EKS vs GKE vs AKS in 2026: Same $0.10 Fee, Very Different Clusters

The question "which managed Kubernetes should we use?" usually comes from a team that has already picked a cloud and wants permission. In 2026 the honest answer to EKS vs GKE vs AKS is that the control plane is no longer where they differ. All three charge $0.10 an hour for it, all three sell an opinionated mode that runs your nodes for you, and all three charge roughly $0.50 an hour more if you want to stay on an old Kubernetes version. The differences that matter sit below the API server: how pods get IP addresses, how they get cloud credentials, which GPUs you can actually schedule, and how firmly the provider will upgrade you when you fall behind. Below I compare those, with sources re-checked on 31 October 2026, and say what I would pick for which kind of team.

EKS vs GKE vs AKS pricing: control plane fees and free tiers

The base fee has converged. Amazon EKS charges $0.10 per cluster per hour in standard support. GKE charges a flat $0.10 per cluster per hour "irrespective of the mode of operation", Autopilot included. AKS lists its Standard tier at $0.10 an hour in Azure's retail price feed, and its pricing tiers page describes what each tier buys. At 730 hours a month, that is about $73 per cluster.

The free tiers are where they part ways. AKS has a genuine Free tier: no control plane charge, no financially backed SLA, support for up to 1,000 nodes but a recommendation to stay under 10. GKE gives every billing account $74.40 of monthly credit, which is 744 hours at $0.10, enough for one zonal Standard or one Autopilot cluster for a 31-day month; it does not apply to regional Standard clusters. EKS has no free control plane at all. GKE also simplified its packaging: its editions page says GKE "is a single offering", with the Enterprise features folded in and the cluster tier field gone since 23 September 2025.

	Amazon EKS	Google GKE	Azure AKS
Control plane fee	$0.10/cluster-hour (pricing)	$0.10/cluster-hour, all modes (pricing)	Free tier $0; Standard $0.10/hr (tiers)
Free allowance	None	$74.40/month credit per billing account	Free tier: no SLA, recommended under 10 nodes
Long version support	Extended: $0.60/hr total for 12 more months	Extended period: +$0.50/hr, up to 24 months	Premium with LTS: $0.60/hr, billed only in the LTS window (release notes)
API server SLA	99.95%; 99.99% on Provisioned Control Plane (SLA)	99.95% regional and Autopilot; 99.5% zonal	99.95% with availability zones, 99.9% without
Bigger control plane	Provisioned tiers, $1.65/hr (XL) to $13.90/hr (8XL)	Regional Standard up to 65,000 nodes via support (limits)	Up to 5,000 nodes on Standard and Premium
Opinionated mode	Auto Mode: per-instance fee, 12% of on-demand EC2 price in AWS's examples	Autopilot: $0.10/hr plus Pod-based billing	Automatic: $0.16/hr hosted control plane, plus VMs and an Automatic compute charge per VM family (pricing)

Two notes on that table. The EKS Provisioned Control Plane, launched on 27 November 2025, pre-allocates API server capacity; AWS's benchmark ran 40,000 nodes and 640,000 pods on 4XL against 5,000 nodes and 80,000 pods on a standard control plane. And the Auto Mode fee is per instance: every pricing example (c6a.2xlarge at $0.306 with a $0.03672 fee, m5a.xlarge at $0.172 with $0.02064) works out to 12 percent of the on-demand price.

None of these fees decides a budget. The control plane is $73 a month; half-idle nodes, NAT gateways and cross-zone traffic usually cost far more, as I covered in Kubernetes Cost Optimization in 2026.

EKS Auto Mode vs GKE Autopilot vs AKS Automatic

Each provider now sells a mode where it owns the nodes. The intent is the same; the billing and the lock-down are not.

EKS Auto Mode runs compute autoscaling on Karpenter, plus pod networking, load balancing, EBS storage and GPU drivers as managed components. Nodes are Bottlerocket variants with SELinux enforcing and a read-only root, SSH and SSM access are disallowed, and every node has a 21-day maximum lifetime. You pay EC2 prices plus the per-instance fee above.

GKE Autopilot is the oldest of the three and the one Google calls "the recommended way to use GKE". General-purpose Pods are billed on their resource requests, so the node shape does not matter to your invoice; Pods that ask for specific hardware such as accelerators switch to node-based billing plus a management premium. You can also run individual workloads in Autopilot mode inside a Standard cluster by selecting an Autopilot ComputeClass.

AKS Automatic moved to general-availability billing on 19 October 2025, with a $0.16 per cluster-hour hosted control plane fee and compute charged by VM type and duration, according to the AKS release notes. Read the pricing page closely: that compute charge comes "in addition to" the VMs themselves, and Azure's price feed lists a separate hourly Automatic meter for each VM family, so like EKS Auto Mode it carries a management premium on top of the instances. It comes preconfigured with Standard tier, node autoprovisioning, Azure CNI Overlay powered by Cilium, Microsoft Entra Workload ID, deployment safeguards and automatic upgrades on the stable channel, and it is the only one of the three with a pod readiness SLA: 99.9 percent of qualifying pod readiness operations complete within five minutes. GKE's Autopilot SLA is about Pod availability instead, 99.9 percent for Pods spread across zones.

Two of the three are Karpenter underneath. AWS says so in the Auto Mode docs, and the AKS release notes record node autoprovisioning moving to Karpenter provider Azure v1.14.0. If you want that behaviour without the managed wrapper on AWS, my companion guide on how to set up Karpenter on EKS walks through NodePools, Spot and consolidation. Creating one opinionated cluster on each cloud looks like this; I checked the flags against the eksctl Auto Mode docs and the local gcloud and az help output, not against live accounts.

# EKS Auto Mode with eksctl 0.231.0 (released 2 October 2026)
cat > eks-auto.yaml <<'EOF'
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: demo-auto
  region: us-west-2
  version: "1.37"            # EKS standard support until 1 December 2027
autoModeConfig:
  enabled: true              # creates the general-purpose and system NodePools
EOF
eksctl create cluster -f eks-auto.yaml

# GKE Autopilot on the Regular channel (1.37 became available there on 22 October 2026)
gcloud container clusters create-auto demo-autopilot \
  --location=us-central1 \
  --release-channel=regular

# AKS Automatic (flags checked on Azure CLI 2.78.0; 2.91.0 is current); upgrades itself on the stable channel to N-1
az aks create \
  --resource-group rg-demo \
  --name demo-automatic \
  --sku automatic

How long does each provider support a Kubernetes version?

This is where policy differs most, and several dates land this quarter.

EKS gives each minor version 14 months of standard support and 12 of extended support, 26 months in total, and extended support is on by default. Today 1.34 to 1.37 are in standard support (1.37 arrived on EKS on 1 October 2026, five weeks after the upstream release on 26 August) and 1.31 to 1.33 are in extended. When extended support ends, EKS upgrades the control plane only; managed node groups and self-managed nodes stay behind, which is how unplanned version skew happens. Version 1.31 leaves extended support on 26 November 2026 and 1.34 leaves standard support on 2 December 2026.

GKE's schedule gives roughly 14 months from Regular availability to the end of standard support, and the Extended channel stretches that to 24 months for an extra $0.50 per cluster-hour once standard support ends. Version 1.37 reached Rapid on 2 September and Regular on 22 October 2026.

AKS supports N-2 with a 12-month policy and sells one more year as LTS on the Premium tier. It is also the strictest about stragglers: starting on 1 June 2027, any cluster still on an unsupported version after its 60-day grace period gets a platform-initiated upgrade "one minor version at a time", and the docs say "There's no opt-out." Azure Linux 2.0 node images are also removed on 31 October 2026, after which those pools cannot scale. That is today.

Networking: VPC CNI vs GKE Dataplane V2 vs Azure CNI Overlay

The Amazon VPC CNI gives every pod a real IPv4 or IPv6 address from your VPC, which makes pods first-class in security groups and flow logs, and makes subnet sizing your problem. It is the only CNI that EKS supports for nodes on AWS infrastructure; other compatible plugins run, but AWS support stops at the VPC CNI. Plan for prefix delegation, custom networking or IPv6 before the subnets fill up.

GKE Dataplane V2 is built on Cilium and eBPF and is on by default for new Autopilot clusters. The catch is in one sentence of the docs: it "can only be enabled when creating a new cluster". Choose it at creation or plan a migration.

On AKS, Azure CNI Overlay assigns pod IPs from a separate CIDR, supports 250 pods per node, and is the option Microsoft recommends "for most scenarios"; Azure CNI Powered by Cilium can sit on top as the data plane. Kubenet retires on 31 March 2028. Oddly, the AKS Automatic comparison table still lists kubenet as the default for a Standard cluster created with a managed VNet, which is a good reason to always pass --network-plugin explicitly.

Pod identity: EKS Pod Identity vs Workload Identity Federation vs Entra Workload ID

All three have moved from node credentials to federated, per-service-account identity, and all three work; the differences are operational. EKS Pod Identity needs no OIDC provider, uses one trust principal (pods.eks.amazonaws.com) that works across clusters, and allows 5,000 associations per cluster, but it does not work on Fargate, where IRSA is still the answer. Workload Identity Federation for GKE lets you grant IAM roles directly to a Kubernetes ServiceAccount through a principal:// identifier, so the old Google service account impersonation dance is optional. Microsoft Entra Workload ID is preconfigured on AKS Automatic and opt-in on Standard; watch the limit of 20 federated identity credentials per managed identity, which identity bindings (one credential shared by many clusters) are designed to get around. I covered the underlying mechanism in Workload Identity Federation Explained.

GPU availability on EKS, GKE and AKS

For AI workloads, regional capacity matters more than any feature. On paper: the EKS accelerated AMIs cover p6-b300, p6-b200 and the p5 family on x86, p6e-gb200 and p6e-gb300 on the ARM NVIDIA variant, and Inferentia and Trainium through the Neuron variant. GKE Autopilot lists GB300 (A4X Max), GB200 (A4X), B200, H200, H100 and smaller GPUs, Standard supports every GPU Compute Engine sells, and GKE is the only one of the three with TPUs. AKS recommends AKS-managed GPU node pools, where it installs the NVIDIA driver, device plugin and DCGM exporter for you; its GPU page did not name the ND GB200 or GB300 v6 sizes when I checked, so run az vm list-skus in your region before you promise anyone Blackwell on AKS. Who actually has the GPUs, at what price, is the subject of GPU Clouds in 2026.

Which should you choose? EKS, GKE or AKS by team type

A small team with no platform engineer. GKE Autopilot, if nothing else pulls you to a cloud. The $74.40 credit covers one cluster, Pod-based billing punishes bad node choices less, and it is the oldest of the three managed modes. AKS Automatic is a close second, and the better choice if you are already on Azure.

A company already deep in AWS. EKS, almost regardless of the comparison; your IAM, VPCs, data and commitments are there. Start with Auto Mode if you can live with no SSH and a 21-day node lifetime; run Karpenter yourself if you need custom AMIs or want to avoid the 12 percent fee.

A Microsoft and Entra ID shop. AKS. Entra integration, Azure RBAC for Kubernetes and the pod readiness SLA on Automatic are real advantages, and the forced upgrade policy is easier to accept than to fight.

AI and ML teams. Follow the accelerator. TPUs mean GKE, Trainium means EKS, and for NVIDIA Blackwell the deciding factor is which provider will sell you capacity in your region this quarter.

Regulated teams that upgrade slowly. All three sell about two years of support for about $0.50 an hour more. That is cheaper than an unplanned upgrade, but it is a loan, not a fix; all three will eventually upgrade you anyway.

Very large clusters. GKE allows up to 65,000 nodes in regional Standard clusters, EKS has Provisioned Control Plane tiers, and AKS stops at 5,000 nodes per cluster, which pushes you toward multiple clusters earlier.

The managed modes do not remove the work that makes clusters cheap and reliable: honest resource requests, PodDisruptionBudgets that let nodes move, and an upgrade cadence someone owns. They move the cost of skipping that work from your pager to your invoice.

FAQ

Which is cheapest: EKS, GKE or AKS?

For the control plane, AKS Free tier is the only one that is truly free, and GKE's $74.40 monthly credit covers one zonal or Autopilot cluster. Otherwise all three charge $0.10 per cluster-hour, about $73 a month. Nodes, networking and idle capacity dominate the bill, so the cheapest provider is usually the one holding your discounts and data.

Is EKS Auto Mode the same as GKE Autopilot?

No. Both manage nodes for you, but Autopilot bills general-purpose Pods on their resource requests, while EKS Auto Mode bills the EC2 instances it launches plus a per-instance management fee. Auto Mode is built on Karpenter and uses locked-down Bottlerocket nodes with a 21-day maximum lifetime.

How long are Kubernetes versions supported on EKS, GKE and AKS?

EKS supports each minor version for 26 months (14 standard plus 12 extended). GKE gives about 14 months of standard support and up to 24 months on the Extended channel. AKS gives 12 months, plus 12 more with LTS on the Premium tier.

Can I run Karpenter on GKE or AKS?

On AKS, yes: node autoprovisioning is Karpenter provider Azure, and the Karpenter docs also point to the self-hosted Azure provider. On GKE, the Karpenter project README lists a community GCP provider, but it is not a Google product; GKE's supported answer is its own node auto-provisioning and ComputeClasses.

This quarter, on any of the three, I would do three things before touching features. List every cluster's minor version against the calendars above, because 1.31 on EKS and 1.34 on AKS reach end of support in November, 1.34 leaves EKS standard support on 2 December, and Azure Linux 2.0 node images are removed from AKS today. Check which clusters are quietly paying the $0.50 extended or LTS premium and decide whether that is a choice or an accident. And set a budget alert on node spend rather than control plane spend, because that is where the money actually goes.

Related: Kubernetes Autoscaling Explained (2026): HPA, VPA, KEDA and Karpenter, Kubernetes Cost Optimization in 2026: 8% CPU Use and What Fixes It and Workload Identity Federation Explained (2026): OIDC Instead of Cloud Keys.