AWS vs. Azure vs. GCP: A Platform Engineer's Cold-Blooded Comparison

Most cloud comparisons are written by sales teams or "cloud architects" who focus on feature checklists and pricing tiers. For a Platform Engineer, that's irrelevant. We don't care if a provider has 200+ services; we care about the API consistency, the K8s control plane experience, and the cognitive load of the IAM model. Since this guide first ran, we've kept getting the same feedback: the framing is right, but the numbers are missing. So this edition adds them — list prices checked against the official pricing pages (date-stamped as of Sep 2026), a worked monthly-cost example with the math shown, and the outage history that should inform your region strategy. All prices are on-demand list prices in us-east-1, eastus, and us-central1; no reservations, no committed-use discounts, no enterprise negotiation.

The Technical Comparison Matrix

When evaluating a cloud provider, you aren't choosing a set of tools—you're choosing the "OS" for your infrastructure. Here is how they actually compare on the vectors that matter to SREs.

The Cost Model Deep-Dive: Egress Is the Real Differentiator

Nobody picks a cloud on egress pricing, which is strange, because egress is one of the few line items that scales with your product's success rather than your engineering discipline. All three providers bill internet egress in declining tiers, and all three give you a token free allowance — 100 GB/month on AWS and Azure, 1 GiB on GCP Premium Tier (200 GiB on Standard Tier). Here are the list-price tiers (as of Sep 2026):

Three details the pricing pages bury. First, units differ: AWS and Azure bill per decimal GB, GCP per GiB — at 5 TB/month that's a ~7% unit difference before rates even enter the picture. Second, GCP's Premium Tier (Google's backbone, the default) is more expensive than AWS at low volumes: $0.12/GiB up to 1 TiB vs. AWS's flat $0.09/GB. GCP's Standard Tier — which routes over the public internet with a lower SLA — is the one that undercuts AWS. Third, both AWS and Azure eventually bottom out at $0.05/GB — AWS past 150 TB/month, Azure in its 350 TB tier — but those discounts start past the volume most platforms ever see; at the first paid tier, Azure's edge over AWS is 3.3%; most mid-size platforms never leave the first paid tier, where Azure's edge over AWS is 3.3% and GCP Premium is ~18% worse than AWS.

The other metered network services follow the same "nickel-and-dime the data path" pattern. NAT gateways, which you need for private subnets to reach the internet, are priced remarkably similarly — and add up remarkably fast:

Load balancers diverge more. AWS bills an hourly charge plus capacity units (ALB: $0.0225/hr + $0.008/LCU-hour). Azure's Standard Load Balancer is $0.025/hr for the first 5 rules plus $0.005/GB processed. GCP bundles your first 5 forwarding rules into a single $0.025/hr charge and adds $0.008/GiB processed. For a 2-LB platform moving 2 TB/month through the balancers, that's roughly $49 (AWS), $47 (Azure), and $33 (GCP) — GKE's external Application Load Balancer is genuinely cheaper here, partly because you're charged once for the bundle instead of per balancer.

A Worked Example: The Same Platform, Priced Three Ways

Assume a mid-size platform: 40 nodes of 4 vCPU/16 GB (m5.xlarge on AWS, D4s_v5 on Azure, n2-standard-4 on GCP), 5 TB/month of internet egress, 2 load balancers processing 2 TB/month, NAT processing 5.5 TB/month (outbound plus return traffic), a 3-AZ deployment, one production K8s cluster with an SLA-backed control plane, and a 730-hour month. List prices, as of Sep 2026:

The math, so you can check us: compute is 40 × $0.192 × 730 on AWS/Azure (m5.xlarge and D4s_v5 both list at $0.192/hr) and 40 × $0.1942 × 730 on GCP. Egress: AWS is (5,000 − 100) × $0.09; Azure is (5,000 − 100) × $0.087; GCP Premium is 1,023 GiB × $0.12 + 3,632.6 GiB × $0.11 (5 TB = 4,656.61 GiB), and Standard Tier is (4,656.61 − 200) × $0.085. NAT: AWS runs one gateway per AZ for zone redundancy — 3 × $0.045 × 730 = $98.55 hourly plus 5,500 GB × $0.045 = $247.50 processing; Azure's StandardV2 is zone-redundant in a single resource, so $32.85 + $247.50; GCP bills 40 VMs at the 32-VM cap ($0.044 × 730 = $32.12), 2 external IPs ($7.30), and 5,122.27 GiB × $0.045 processing. Load balancers: AWS 2 × $0.0225 × 730 + ~2.74 GB/hr processed × $0.008 × 730; Azure 2 × $0.025 × 730 + 2,000 GB × $0.005; GCP $0.025 × 730 (both rules inside the first-5 bundle) + 1,862.65 GiB × $0.008.

Read the AKS row again, because it's the story here. Azure's pricing page (as of Sep 2026) layers a per-vCPU management charge on top of the VM price for AKS-managed nodes — $7.05/month per General Purpose vCPU. Forty 4-vCPU nodes is 160 vCPUs, or $1,128/month, before you've paid for a single virtual machine. That single line item turns Azure from "roughly at parity" into 16% more expensive than AWS for this shape of platform, and it scales with node count, not with cluster count. If you run wide, flat clusters on AKS, re-price your fleet before your next renewal. Caveats, because we'd rather be precise than dramatic: this excludes storage, databases, reservations/savings plans, CDN offsets (CloudFront egress is materially cheaper than direct egress), and the fact that most enterprises negotiate. A 1-2 NAT-gateway AWS design saves ~$65-98/month but concentrates failure. GCP's Standard Tier saves ~$144/month but rides the public internet. The point isn't the absolute number — it's that identical architectures produce materially different bills, and the differences live in boring network line items.

The Idle-Cost Traps

Every provider has charges that accrue while you sleep. The ones that actually hurt platform teams:

• AWS: Every public IPv4 address costs $0.005/hr — attached or not — since February 2024. That "temporary" Elastic IP on a dead NAT gateway is $3.65/month each, forever. An idle EKS cluster bills $73/month at zero workloads. NAT gateways bill per-AZ hourly whether or not traffic flows.
• Azure: A Standard Load Balancer with zero backend pools bills $18.25/month. Standard public IPs bill at $0.005/hr reserved-but-unattached. The killer: AKS Standard tier + per-vCPU charges accrue on stopped-but-not-deallocated clusters that still have node objects.
• GCP: An unused static external IP is billed at a higher rate than an in-use one — Google's explicit nudge to not hoard addresses. Regional GKE clusters bill the same $73/month as zonal ones (only zonal and Autopilot clusters get the free-tier credit). Autopilot enforces minimum resource requests (50m CPU / 0.5 GiB per container), so microservices that requested nothing get billed for something.

Network Topology: Three Mental Models

You can't design a landing zone until you internalize how each provider models "a network" — because they genuinely disagree.

• AWS VPC: A VPC is regional, with subnets pinned to Availability Zones. Accounts are the hard isolation boundary; networks are not. Cross-VPC routing is never free and never transitive by accident — peering is point-to-point, so multi-account shops converge on Transit Gateway ($0.05/hr per VPC attachment, $0.02/GB processed).
• Azure VNet: A VNet is also regional, with the same non-transitive peering model (500 peerings per VNet by default; hub-spoke with Azure Virtual Network Manager stretches to ~1,000 spokes). The mental model is explicitly hub-and-spoke: a shared-services hub VNet (firewall, DNS, VPN) that every workload VNet peers to. Data traversing peering costs $0.01/GB each direction, same-region; global peering runs $0.035–$0.16/GB by zone pair.
• GCP VPC: The odd one out — a VPC is global, with regional subnets inside it. One network object spans every region your project uses, which deletes the "how do I connect my regions" problem AWS and Azure make you solve, and replaces it with "IAM in one project is the perimeter." Spoke-to-spoke traffic still needs Network Connectivity Center (hubs are free; VPC spokes $0.10/hr, hybrid spokes $0.075/hr, plus $0.02/GiB advanced data networking).

AWS: accounts are the wall, TGW is the plumbing
  acct-prod           acct-staging
   VPC (regional)      VPC (regional)
        \                 /
         [ Transit Gateway ]--- egress VPC --- internet
         $0.05/hr per attachment + $0.02/GB

Azure: hub-and-spoke is the canonical shape
  mgmt subscription
        |
   hub VNet (firewall, DNS, VPN)
   /       |       \
  spoke   spoke    spoke
  (peering: non-transitive, $0.01/GB per direction)

GCP: the network is global, the project is the wall
  organization
   +-- folder: platform
        +-- project: prod   -- one VPC, subnets in every region
        +-- project: staging
        +-- project: ci

Private access to managed services is where the models fork hardest. AWS PrivateLink gives you an elastic network interface in your VPC per endpoint — $0.01/hr per AZ plus $0.01/GB (tiered down to $0.004/GB past 1 PB); gateway endpoints for S3 and DynamoDB are free. Azure Private Endpoints are per-resource NICs inside your subnet — $0.01/hr plus $0.01/GB processed — and they're the standard answer for storage, databases, and anything else you don't want touching the internet. GCP Private Service Connect endpoints are forwarding rules: $0.01/hr, data charges per the service. Functionally all three converge on the same idea; the difference that matters operationally is that Azure's private endpoints consume subnet address space (plan your CIDRs or you'll re-IP), while AWS's interface endpoints do too but gateway endpoints for S3 don't. For hybrid connectivity, the honest summary: all three sell you the same physical product (MPLS-adjacent private circuits into their regions) with different marketing. AWS Direct Connect, Azure ExpressRoute, and GCP Cloud Interconnect (Dedicated or Partner) all bill port-hours plus per-GB egress through the circuit. Budget-wise, GCP's Partner Interconnect is the cheapest entry point for sub-Gbps needs ($0.054–$0.174/hr by port); AWS and Azure want you to commit to full ports. The topology decision matters more than the vendor: if your on-prem footprint is small, terminate VPNs in the hub and skip circuits entirely until throughput forces the issue.

Deep Dive: The Managed K8s Battle (EKS vs AKS vs GKE)

For platform engineers, the managed Kubernetes service is the "center of gravity." This is where the real operational difference lies.

The K8s Cost Reality: Control Planes, Serverless, and Upgrade Windows

The "$73/month control plane" is folklore at this point, and it's mostly still true — with meaningful exceptions. List prices as of Sep 2026:

The philosophical split is in the last row. GKE treats upgrades as a provider responsibility and will move your cluster whether you enrolled in a channel or not. AKS escalates: past end-of-support, Microsoft auto-upgrades you. EKS is the laissez-faire one — your cluster just gets more expensive. If your platform can't absorb an unrequested minor-version bump, you need maintenance windows and PDBs regardless of provider, but AWS at least lets you schedule the disruption on your calendar instead of theirs.

The "serverless K8s" pricing models are genuinely different animals, and the marketing hides it:

• EKS + Fargate: per-pod, per-second (1-minute minimum) billing on the resources your pod requests — about $0.04048/vCPU-hour and $0.004445/GB-hour in us-east-1. There is no Spot for EKS Fargate, so bursty batch workloads pay full freight.
• GKE Autopilot: bills the pod's requests per second with no minimum duration ($0.0445/vCPU-hour, $0.0049225/GiB-hour for general-purpose in us-central1) — but Autopilot silently raises requests that don't meet minimums, so your manifest hygiene is directly on the bill.
• AKS: no true Fargate analog. Virtual Nodes run pods on Azure Container Instances (per-second, per-vCPU/GB), and AKS Automatic manages node pools but still bills VMs plus that per-vCPU management charge. The practical result: Azure's serverless K8s story is the least mature of the three.

IAM in Practice: The CI Pipeline Test

IAM complexity is best measured not in feature lists but in what it takes to do the single most common platform task: give a CI pipeline write access to exactly one object-storage bucket and nothing else. Here's the runnable version on each provider.

AWS: two JSON documents — a trust policy federating your CI's OIDC provider (no long-lived secrets), and a permission policy pinned to one prefix:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": "arn:aws:s3:::platform-monkey-artifacts/ci/*"
    }
  ]
}

Azure: there is no resource-level policy language — you assign a built-in RBAC role ("Storage Blob Data Contributor") scoped down to the container, to an Entra ID service principal. One command, if you already know your ARM resource ID syntax:

az role assignment create \
  --assignee "$SP_OBJECT_ID" \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/$SUB_ID/resourceGroups/rg-platform/providers/Microsoft.Storage/storageAccounts/stplatformmonkey/blobServices/default/containers/artifacts"

GCP: an IAM binding on the bucket, with a CEL-based condition if you want prefix-level restrictions — the binding is a mutation of the bucket's policy document, not a standalone object:

gcloud storage buckets add-iam-policy-binding gs://platform-monkey-artifacts \
  --member="serviceAccount:ci-pusher@platform-monkey.iam.googleapis-alias.example.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin" \
  --condition='expression=resource.name.startsWith("projects/_/buckets/platform-monkey-artifacts/objects/ci/"),title=ci-prefix-only'

Now the honest comparison. AWS is the most expressive — the JSON is auditable, diffable, and precise to a single prefix — and the OIDC federation pattern is the cleanest in the industry. The cost is that expressiveness: policies compose through a subtle interaction of identity policies, resource policies, SCPs, and permission boundaries, and "who can touch this bucket" becomes a multi-document archaeology project at scale. Azure is a one-liner, but the role is coarse (contributor on the container, not write-to-one-prefix), role assignments take minutes to propagate, and the real policy boundary is the scope string — a typo in a resource ID fails open more often than you'd like. GCP splits the difference: the project hierarchy makes "who is in scope" obvious, conditions give prefix-level control, but the default project roles (editor, legacy owner grants) hand out far more than CI needs, and deleting bindings requires editing a policy document that other automation may be mutating concurrently.

The "Exit Strategy" Analysis

The most important question for a platform lead is: \"How hard is it to leave?\"

The lock-in isn't the VM; it's the Proprietary Data Plane. If you use AWS S3, you can move to any S3-compatible storage. If you use AWS DynamoDB, you are locked into a proprietary API. The same applies to GCP's BigQuery and Azure's CosmosDB. The Platform Monkey Strategy: To maintain sovereignty, use a "Cloud-Agnostic" abstraction layer. Use Crossplane to define your resources and Kubernetes as your universal control plane. By defining a XDatabase resource rather than an RDSInstance, you make the cloud provider an implementation detail rather than a permanent anchor. We've covered the full mechanics — including where Crossplane's Upjet layer lags Terraform providers — in Crossplane vs. Terraform: state files vs. control planes. One caveat we've grown into after watching teams actually attempt exits: egress pricing is the exit tax. Moving 500 TB of S3 data to another cloud at $0.05-0.09/GB costs $25,000-45,000 in egress fees alone — which is precisely why AWS introduced free egress for customers moving off the platform. Any exit strategy that ignores the data-movement bill is theater.

Multi-Region Reality: Outage History and Blast Radius

All three providers sell multi-region architectures, and all three have had the kind of incidents that tell you where their real failure domains live. Dates verified against the providers' own post-incident reports:

Two structural conclusions fall out of this history. First, every provider has a global layer that outranks your regional architecture: AWS's is concentrated in us-east-1 (where more services' control planes live than anywhere else), Azure's is ARM plus the shared Microsoft identity/config fabric, GCP's is its identity and policy planes. Designing "multi-region" within one provider mitigates some failure modes (the Nov 2020 Kinesis class) and is helpless against others (the Dec 2020 and Jun 2025 classes). Second, blast radius is governed by your account/subscription/project topology, which is where landing zones come in. The three landing-zone models, and what they actually isolate:

• AWS — Organizations + Control Tower: accounts are the isolation unit. SCPs enforce guardrails at the org level; blast radius (quota exhaustion, IAM mistakes, compromised credentials) stops at account boundaries. The cost: accounts are heavyweight — email, payment plumbing, CloudTrail per account — so teams procrastinate on account hygiene. Multi-account is the default posture for any serious AWS shop, and Transit Gateway is the tax for connecting it all. (We cover the topology patterns in landing zone design patterns.)
• Azure — Management Groups + Azure Landing Zones: subscriptions are the isolation unit, arranged under management groups that inherit policy (Azure Policy) and RBAC. The reference ALZ implementation is genuinely opinionated and decent. The weakness the outage table exposes: ARM is the shared control plane above all your subscriptions, so "subscription-level isolation" protects you from yourself, not from Microsoft.
• GCP — Organization → Folders → Projects: projects are the isolation unit, and they're free and instant — so GCP shops naturally drift to hundreds of projects (one per team, per env, per service). Folders + org policies give the same inherited-governance model as management groups. The failure modes above show the ceiling: identity and the policy plane sit above every project.

On data residency: all three now sell sovereignty tiers for customers whose regulators require them — the AWS European Sovereign Cloud (GA, Brandenburg region) with its own isolated control plane, Microsoft Cloud for Sovereignty as a governance layer over standard Azure regions, and Google's Sovereign Cloud portfolio (Data Boundary, Dedicated, Air-Gapped). Note what they admit by existing: in the standard commercial clouds, your data's location and the control plane's location are different claims.

Who Should Skip Each Cloud

Every cloud comparison ends with "it depends." We refuse. Here's when each provider is the wrong answer:

• Skip AWS if your platform team is smaller than five engineers. AWS's model assumes you have people for account strategy, SCP design, TGW topology, and Karpenter tuning. A 2-3 person platform team on AWS spends its time on AWS. The 200+ service surface is a decision-fatigue tax you pay daily. Also skip AWS if your product is egress-heavy with thin margins (video, large-file distribution) — you'll notice the $0.09/GB, and AWS is the only one of the three whose first paid egress tier hasn't gotten cheaper in years.
• Skip Azure if you are not already a Microsoft shop. The value of AKS and Entra ID is mostly in the integration you're not using if you don't run M365, Intune, or the Microsoft identity stack. You'd be paying the heaviest ARM control plane, the noisiest feature-flag surface, and — as of Sep 2026 — a per-vCPU AKS management charge on top of VM prices, without cashing any of the ecosystem dividends. Multi-tenant SaaS with many small clusters gets hit hardest by that billing model.
• Skip GCP if your procurement demands enterprise hand-holding or your compliance surface is long-tail. Google's org has fewer compliance certifications and a thinner third-party marketplace than AWS/Azure in most verticals, and its sales/support motion is built for companies that don't need to be sold to. Don't skip GCP over the outage table above — every provider's history looks like that — but do skip it if your data gravity lives in another provider's analytics warehouse already; BigQuery's gravity well only pulls one way.

Final Verdict

• Choose GCP if: You want the best K8s experience and the lowest operational overhead. GKE is simply better — and at moderate scale, the free-tier cluster credit and bundled LB rules make it the cheapest of the three, provided you can stomach Premium-Tier egress or live with Standard Tier's best-effort routing.
• Choose AWS if: You need the most mature ecosystem, the widest range of instance types, and the absolute industry standard for scale — and you have the team to operate the machinery. AWS is not the cheapest at any single line item; it's the provider most likely to already have the service you'll need in year three.
• Choose Azure if: Your organization is a "Microsoft Shop" and you need seamless integration with Active Directory and Office 365. That integration is real and it's excellent. Price it first: as of Sep 2026, AKS's per-vCPU management charge makes Azure the most expensive of the three for wide, VM-based clusters — budget the delta before you commit.
• Whichever you choose: treat egress as a first-class cost model, keep the landing-zone hierarchy as your blast-radius tool, and put an abstraction layer between your developers and the provider's proprietary data planes. The clouds are more similar than their sales decks claim — the differences that matter are the boring ones: unit sizes, minimums, and who auto-upgrades your cluster at 2 AM.