EKS vs GKE vs AKS in 2026: Networking, Upgrades, Autoscaling and Cost

The control plane fee is the least interesting number on a managed Kubernetes bill. All three hyperscalers charge about ten cents per cluster-hour for a production control plane, so any argument about eks vs gke vs aks that starts and ends there is arguing about roughly seventy-three dollars a month. The real differences sit in what each provider operates below the API server: who picks and patches the nodes, how pod IPs are allocated, how forced upgrades arrive, and how much you pay every time a packet leaves a zone or a cloud.

In 2026 each provider also ships an opinionated “hands-off” tier: EKS Auto Mode, GKE Autopilot, and AKS Automatic. They look similar on slides and behave quite differently in production. This post compares them from the documentation, not from the marketing pages, and flags where a number is something you must verify for your region.

What this covers: control plane pricing and SLAs, the three managed tiers, networking and CNI choices, release channels and support windows, node autoscaling, GPUs, workload identity, egress cost traps, multi-cluster, and a decision matrix.

Context and Background

Kubernetes is still the default substrate for platform teams, and the managed offerings have converged on the same promise: you do not run etcd, the API server, or the scheduler. Where they diverge is the shared responsibility line. Classic “standard” modes on all three clouds hand you a managed control plane and a pile of node-level decisions: AMI or image choice, node group sizing, CNI add-on versions, autoscaler installation, and upgrade orchestration. The newer tiers push that line down to the node and add-on layer.

That shift matters because the cost of Kubernetes for most teams is not compute. It is the toil of keeping nodes patched, add-ons compatible, and upgrades unblocked. If you have already weighed node provisioners, our Karpenter vs Cluster Autoscaler GPU comparison covers the autoscaling mechanics in depth; here we compare how each cloud packages them.

The upstream project releases roughly three minor versions a year, and each provider layers its own support policy on top. The Kubernetes project itself documents its release cadence and version skew rules at kubernetes.io/releases. Provider windows are longer than upstream, and they are paid for in different ways, which we will quantify below.

A final piece of context: this comparison is dated. Everything below was checked against vendor documentation on 4 November 2026, when Kubernetes 1.37 had just reached EKS (1 October 2026) and AKS (GA October 2026) and was already in the GKE Rapid and Regular channels. Prices and dates move; treat every figure as a snapshot and re-check the linked pages before you commit a budget.

The Reference Picture: Control Plane, Tier, Dataplane

The simplest way to compare the three platforms is as a three-layer stack: a managed control plane, an optional managed-node tier, and a pod networking dataplane. Fig 1 shows that stack for each cloud.

Direct answer: EKS, GKE and AKS all bill about $0.10 per cluster-hour for a production control plane, and all three now offer a managed-node tier that automates node provisioning and upgrades. They differ mainly in default CNI, how long versions are supported, how upgrades are forced, and how egress is billed.

Figure 1: The three-layer stack on each cloud. The control plane is always managed; the middle tier is where Auto Mode, Autopilot and Automatic differ; the dataplane determines IP planning and policy.

The figure is a simplification, but it surfaces the key idea: the middle layer is now the product. A decade ago the differentiator was whose control plane was more reliable. Today all three publish SLAs for the API server, and the buying decision is about the node and networking layers.

Control plane pricing and SLAs

Here is what the vendor pages say, as fetched during this run.

Item	EKS	GKE	AKS
Control plane fee	$0.10 per cluster-hour (standard support)	$0.10 per cluster-hour, any mode	Free tier: no fee. Standard and Premium: pay as you go, see the AKS pricing page
Extended version support	+$0.50, so $0.60 per cluster-hour	+$0.50 for Extended channel clusters in the extended period, so $0.60	Premium tier with 24-month LTS, see pricing page
Free allowance	None	$74.40 monthly credit per billing account, applies to zonal and Autopilot clusters only	Free tier has no management fee but no SLA
Control plane SLA	Not stated on the pricing page I fetched; check the EKS SLA document	99.95% for Autopilot and regional Standard; 99.5% for zonal Standard	99.95% with availability zones, 99.9% without, on Standard and Premium; none on Free
Node limit stated in docs	Not covered here	Regional Standard up to 5,000 nodes on Dataplane V2	Free up to 1,000, Standard and Premium up to 5,000

A few points deserve emphasis. First, GKE’s fee is flat across zonal, regional and Autopilot, but the $74.40 credit only offsets zonal and Autopilot clusters. A single regional Standard cluster still costs roughly $73 a month in fees (730 hours at $0.10). Second, AKS is the only one with a genuinely free control plane tier, but it comes with no uptime SLA and Microsoft recommends fewer than ten nodes on it. Third, EKS has additionally published Provisioned Control Plane tiers (XL at $1.65, 2XL at $3.40, 4XL at $6.90 and 8XL at $13.90 per cluster-hour on top of standard pricing) for clusters that need higher API throughput. Those are niche, but they show where AWS thinks the large-cluster ceiling bites.

The takeaway for budgeting: for a fleet of fifty production clusters, the control plane fee is about $3,650 a month on any cloud. It is real, and it is also dwarfed by node compute and data transfer. The strategic implication is that cluster count is a cost lever: consolidating five small clusters into one with namespace isolation saves four fees, but costs you blast radius. We return to that in the multi-cluster section.

The three managed-node tiers

EKS Auto Mode. AWS describes Auto Mode as extending management beyond the control plane to the data plane. Compute autoscaling, pod and service networking, load balancing, cluster DNS, block storage and GPU support are built in rather than installed as add-ons. Nodes are treated as appliances: AWS selects the AMI, uses Bottlerocket-based variants, enforces SELinux, uses a read-only root filesystem, and disallows SSH and SSM access. Autoscaling is done by Karpenter run by AWS. Nodes have a maximum 21-day lifetime (configurable shorter), so every node is replaced regularly, respecting PodDisruptionBudgets and NodePool disruption budgets.

Billing is distinct: Auto Mode charges per second (one-minute minimum) for the EC2 instances it launches and manages, as a fee in addition to the normal EC2 price. The pricing page does not state a percentage, though its worked examples (a $0.03672 fee on a $0.306 per hour c6a.2xlarge) work out to 12% of the instance price; that arithmetic is mine, not a published rate, so verify it for your instance types. The operational consequence is that the Auto Mode premium scales with instance size, which makes it relatively more expensive for large GPU nodes in absolute dollars.

GKE Autopilot. Autopilot is now both a cluster mode and a workload mode: you can run an entire cluster in Autopilot, or select an Autopilot ComputeClass for specific workloads inside a Standard cluster. Google manages node provisioning, bin-packing, upgrades and patching. The billing model is the clearest differentiator: for general-purpose workloads you pay for the CPU, memory and ephemeral storage that pods request, per second, and not for system DaemonSets, OS overhead, or unallocated node space. For pods that select specific hardware (accelerators, particular machine series) you pay Compute Engine prices for the whole node plus a management premium. The published example rates for us-central1 are $0.0445 per vCPU-hour and $0.0049225 per GiB-hour for the container-optimized platform. Those are list rates for one region at fetch time.

AKS Automatic. Microsoft’s page describes it as preconfigured and opinionated, and recommends it as the default production experience. It runs on the Standard tier (up to 5,000 nodes) with the 99.95% API server SLA and adds a pod readiness SLA: 99.9% of qualifying pod readiness operations complete within five minutes. It ships with Azure CNI Overlay powered by Cilium, a managed NAT gateway for egress, managed system node pools, node auto-provisioning for user nodes, HPA, KEDA and VPA, Azure RBAC, workload identity, deployment safeguards via Azure Policy, and managed Prometheus. Preconfigured features cannot be disabled. The node resource group is fully managed, so you cannot hand-edit what lives there.

Why the readiness SLA matters

Most SLAs cover the API server being reachable. That says little about whether your pod becomes Ready after a scale-out. AKS Automatic is the only one of the three with a documented pod-level service objective, which makes it attractive for teams that must put a number on “autoscaling works” for internal customers. It is also narrowly scoped (“qualifying operations”), so read the SLA text before relying on it contractually.

Deeper Analysis: Networking, Upgrades, Autoscaling

Networking and CNI

Pod networking is where the three platforms feel most different, and it is the decision hardest to reverse. Compare the models:

EKS with the Amazon VPC CNI gives pods real VPC IP addresses. That means security groups, flow logs and VPC routing apply to pods natively, and pods are directly addressable from other VPC resources. The price is IP consumption: a busy cluster can exhaust a subnet. The VPC CNI also supports network policy via eBPF; per the docs, standard mode defaults to allow until policies attach, and strict mode defaults to deny (you must then explicitly allow DNS). Requirements include VPC CNI 1.21 or later for standard and admin network policies and Linux kernel 5.10 or later.
GKE Dataplane V2 is built on Cilium and eBPF, runs as the anetd DaemonSet, enforces Kubernetes NetworkPolicy always-on without Calico, and provides network policy logging. It is on by default for new Autopilot clusters, but it can only be chosen at cluster creation for Standard; you cannot upgrade an existing cluster to it. Documented limits include up to 400,000 pods per cluster, custom eBPF programs are unsupported, and under heavy TCP connection churn anetd can consume two or three vCPUs per instance.
AKS Azure CNI Overlay gives only nodes VNet addresses; pods draw from a private CIDR, with each node taking a /24 block (up to 250 pods per node). Cluster maximum is 5,000 nodes. Traffic leaving the cluster is SNAT’d to the node IP, and inbound traffic needs a Service or ingress. The eBPF option is called Azure CNI Powered by Cilium and Microsoft recommends it. kubenet is on the retirement path: AKS stops supporting it on 31 March 2028.

The practical comparison is IP planning. With overlay networking on AKS you rarely think about VNet pod IP exhaustion. With the EKS VPC CNI you plan subnets carefully (or enable secondary CIDRs and prefix delegation, which the page I fetched does not cover, so check the VPC CNI documentation). GKE sits in the middle with alias IP ranges for pods in VPC-native clusters; I did not verify sizing details this run.

For policy, all three now converge on eBPF-based enforcement. If your security architecture depends on default-deny microsegmentation, our walkthrough of Kubernetes default-deny network policy with Cilium vs Calico covers the rollout steps that apply regardless of provider.

Release channels and version support windows

Upgrades are the second-largest hidden cost. Each provider’s policy has changed over the last two years, and the differences are financial as well as technical.

EKS. Standard support lasts 14 months after the EKS release date, followed by 12 months of extended support, for 26 months total. From the version table fetched this run: 1.34 reached EKS on 2 October 2025 with standard support ending 2 December 2026; 1.35 on 27 January 2026 (ends 27 March 2027); 1.36 on 2 June 2026 (ends 2 August 2027); and 1.37 on 1 October 2026 (ends 1 December 2027). The EXTENDED upgrade policy is the default for new and existing clusters, which means that if you do nothing, a cluster on 1.34 will start paying $0.60 instead of $0.10 per hour on 2 December 2026. To avoid that, set the cluster upgrade policy to standard, in which case the cluster is auto-upgraded at the end of standard support. If a cluster is not upgraded before extended support ends, the control plane is auto-upgraded to the oldest supported extended version. That default is the single most likely EKS surprise on a bill: a sixfold increase in the per-cluster fee, silently.

GKE. Clusters are enrolled in Rapid, Regular, Stable or Extended release channels, and the release schedule page publishes availability and auto-upgrade dates per minor version. For 1.35 the table shows Rapid availability on 24 December 2025, Regular on 11 February 2026, Stable on 7 April 2026, end of standard support on 11 April 2027 and end of extended support on 11 February 2028. The Extended channel receives extended support at the additional $0.50 per cluster-hour only while the cluster is in the extended period. Clusters not enrolled in a release channel follow the Stable schedule, and Google states it plans to remove the no-channel option on 14 June 2027. Autopilot clusters are always enrolled; the default is Regular.

AKS. The N-2 policy supports three GA minor versions at once. Per the support page, 1.35 went GA in March 2026 with end of life March 2027, 1.36 in June 2026 (EOL June 2027) and 1.37 in October 2026 (EOL October 2027); 1.38 is planned for February 2027. Long-term support requires explicit enrollment via the Premium tier and --k8s-support-plan AKSLongTermSupport, extending a version to roughly 24 months in total (for example, 1.34 from November 2025 community end of life November 2026 to LTS end November 2027). Clusters on N-3 get only platform-level support and a 60-day grace period, after which AKS performs a platform-initiated upgrade that does not follow your maintenance window, does not stop for deprecated API usage and can override a PodDisruptionBudget. The docs say these platform-initiated upgrades apply to unsupported versions starting 1 June 2027.

Dimension	EKS	GKE	AKS
Standard window	14 months	Roughly 15 to 17 months from Rapid availability (my calculation from the schedule table)	N-2: three GA minors, about 12 months of community support per version
Extended or LTS	12 more months at +$0.50 per hour	Extended channel, +$0.50 per hour only in the extended period	Premium tier LTS, 24 months total
Forced upgrade	Control plane auto-upgraded at end of extended support	Auto-upgrade per channel schedule	Platform-initiated upgrade after 60-day grace; can bypass PDBs
Auto-upgrade default	Opt in to standard policy to avoid extended fee	Channel based, Regular default for Autopilot	AKS Automatic uses stable channel to N-1

The strategic read: EKS charges you for being late, GKE schedules you through channels, and AKS forces you eventually and ignores your maintenance window when it does. Any of these punishes a team without an upgrade rhythm. Our look at Kubernetes 1.37 HPA scale to zero versus KEDA and Knative is a good example of the kind of feature drop that makes staying current worth it.

Node autoscaling: Karpenter everywhere, with different wrappers

The most notable convergence of 2026 is that two of the three clouds run Karpenter under the hood. EKS Auto Mode uses Karpenter to detect unschedulable pods and launch nodes. AKS node auto-provisioning (NAP) deploys and manages Karpenter on your cluster, based on the open-source project and the AKS Karpenter provider, and you define policy through NodePool and AKSNodeClass custom resources, with NodeClaims representing provisioned nodes. GKE takes a different lineage: node pool auto-creation extends the cluster autoscaler, and the unit of policy is the ComputeClass.

Figure 2: The provisioning loop shared by Karpenter-style autoscalers. Pending pods that do not fit drive a NodePool match, instance selection and launch; consolidation closes the loop.

The loop in Figure 2 explains why these tools reduce waste. A classic cluster autoscaler scales pre-defined node groups, so you must guess instance shapes ahead of time. A provisioner looks at the actual resource requests of pending pods and picks a fitting instance, then later consolidates by moving pods and terminating underused nodes.

Here is a minimal Karpenter-style NodePool of the kind you would author on EKS (self-managed Karpenter or Auto Mode custom pools) and, with an AKSNodeClass reference, on AKS NAP. The API group and nodeClassRef kind differ by provider, so treat this as a shape, not a copy-paste:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      nodeClassRef:
        group: karpenter.azure.com   # EKS uses eks.amazonaws.com or karpenter.k8s.aws
        kind: AKSNodeClass
        name: default
      expireAfter: 336h
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
  limits:
    cpu: "1000"

On GKE the equivalent intent is expressed as a ComputeClass with ordered priority rules:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-first
spec:
  priorities:
    - machineFamily: n2
      spot: true
    - machineFamily: n2
      spot: false
  whenUnsatisfiable: ScaleUpAnyway
  nodePoolAutoCreation:
    enabled: true

Pods select it with nodeSelector: {cloud.google.com/compute-class: cost-first}. The GKE docs note that workload-level auto-creation through ComputeClasses is available from version 1.33.3-gke.1136000, and that it removes the need for cluster-wide CPU and memory limits that older cluster-level node auto-provisioning required. They also warn that clusters with more than 200 node pools may see higher autoscaling latency, and that GKE prefers scaling existing compatible pools over creating new ones.

Differences that matter in practice:

Who owns the Karpenter version. On EKS Auto Mode and AKS NAP the provider runs it, so you cannot pin or patch it. On self-managed EKS you install Karpenter yourself and own its upgrades.
Default pool editing. EKS Auto Mode tells you not to edit the default NodePools and NodeClasses, but to add custom ones alongside them.
Limitations on AKS NAP. The docs list no Windows node pools, no IPv6 clusters, no service principals (use managed identity), no stopping a NAP-enabled cluster, and no changing the outbound type after creation.
Node lifetime. Auto Mode caps nodes at 21 days. Short lifetimes are good for patching, bad for pods with long warm-up and no PDB.

GPU support

All three clouds support NVIDIA GPUs and have their own accelerator story. EKS Auto Mode includes separate kernel drivers and plugins for NVIDIA and AWS Neuron devices, with custom NodePools used to select accelerated instance types. GKE lets you request GPUs in a ComputeClass or directly in the workload manifest, and the docs note that certain GPU series need minimum GKE versions (G4 needs 1.34.1-gke.1829001 or later; A4X needs 1.33.4-gke.1036000 or later). On AKS, the Automatic and NAP documentation pages I fetched do not address GPU support, so I make no claim about it here; consult the AKS GPU node pool documentation directly.

The structural point is billing. On GKE Autopilot, pods that select accelerators move from request-based billing to node-based billing: you pay for the whole node plus a premium. On EKS Auto Mode, the fee is attached to the instance, so a large GPU node carries a proportionally larger fee. If you run GPU fleets, the economics of the managed tier depend on how well you pack nodes; an idle eight-GPU node costs the same however it is managed. For the scheduling mechanics, see the GPU section of the Karpenter vs Cluster Autoscaler comparison.

Workload identity: three names for one idea

All three solve the same problem: give a pod short-lived cloud credentials without storing keys. Figure 3 shows the common flow.

Figure 3: A node-local agent exchanges the pod’s Kubernetes service account identity for a short-lived cloud token via the provider’s token service.

EKS Pod Identity. You create an association between an IAM role and a service account in a namespace. The EKS Auth service assumes the role, and the EKS Pod Identity Agent, a DaemonSet, hands credentials to the SDKs via a link-local address (169.254.170.23 for IPv4, with the agent on ports 80 and 2703). The role’s trust policy uses the single service principal pods.eks.amazonaws.com, so one role can be reused across clusters without editing its trust policy, unlike IRSA where each cluster’s OIDC provider appears in the policy. Limits from the docs: up to 5,000 associations per cluster, Linux EC2 nodes only (not Fargate, Windows, Outposts or EKS Anywhere), and each service account maps to one role in the cluster’s own account, so cross-account access uses role chaining or delegation. Associations are eventually consistent, so do not create them in a hot path. On Auto Mode you do not need to install the agent.

GKE Workload Identity Federation. Enabling it creates a fixed workload identity pool named PROJECT_ID.svc.id.goog. IAM policies reference workloads with principal:// for one ServiceAccount or principalSet:// for groups such as a namespace. A metadata server DaemonSet intercepts calls to the metadata endpoint and exchanges the Kubernetes token for a federated token from Security Token Service. Direct IAM access is the default pattern, with optional impersonation of an IAM service account for services that do not accept federated tokens. A policy binding looks like this:

gcloud projects add-iam-policy-binding my-project \
  --role roles/storage.objectViewer \
  --member "principal://iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/my-project.svc.id.goog/subject/ns/prod/sa/reader"

AKS Microsoft Entra Workload ID. AKS Automatic preconfigures workload identity and the OIDC issuer; on Standard you enable both on the cluster. The pod’s projected service account token is federated to an Entra application or managed identity. I did not fetch the full AKS workload identity page this run, so details such as federated credential limits are not stated here.

Comparison: EKS has the simplest trust policy story; GKE has the cleanest direct-to-IAM model with no intermediate service account in the default case; AKS integrates with Entra’s broader identity governance. The common failure mode on all three is the same: the node’s own instance identity is more privileged than the pod’s, and without blocking metadata access, pods can reach it.

Cost: Egress and the Other Bill

The control plane fee is visible. The following are not.

Data transfer and NAT

Compute is billed where you can see it; data transfer is billed everywhere else. The mechanics are cloud-specific, but the patterns are universal:

NAT processing. Private nodes reaching the internet or public cloud APIs go through NAT. For AWS the VPC pricing page gives an example rate of $0.045 per hour and $0.045 per GB processed for a NAT gateway in US East (Ohio). That means pulling 10 TB of container images or API traffic through one gateway in a month adds roughly $450 in processing fees alone, before any internet egress charge. (Arithmetic from the published rate; actual volume is yours.) Use VPC endpoints for S3, ECR and other AWS services to bypass NAT.
Cross-zone traffic. AWS notes data transfer charges apply when a NAT gateway and an EC2 instance are in different AZs. Chatty service meshes, cross-AZ database reads and cluster-wide log shippers all generate cross-zone traffic. The exact per-GB rates differ by cloud and region and I did not verify them this run, so check the EC2, Compute Engine and Azure bandwidth pages for your regions.
Internet egress. AWS gives 100 GB free per month across services; beyond that, tiered per-GB charges apply. Each cloud publishes different tiers, and egress to another cloud is billed as internet egress.
Image pulls and registries. Cross-region image pulls multiply with node churn, especially with 21-day node expiry or aggressive consolidation. Replicate images to the region you run in.

Managed tiers change where the leak is. AKS Automatic provisions a managed NAT gateway for egress and the docs say you cannot change the cluster outbound type after creation on NAP-enabled clusters, so egress design is a day-one decision there.

Compute pricing model differences

Model	Pay for	Wins when	Loses when
GKE Autopilot pod-based	Pod requests per second	Many small, bursty pods with honest requests	Over-requested pods; requests are the bill
EKS Auto Mode	EC2 instance plus per-second management fee	You want Karpenter with Savings Plans, Reserved Instances and Spot	Very large instances where the fee grows in absolute terms
AKS Automatic	VM costs on Standard tier	You want pod readiness SLA and defaults	You need to change preconfigured features

A worked illustration, with the numbers labelled as illustrative: suppose a service requests 2 vCPU and 8 GiB but uses 0.6 vCPU. On Autopilot pod-based billing at the published us-central1 container-optimized rates ($0.0445 per vCPU-hour and $0.0049225 per GiB-hour), the hourly bill is 2 x 0.0445 + 8 x 0.0049225 = $0.1283, regardless of usage. Right-sizing requests to 0.8 vCPU and 3 GiB would be 0.8 x 0.0445 + 3 x 0.0049225 = $0.0504, a 61% reduction. On node-based models the same over-request wastes node capacity that the autoscaler may or may not reclaim. Both paths reward right-sizing; Autopilot just makes it directly visible on the invoice.

Spot and committed-use options exist on all three. GKE’s page cites Autopilot Spot prices 60 to 91% lower than regular, and committed use discounts apply. EKS Auto Mode fees are billed independently of the instance purchase option. As with all numbers here, confirm in your region and currency.

Multi-Cluster and Fleet Strategy

Most organisations end up with more than one cluster: separate production and non-production, regional isolation, regulatory boundaries, or blast-radius control. The managed offerings handle this unevenly, and I verified only part of the picture this run, so this section is mostly design reasoning rather than product claims.

The first question is whether you need many clusters at all. With a flat $0.10 per cluster-hour, the fee argument for consolidation is weak: ten clusters cost about $730 a month in control plane fees. The stronger forces are operational. Each cluster needs its own add-ons, upgrade run, policy rollout and observability wiring. The managed tiers lower the per-cluster burden, because Auto Mode, Autopilot and Automatic automate the node layer, but they do not remove the need for consistent policy and identity across clusters.

Three patterns work across clouds:

Cluster per environment and region, shared GitOps. Use one Git repository with per-cluster overlays and a pull-based controller. This is provider-neutral and the lowest-risk way to stay portable.
Cluster per team with a platform layer. Teams get their own cluster, the platform team owns baselines for network policy, admission control and identity. Works best on the managed tiers where node ownership is already outsourced.
Multi-cloud for resilience. Rarely worth it. Cross-cloud service traffic is billed as internet egress, identity models differ (IAM roles, GCP principals, Entra identities), and the CNI semantics are not identical. If you need it, keep the data plane per cloud and share only the delivery pipeline.

Cross-cluster service connectivity is the hard part. Native options exist on each cloud (for example, GKE fleet features and AKS fleet management products), but I did not verify their current feature sets on official documentation this run, so I will not compare them. A pragmatic approach is a service mesh or Cilium cluster mesh layered on a consistent CNI. AKS Automatic’s Istio-based add-on is optional and, per the docs, is not auto-upgraded with the cluster, so you must upgrade it manually or it can block cluster auto-upgrades. That is an example of a hidden coupling: opting into a mesh turns an automatic platform into a partly manual one.

Finally, consider upgrade coordination. A fleet of twenty clusters on three different support windows becomes an upgrade calendar problem. EKS’s default extended policy, AKS’s N-2 with platform-initiated upgrades, and GKE’s channel auto-upgrades all create different deadlines. Standardise on one minor version per quarter fleet-wide and use the most restrictive provider’s window as your team’s cadence.

Decision Matrix

Figure 4 shows a rough decision flow. It is deliberately simple; the matrix below it adds nuance.

Figure 4: A first-pass decision flow for choosing among EKS, GKE and AKS. Existing cloud gravity dominates; egress exposure is the final check.

Criterion	EKS	GKE	AKS
Managed-node tier	Auto Mode, Karpenter and Bottlerocket-based nodes, 21-day max node lifetime	Autopilot, cluster or per-workload via ComputeClass	Automatic, preconfigured Standard tier, pod readiness SLA
Control plane fee	$0.10 per hour; $0.60 in extended support	$0.10 per hour; $74.40 monthly credit for zonal or Autopilot	Free tier or paid Standard and Premium
API server SLA	Verify on AWS SLA page	99.95% regional or Autopilot, 99.5% zonal	99.95% with zones, 99.9% without
Default pod networking	VPC CNI, VPC IPs for pods	Dataplane V2 (Cilium), default on Autopilot	Azure CNI Overlay with Cilium on Automatic
Node autoscaling	Karpenter (Auto Mode managed or self-run)	Cluster autoscaler plus node pool auto-creation, ComputeClass	Karpenter-based NAP
Version support	14 months plus 12 extended	Channel based, Extended channel	N-2, LTS on Premium
Pod identity	EKS Pod Identity or IRSA	Workload Identity Federation	Entra Workload ID
Strongest fit	AWS-centric teams needing VPC-native pods and the AWS ecosystem	Teams wanting the least node operations and per-pod billing	Microsoft-centric teams wanting guardrails and Entra integration
Watch out for	Silent extended-support fee, subnet IP exhaustion	Dataplane V2 only at creation, hardware-pinned workloads leave pod billing	Platform-initiated upgrades, locked preconfigured features

How to read it. If your data, identity provider and security tooling already live in one cloud, that cloud’s Kubernetes wins about nine times in ten, because identity, private networking and data gravity outweigh feature differences. If you are greenfield, the honest differentiators are (a) how opinionated a tier you want, (b) how much you value pod-level billing, and (c) which ecosystem you already staff for.

My opinion, labelled as such: GKE Autopilot is the most coherent “just run my pods” product because billing, scaling and node management share one model; EKS Auto Mode is the best fit if you want Karpenter and EC2 purchasing options without running it yourself; AKS Automatic has the most explicit guardrails and the only pod-level readiness SLA. None dominates.

Trade-offs, Gotchas, and What Goes Wrong

Managed means constrained. The hands-off tiers remove choices. EKS Auto Mode disallows SSH and SSM, so debugging relies on kubectl debug and logs. AKS Automatic’s preconfigured features cannot be disabled and the node resource group is locked. GKE Autopilot requires allowlists or admission controls for privileged workloads, and new Autopilot clusters start with zero nodes, so the first deployment is slower. If you run kernel modules, custom CNI plugins, or privileged agents, you may not fit.

Disruption collides with PDBs. Short node lifetimes and automatic upgrades interact with PodDisruptionBudgets. AWS notes that blocking PDBs can prevent updates and require your intervention before the 21-day limit. AKS platform-initiated upgrades can override a PDB entirely. A PDB that allows zero disruptions is not protection; it is a deferred outage.

Add-on coupling. An optional add-on can pull you out of automatic operations. The AKS Istio add-on not auto-upgrading with the cluster is one documented case. On GKE, third-party eBPF tools such as Retina can conflict with Dataplane V2 and block pod access to services, per the docs.

Irreversible choices. Dataplane V2 on GKE is a creation-time decision. The AKS outbound type cannot be changed on NAP clusters. Pod CIDRs on AKS overlay can be expanded but not shrunk or replaced. EKS subnet sizing is awkward to fix after the fact. Treat networking as the part of the design you review twice.

Visibility changes. EKS Auto Mode hides managed instances from EC2 console views and API list operations by default for new resources since 22 April 2026, which can confuse cost and inventory tooling until you adjust the managed resource visibility settings.

Deprecations. Azure Linux 2.0 node images are frozen and scheduled for removal on 31 October 2026, Azure Network Policy Manager support ends on Windows nodes on 30 September 2026 and on Linux on 30 September 2028, and kubenet ends on 31 March 2028. Calendar these now.

Benchmark caveat. I have not cited cluster-to-cluster performance benchmarks here because the vendor documentation does not publish comparable ones, and third-party benchmarks vary with instance types and CNI versions. Run your own test with your workloads.

Surprise bills. The recurring ones: EKS extended support defaulting on, NAT processing for image and API traffic, cross-zone chatter, and over-requested pods on request-billed Autopilot.

Practical Recommendations

Start from the cloud where your data and identity already live; moving Kubernetes is the easy part and moving everything around it is not. Within that cloud, default to the managed tier (Auto Mode, Autopilot or Automatic) for new application platforms, and drop to the standard mode only when you hit a documented constraint such as privileged agents, Windows nodes on NAP, or custom kernel needs.

For upgrade policy, decide on purpose. On EKS, either budget for extended support or set the standard upgrade policy and own the cadence. On GKE, pick a channel per environment: Rapid or Regular for dev, Regular or Stable for production, Extended only where you need the longer window and accept the fee. On AKS, run N-1, enable planned maintenance, and only pay for Premium LTS when you have a real reason.

For networking, pick the CNI model before the first cluster and document the IP plan. For policy, move to default-deny early.

A short checklist:

[ ] Confirm control plane SLA text and your region’s pricing on the vendor pages before budgeting.
[ ] Set the EKS upgrade policy explicitly, or alert on the extended-support start date for each version.
[ ] Enrol every GKE cluster in a release channel; plan for the removal of no-channel clusters on 14 June 2027.
[ ] On AKS, stay inside N-2 and calendar the 1 June 2027 platform-initiated upgrade rule.
[ ] Right-size pod requests; on Autopilot they are the bill.
[ ] Use private endpoints or VPC endpoints for cloud APIs and registries to avoid NAT processing.
[ ] Use Pod Identity, Workload Identity Federation or Entra Workload ID; block pod access to node credentials.
[ ] Add PDBs that allow at least one disruption, and test a node-expiry cycle.
[ ] Adopt default-deny network policy and log denials.
[ ] Re-run this checklist each quarter; the pricing and support pages change.

Frequently Asked Questions

Which is cheapest: EKS, GKE or AKS?

There is no universal winner. The control plane fee is about $0.10 per cluster-hour on EKS and GKE, and AKS offers a Free tier without an SLA or a paid Standard tier. At realistic scale, node compute, purchase options and data transfer dominate. GKE’s $74.40 monthly credit can cover one zonal or Autopilot cluster, which helps small setups. Model your own request sizes, instance mix and egress before deciding; the managed-tier pricing models differ enough that workload shape decides.

What is EKS Auto Mode and how is it billed?

EKS Auto Mode lets AWS manage the data plane as well as the control plane: compute autoscaling with Karpenter, networking, load balancing, DNS, block storage and GPU support are built in. Nodes use Bottlerocket-based images with no SSH or SSM access and are replaced within 21 days. You pay the normal EC2 price plus a per-second Auto Mode fee tied to the instance type, independent of the purchase option such as Spot or Savings Plans.

How does GKE Autopilot differ from GKE Standard?

In Autopilot, Google manages nodes, scaling, security configuration and upgrades. General-purpose workloads are billed on pod resource requests per second, not on nodes. Pods that need specific hardware, like accelerators, are billed on the full node plus a management premium. You can also run Autopilot compute classes inside a Standard cluster. Standard gives you node control and Compute Engine pricing for node pools, at the cost of managing sizing and some upgrade decisions yourself.

Is AKS Automatic production ready?

Microsoft recommends AKS Automatic as the default production experience. It runs on the Standard tier with a 99.95% API server SLA and adds a 99.9% pod readiness SLA within five minutes for qualifying operations. It comes preconfigured with Azure CNI Overlay powered by Cilium, node auto-provisioning, workload identity and deployment safeguards. The tradeoff is that preconfigured features cannot be disabled, so confirm your workloads fit the guardrails, and note the docs do not state GPU support on that page.

Which CNI is better: VPC CNI, Dataplane V2 or Azure CNI Overlay?

They solve different problems. The VPC CNI gives pods real VPC addresses, which simplifies security groups and routing but consumes subnet IPs. GKE Dataplane V2 is Cilium-based, enforces network policy by default and is a creation-time choice. Azure CNI Overlay saves VNet addresses by using a private pod CIDR, with Cilium as the recommended eBPF option. Choose based on IP availability, policy needs and whether external systems must reach pods directly.

How long are Kubernetes versions supported on each platform?

EKS supports each version for 14 months in standard support plus 12 in extended support, with extended support costing an extra $0.50 per cluster-hour. AKS supports three GA minors at a time and offers 24-month LTS on the Premium tier. GKE uses release channels with published per-version dates, and an Extended channel for the longer window at an additional $0.50 per hour while in the extended period. Always read the live schedule pages.

Managed Kubernetes in 2026: EKS vs GKE vs AKS on Networking, Upgrades, Autoscaling and Cost