The three hyperscalers in context

Amazon Web Services (AWS) launched public cloud infrastructure at scale in 2006 and still carries the largest service catalog and market share. Microsoft Azure grew from enterprise agreements and hybrid datacenter roots—Active Directory, Windows Server, SQL Server, and Office are gravitational fields. Google Cloud Platform (GCP) arrived later as a commercial offering but inherits decades of Google-scale distributed systems: Borg, Bigtable, Spanner, Kubernetes, and TensorFlow.

All three meet NIST’s cloud characteristics—on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service. Differences show up in how they package those capabilities and who they optimize for first.

Philosophy and product DNA

AWS: builder-first, service-rich, customer-obsessed operations

AWS’s culture is “everything is an API.” The catalog grew organically: hundreds of services, many overlapping, each solving a niche a customer asked for. That yields unmatched choice—and cognitive load. Teams that want granular control, early access to new primitives, and a hire-from-anywhere talent pool often default here.

Strengths that follow from DNA: operational maturity, partner ecosystem, IAM depth, edge (CloudFront), and sheer reference architecture volume. Friction: console complexity, naming inconsistency across services, and pricing that rewards FinOps discipline.

Azure: enterprise integration and hybrid continuity

Azure is built for organizations that already live in Microsoft. Entra ID (formerly Azure AD), hybrid identity, Windows workloads, .NET, SQL, and Microsoft 365 licensing create natural on-ramps. Azure Arc extends management to on-premises and other clouds—a deliberate hybrid story.

Strengths: identity and governance for regulated enterprises, SAP and Oracle partnerships, strong PaaS for .NET, and procurement familiarity for existing EA customers. Friction: documentation sprawl, occasional service parity lag behind AWS in niche areas, and the need to navigate product renaming (Resource Manager vs classic resources are mostly history, but mental models linger).

GCP: engineering rigor, open source, data and AI

GCP sells itself to teams that care about clean APIs, Kubernetes-native design, and data analytics. Google invented or popularized much of the cloud-native stack; GKE was Kubernetes before Kubernetes was everywhere. BigQuery, Pub/Sub, and Spanner reflect Google’s internal patterns exported as products.

Strengths: networking (Andromeda), live migration on Compute Engine, GKE operations, data warehouse and ML (Vertex AI), and sustained-use or committed-use discounts that are straightforward relative to AWS’s discount maze. Friction: smaller absolute market share in many regions, fewer third-party integrations than AWS in some verticals, and enterprise sales motion that matured later than the other two.

At-a-glance comparison

Global footprint and compliance

All three operate worldwide region/zone models with sovereign and government clouds where required (e.g. AWS GovCloud, Azure Government, GCP Assured Workloads). Choice often comes down to specific country presence—a bank in Seoul may care which region opened first—and certification attestations for their sector (PCI, HIPAA, ISO 27001, FedRAMP).

Do not assume parity: a service “generally available” in us-east-1 may still be preview in europe-west3. Architecture reviews should list required regions and check service availability matrices per provider.

Pricing and commercial models (depth, not line items)

Public list prices differ by workload; effective cost depends on commitments, architecture, and discipline.

• AWS popularized Reserved Instances and Savings Plans; spot instances for fault-tolerant batch; complex but optimizable at scale.
• Azure often bundles cloud spend into existing Enterprise Agreements; Hybrid Benefit discounts Windows/SQL licenses you already own.
• GCP applies automatic sustained-use discounts on Compute Engine and Committed Use Discounts (CUDs) for predictable spend; BigQuery separates storage and query pricing clearly.

None of the three punishes you for being small; all three can surprise you at scale without FinOps visibility. Compare workload-shaped estimates, not headline vCPU prices. See also the invisible bill series for why cost culture matters as much as unit rates.

Enterprise adoption patterns

Greenfield startups often pick AWS or GCP for hiring pools and tutorials; Azure wins when the founder’s corporate card is tied to Microsoft. Enterprises frequently land on Azure when identity and desktop standards are Microsoft; AWS when they want maximum service choice; GCP when analytics or ML is the strategic bet.

Regulated industries care about landing zones, guardrails, and audit evidence— achievable on all three with different reference architectures (AWS Control Tower, Azure Landing Zone, GCP Foundation Toolkit).

Developer and platform experience

AWS CLI and CloudFormation/Terraform modules are everywhere; the learning curve is steep but documentation and community answers are abundant. Azure’s portal and Bicep/ARM templates resonate with teams already using Visual Studio and GitHub Actions (now Microsoft-owned). GCP’s gcloud CLI, Cloud Shell, and opinionated defaults appeal to engineers who prefer fewer knobs—until they need a niche service AWS shipped years ago.

For platform engineering, all three support internal developer portals, policy-as-code, and GitOps patterns described in GitOps principles. The difference is which managed services your paved road wraps first.

When each hyperscaler tends to win

Use this as a decision lens, not a law:

• Lean AWS when you need the broadest catalog, largest partner network, mature edge and serverless (Lambda), or your team already holds AWS certifications.
• Lean Azure when Entra ID is the identity system of record, you run Windows/SQL/.NET heavily, or hybrid Arc is non-negotiable.
• Lean GCP when Kubernetes is central, you are building on BigQuery/Vertex, or you want Google-grade networking and data tooling without assembling every piece yourself.

Many organizations run two clouds for acquisition integration, geographic redundancy, or vendor negotiation—not because they love operational duplication.

Multi-cloud, lock-in, and exit strategy

Portable layers—Kubernetes, Postgres, Terraform, OpenTelemetry—reduce switching cost. Proprietary layers—DynamoDB-specific access patterns, Azure AD B2C custom policies, BigQuery-specific SQL—buy capability at the price of migration effort.

Honest multi-cloud uses each provider where it is best (e.g. GCP for analytics, AWS for retail edge) with shared governance, not identical stacks copy-pasted three times. Plan exit options for tier-0 data stores and identity; treat proprietary AI APIs as replaceable adapters where regulation requires.

Talent, certifications, and hiring

AWS certifications (Cloud Practitioner → Solutions Architect → specialty) remain the most recognized globally. Azure role-based paths align with enterprise job titles. GCP Professional Cloud Architect and data/ML certs signal strong engineering hires for analytics teams.

Hiring markets vary by city: Kathmandu, Singapore, and London will show different skill pools. Standardize internal learning paths but avoid certification theater without hands-on labs.

Sustainability and responsibility

All three publish carbon transparency tools and renewable energy goals. Instance choice, region selection, and rightsizing still dominate your footprint more than logo color. Align technical decisions with GreenOps practice, not marketing PDFs alone.

What this series does next

Part 2 maps concrete services—compute, storage, databases, networking, identity, observability, AI, and more—in AWS, GCP, and Azure: service-by-service mapping. If you are new to cloud vocabulary, read cloud platform evolution first; for AWS-specific depth, see the Cloud Practitioner and Cloud Architecting notes.

Further reading

• Gartner / Flexera / Synergy — market share and enterprise adoption surveys (yearly)
• Each provider’s Well-Architected or Cloud Adoption Framework
• Cloudflare — multi-cloud networking and egress cost analyses
• FinOps Foundation — unit economics across providers

Blog index · Part 2: Service mapping · Cloud platform evolution

Back to blog list