Amazon EKS in 2026: 1.37, $0.60 Extended Support and Auto Mode Explained

The Amazon EKS line item I most want every AWS customer to understand is "extended support". It means a cluster is running a Kubernetes version more than about 14 months past its EKS release, and AWS is charging six times the normal control plane rate to keep patching it. Explaining that line drags in most of what changed in Amazon EKS this year, so this post covers it all: which Kubernetes versions EKS supports in October 2026, what standard and extended support cost, what EKS Auto Mode manages for its fee, Pod Identity versus IRSA, Hybrid Nodes, upgrade cadence, and when EKS is the right choice. Every number comes from AWS documentation, pricing pages and release notes as they read this week.

Which Kubernetes versions does Amazon EKS support in October 2026?

As of 24 October 2026, the EKS version lifecycle page lists four versions in standard support (1.34, 1.35, 1.36, 1.37) and three in extended support (1.31, 1.32, 1.33). Each minor version gets 14 months of standard support from the day it lands on EKS, then 12 months of extended support, 26 months in total. After that, the control plane is upgraded for you.

Version	Upstream release	On EKS	End of standard	End of extended	Status on 24 Oct 2026
1.37	26 Aug 2026	1 Oct 2026	1 Dec 2027	1 Dec 2028	Standard
1.36	22 Apr 2026	2 Jun 2026	2 Aug 2027	2 Aug 2028	Standard
1.35	17 Dec 2025	27 Jan 2026	27 Mar 2027	27 Mar 2028	Standard
1.34	27 Aug 2025	2 Oct 2025	2 Dec 2026	2 Dec 2027	Standard, 39 days left
1.33	23 Apr 2025	29 May 2025	29 Jul 2026	29 Jul 2027	Extended
1.32	11 Dec 2024	23 Jan 2025	23 Mar 2026	23 Mar 2027	Extended
1.31	13 Aug 2024	26 Sep 2024	26 Nov 2025	26 Nov 2026	Extended, 33 days left

Source: Amazon EKS Kubernetes release calendar. Day counts are mine, from 24 October 2026.

Two dates matter this quarter. Version 1.31 reaches the end of extended support on 26 November 2026, after which AWS upgrades remaining control planes "through a gradual deployment process", at no specified time and without notice. Only the control plane moves: managed and self-managed nodes stay behind (Auto Mode nodes may follow), add-ons are untouched, and the upgrade cannot be rolled back. On 2 December, 1.34 leaves standard support and, under the default policy, starts paying the extended rate.

EKS shipped every version in that table 36 to 44 days after upstream. The per-version notes are where the upgrade work hides: no Amazon Linux 2 AMIs after 1.32, containerd 1.x supported only up to 1.35, the kubelet refusing cgroup v1 by default from 1.35, the gitRepo volume disabled in 1.36, and in 1.37 SELinux mount labelling on by default (pods sharing a volume with different labels can stick in ContainerCreating) plus three removed cAdvisor metrics. Details are in the standard support release notes and the extended support notes.

How much does EKS extended support cost?

The EKS pricing page charges $0.10 per cluster per hour in standard support and $0.60 per cluster per hour in extended support, which it describes as standard plus $0.50. Extended support was free while it was in preview; the $0.60 rate has applied since the April 2024 billing cycle, according to the pricing announcement from January 2024.

Over a 730-hour month that is $73 against $438. Over a year it is $876 against $5,256, so every cluster left in extended support costs an extra $4,380 a year. Ten forgotten clusters is $43,800 a year. Against a node bill it is rarely the biggest line, but it is the purest waste: money spent because nobody owned the upgrade.

The switch that decides what happens is the cluster's upgrade policy. It defaults to EXTENDED for new and existing clusters, so a cluster drifts into the $0.60 rate silently. Set it to STANDARD and the cluster is instead auto-upgraded at the end of standard support. You cannot make that change once the cluster is already in extended support; the only way out then is to upgrade. Rolling back into an extended-support version, which became possible this year, also restarts the extended charge.

Before deciding anything, find out where you stand. This read-only script prints one line per cluster in a region:

#!/usr/bin/env bash
# eks-support-audit.sh: one line per EKS cluster with its Kubernetes version,
# support status, end of standard support, upgrade policy and Auto Mode flag.
# Read-only API calls. Written against the 2026 EKS API reference; needs AWS CLI v2 and jq 1.7.
# Usage: REGION=eu-west-1 ./eks-support-audit.sh
set -euo pipefail
REGION="${REGION:-us-east-1}"

# The version calendar from the EKS API. versionStatus replaces the deprecated status field.
# Dates come back in US Pacific time, so they read one day earlier than the UTC calendar.
CAL=$(aws eks describe-cluster-versions --region "$REGION" --include-all \
  --query 'clusterVersions[].{v:clusterVersion,s:versionStatus,eos:endOfStandardSupportDate}' \
  --output json)

printf '%-28s %-6s %-18s %-11s %-9s %s\n' CLUSTER VER STATUS END_STD POLICY AUTO_MODE
for c in $(aws eks list-clusters --region "$REGION" --query 'clusters[]' --output text); do
  read -r ver pol auto < <(aws eks describe-cluster --region "$REGION" --name "$c" \
    --query 'cluster.[version, upgradePolicy.supportType, computeConfig.enabled]' --output text)
  row=$(jq -r --arg v "$ver" '.[] | select(.v == $v) | "\(.s) \(.eos[0:10])"' <<<"$CAL")
  # shellcheck disable=SC2086  # row deliberately splits into two columns
  printf '%-28s %-6s %-18s %-11s %-9s %s\n' "$c" "$ver" ${row:-UNKNOWN -} "$pol" "$auto"
done

What does EKS Auto Mode manage, and what does it cost?

EKS Auto Mode launched at re:Invent on 1 December 2024. It puts the data plane under AWS management: Karpenter-based autoscaling, pod networking with network policy, load balancer integration, cluster DNS, EBS storage and GPU drivers become core components instead of add-ons you upgrade. Nodes are EC2 managed instances running Bottlerocket with SELinux enforcing, a read-only root and no SSH or SSM. They live at most 21 days, and after a control plane upgrade Auto Mode rolls them for you, respecting PodDisruptionBudgets. The application, VPC and cluster configuration stay yours.

Two 2026 changes are easy to miss: since 22 April, new Auto Mode instances are hidden by default from EC2 console views and list APIs (inventory scripts will undercount), and from 1.37, new NodePools that don't set consolidationPolicy default to Balanced.

The price is a per-instance management fee, billed per second on top of EC2. AWS publishes no formula, but in each pricing-page example the fee is 12 percent of the On-Demand price: $0.03672 an hour on a c6a.2xlarge that costs $0.306. The key sentence is that Auto Mode charges "are independent of the EC2 instance purchase option", so Spot and Savings Plans cut the instance price, not the fee. As an illustration, if a Spot c6a.2xlarge ran at 30 percent of On-Demand, the same $0.03672 would be 40 percent of what you pay for the instance.

My read: Auto Mode is good value for a team without a dedicated platform engineer, because node, AMI and CNI upgrades are exactly the work that gets skipped. A team already running Karpenter well (it reached v1.15.1 on 23 October) on discounted capacity will usually find staying put cheaper. The trade-offs between the two autoscalers are in my Kubernetes autoscaling explainer.

EKS Pod Identity vs IRSA: which should you use in 2026?

AWS's own guidance is now blunt: use EKS Pod Identity "whenever possible". IRSA still works and still has a place, but the comparison is lopsided.

Attribute	EKS Pod Identity	IRSA
Role trust	Trust pods.eks.amazonaws.com once	Edit the trust policy for every new cluster's OIDC issuer
IAM OIDC provider	Not needed	One per cluster; IAM default limit of 100 per account
Service accounts per role	No per-service-account trust entries	About 4 per trust policy at the default 2,048-character limit, about 8 if raised
Session tags for ABAC	Cluster, namespace and service account tags	Not supported
STS calls	EKS Auth service assumes the role, agent hands out credentials per node	Each pod's SDK calls AssumeRoleWithWebIdentity
Runs on	Linux EC2 nodes in EKS; Hybrid Nodes	EKS, EKS Anywhere, ROSA, self-managed Kubernetes on EC2
Fargate, Windows nodes	Not supported	The remaining option
Limit	5,000 associations per cluster	Bounded by OIDC provider and trust policy size

Sources: service account comparison, Pod Identity limits and restrictions, Hybrid Nodes add-ons.

Pod Identity needs its agent DaemonSet on each node (Auto Mode excepted), listening on link-local 169.254.170.23, so add that address to NO_PROXY behind a proxy. Cross-account access, once a reason to keep IRSA, now works through a target role that EKS chains to. I would migrate IRSA roles as you touch them, not in a big bang, and keep IRSA for Fargate and Windows. The general pattern behind both is covered in my workload identity federation explainer.

EKS Hybrid Nodes: what they are and what they cost

EKS Hybrid Nodes let servers or VMs in your own data centre or edge sites join an EKS cluster as nodes. AWS runs the control plane; you run and upgrade the machines. Pricing is per vCPU-hour while a node is attached: $0.020 for the first 576,000 vCPU-hours a month, then $0.014, $0.010 and $0.008 in further tiers, down to $0.006 above 11.52 million, aggregated per region and account. Billing counts vCPUs as reported to Kubernetes, so a hyperthreaded physical core counts as two. Ten servers that each report 32 vCPUs, attached all month, come to 233,600 vCPU-hours, or $4,672, which is $14.60 per vCPU per month.

The fine print shapes where it fits. You need a reliable link to the VPC (VPN or Direct Connect); AWS says Hybrid Nodes are not for disconnected or intermittent sites, where EKS Anywhere is the product. The VPC CNI doesn't work on hybrid nodes, so Cilium 1.17 or 1.18 is the supported CNI, and the feature isn't offered in GovCloud or China. It suits GPUs you already own, data that can't leave a building, or latency to a factory floor. The fee buys a managed control plane, not managed nodes.

How often do you have to upgrade EKS, and what got safer in 2026?

EKS released 1.31 through 1.37 at intervals of 117 to 126 days. With 14 months of standard support and in-place upgrades limited to one minor version at a time, staying out of extended support means about three minor upgrades a year. You can batch them into one maintenance window, but you can't skip versions.

Three things made those upgrades less frightening this year. First, upgrade insights check every cluster daily for deprecated API usage, kubelet and kube-proxy skew, incompatible add-ons and health problems, and since August 2025 you can refresh them on demand. In March 2025 AWS began blocking upgrades with ERROR insights unless you passed --force, then rolled that back because Terraform and other tools couldn't pass the flag. The upgrade docs still say the rollback is in effect, so insights are advice, not a gate.

Second, since 1 July 2026 you can roll a control plane back one minor version within 7 days of an in-place upgrade, at no extra charge, with etcd data and workloads preserved. Auto Mode nodes roll back automatically; you must move managed node groups and other nodes back first, and downgrade incompatible add-ons. It is a safety net with holes, but before July the only "rollback" was a new cluster.

Third, Auto Mode clusters skip the data plane half of the job entirely. For everyone else, I wrote the full sequence, with commands, in the step-by-step EKS upgrade guide.

This is where platform discipline earns its keep: three upgrades a year per cluster is a recurring task, and the more manifests are generated rather than written, the more the pre-upgrade scan matters.

Is EKS the right choice in 2026?

If you are already on AWS and running more than a handful of services, usually yes. The $73 a month control plane is noise next to node spend, and IAM, VPC networking and load balancers integrate without glue code. The ceiling is high: EKS has supported 100,000 worker nodes per cluster since July 2025. Provisioned Control Plane pins control plane capacity in XL to 8XL tiers for $1.65 to $13.90 an hour extra, with a 99.99% SLA instead of 99.95%, though AWS says standard mode suits most clusters. EKS Capabilities, announced on 30 November 2025, run managed Argo CD, ACK and kro in AWS-owned accounts; Argo CD costs $0.03 per capability hour plus $0.0015 per Application hour.

It is the wrong choice when the workload doesn't need Kubernetes. Three stateless services and a queue run happily on ECS with Fargate or on Lambda, neither of which asks for three version upgrades a year. I went through that judgement in more depth in Is Kubernetes Still Worth It in 2026?. EKS is also a poor fit if nobody will own upgrades, because the platform charges you for neglect at $0.50 an hour per cluster and then upgrades you anyway.

FAQ

How much does an EKS cluster cost per month?

The control plane costs $0.10 an hour (about $73 a month) in standard support and $0.60 (about $438) in extended support. Nodes, EBS, load balancers, public IPv4 and cross-AZ traffic are billed separately, and Auto Mode and Provisioned Control Plane add their own fees.

What happens when EKS extended support ends?

EKS upgrades the control plane to the oldest supported version at some point after the end date, without advance notice. Nodes and add-ons are not upgraded, so skew and add-on compatibility become your problem immediately, and the upgrade cannot be rolled back.

Can I downgrade an EKS cluster?

Since July 2026, yes, within limits: one minor version back, within 7 days of an in-place upgrade, and only if you roll back managed node groups and incompatible add-ons first. After 7 days the only route is a new cluster on the older version and a workload migration.

Is EKS Auto Mode worth the fee?

For small teams, usually: the fee (12 percent of On-Demand in AWS's examples) replaces node patching, AMI rotation and add-on upgrades that otherwise need a person. For large fleets on Spot or Savings Plans the fee doesn't shrink with the discount, so self-managed Karpenter is often cheaper if you have the skills to run it.

This quarter I would run the audit script against every region, get anything on 1.31 off it before 26 November, and schedule 1.34 clusters for an upgrade before 2 December. I would set the upgrade policy to STANDARD on development clusters, so forgetting costs a forced upgrade in a place where that's survivable, and keep EXTENDED on production with an alarm on the status rather than the bill. New workloads get Pod Identity by default, and I would pilot Auto Mode on one non-critical cluster and compare its fee with the hours the last node upgrade actually took.

Related: Kubernetes Cost Optimization in 2026, Ingress NGINX Is Retired: What Replaces It and Kubernetes Security in 2026.