EKS 1.34 end of support: the 2 December price jump

Kubernetes 1.34 reaches upstream end of life on 27 October 2026, but that is not the date that changes your AWS bill. EKS 1.34 end of support (the end of standard support) is 2 December 2026, and from 00:00 UTC that day every 1.34 cluster on the default upgrade policy bills at $0.60 per cluster-hour instead of $0.10. Below are the provider dates side by side, the cost arithmetic, and the upgrade order we would run.

All dates are as of 26 October 2026 and come from each provider's own lifecycle page.

Platform	Kubernetes 1.34 date	What happens
Upstream Kubernetes	27 Oct 2026	End of life; the project stops patching 1.34
Amazon EKS	2 Dec 2026 standard ends; 2 Dec 2027 extended ends	Moves into paid extended support by default
Azure AKS	Nov 2026 end of life; Nov 2027 with LTS	Platform support, then a platform-initiated upgrade
Google GKE	25 Jan 2027 standard ends; 25 Nov 2027 extended ends	Auto-upgrade unless the cluster is on the Extended channel

Why the upstream date and the EKS 1.34 end of support date differ

EKS counts from its own release, not from upstream. AWS gives each minor version 14 months of standard support after it first becomes available on EKS, "even if upstream Kubernetes no longer supports a version", and backports security patches in the meantime. EKS released 1.34 on 2 October 2025, so standard support runs to 2 December 2026.

Upstream works on a shorter clock. The Kubernetes project says releases from 1.19 onwards get approximately one year of patch support, which is why 1.34 is listed as end of life on 2026-10-27. If a summary tells you EKS 1.34 support ends on 27 October, it has quoted the upstream calendar, not the AWS one.

What EKS extended support costs from 2 December

EKS extended support costs $0.60 per cluster-hour, against $0.10 for standard support. AWS prices it as standard support plus $0.50 per cluster-hour. Billing starts at the beginning of the day the version reaches end of standard support, in UTC+0, and extended support is enabled by default for new and existing clusters.

The arithmetic below uses illustrative inputs: 730 hours as an average month, and a hypothetical fleet of six 1.34 clusters. Only the two hourly rates come from AWS.

Illustrative case	Arithmetic	Result
One cluster, standard, per month	730 h × $0.10	$73
One cluster, extended, per month	730 h × $0.60	$438
Extra cost per cluster per month	$438 − $73	$365
Extra for 2–31 December 2026, one cluster	30 days × 24 h × $0.50	$360
Extra per month, six clusters	6 × $365	$2,190

The strongest case for paying is real. Extended support keeps control plane security patches flowing for 12 more months, plus patches for the VPC CNI, kube-proxy and CoreDNS add-ons and the EKS optimised AMIs. If a removed API or an unready Helm chart blocks your move to 1.35, $365 a month per cluster is cheaper than a rushed upgrade. Paying is the wrong choice when the only blocker is that nobody has scheduled the work.

How to check, and disable, EKS extended support before 2 December

The cluster upgrade policy decides what happens at end of standard support. Read it with the command from the EKS upgrade policy docs:

aws eks describe-cluster \
--name <cluster-name> \
--query "cluster.upgradePolicy.supportType"

EXTENDED means the cluster will enter paid extended support. To opt out, AWS documents setting the policy to STANDARD:

aws eks update-cluster-config \
--name <cluster-name> \
--upgrade-policy supportType=STANDARD

Two catches. You cannot disable extended support once a cluster has entered it, so this has to happen before 2 December. And a STANDARD policy does not freeze the cluster: AWS auto-upgrades it to the next version at the end of standard support, so treat the switch as a commitment to upgrade, not a way to avoid one.

The EKS 1.31 deadline arrives first, on 26 November

EKS 1.31 extended support ends on 26 November 2026, six days before the 1.34 price change. After that date AWS auto-upgrades the control plane only, to the earliest supported version, through a gradual rollout. AWS states it "can't provide specific time frames" and that you won't receive any notification before the update.

Managed node groups and self-managed nodes stay on the previous version; EKS Auto Mode nodes may update automatically. Fargate Pods keep their old kubelet until you redeploy them. A cluster that AWS upgraded at the end of extended support cannot be rolled back, unlike the seven-day rollback window you get on an upgrade you ran yourself. EKS 1.32 is next in line: its extended support ends on 23 March 2027.

AKS 1.34 end of life and the GKE 1.34 dates run on separate clocks

AKS: November 2026, and LTS is never switched on for you

AKS lists 1.34 end of life as Nov 2026, and its calendar note says a month-only date means the last day of that month, so 30 November. A 1.34 cluster then sits in platform support until 1.38 GA, with a 60-day grace period before AKS upgrades it. The calendar gives Jun 2027 as the planned platform-initiated upgrade month for non-LTS 1.34, and those upgrades ignore your maintenance window and can override a Pod Disruption Budget.

Do not read February 2028 as the standard deadline: that month belongs to the LTS table. AKS 1.34 LTS ends in Nov 2027, with a platform-initiated upgrade planned for Feb 2028, but LTS requires the Premium tier and an explicit support plan, and AKS says enrolment is never automatic. A supported non-LTS cluster must also upgrade one minor version at a time.

GKE: the latest standard date of the three

GKE ends 1.34 standard support on 25 January 2027 and extended support on 25 November 2027. Only clusters on the Extended channel can stay that long; Google says extra charges apply once the minor version enters extended support, and other clusters are auto-upgraded. On GKE, 1.31 extended support already ended on 22 October 2026, and 1.32 follows on 11 February 2027.

Can you skip Kubernetes versions when upgrading EKS?

No. EKS upgrades one minor version at a time, so a 1.33 cluster reaches 1.35 through 1.34. Before each control plane step, managed and Fargate nodes must match the control plane's minor version, and the update needs up to five free IP addresses in the cluster subnets. Here is the order we would run:

1. Inventory every cluster with aws eks describe-cluster-versions and the upgrade-policy query above.
2. Move anything on 1.31 first; 26 November is the earliest deadline and comes without warning.
3. Check upgrade insights for deprecated API usage. AWS notes insights look back over a rolling 30-day window.
4. Upgrade 1.34 control planes with aws eks update-cluster-version --name <cluster-name> --kubernetes-version 1.35 --region <region-code>.
5. Bring node groups up to match, for example eksctl upgrade nodegroup --name=node-group-name --cluster=my-cluster --region=region-code --kubernetes-version=1.35, then update the VPC CNI, CoreDNS and kube-proxy add-ons.

Look past 1.35 before you stop. EKS 1.35 standard support ends on 27 March 2027, four months after the 1.34 date, while 1.36 runs to 2 August 2027. If you have the window, carrying on to 1.36 saves you a second scramble in March. Newer releases also bring features worth having, such as the new Unused condition for PVCs in 1.37.

The decision to make before 2 December

On EKS, each 1.34 cluster needs one of three answers this month: upgraded, set to STANDARD with an upgrade booked, or knowingly left on EXTENDED with a budget line. On AKS, decide whether a 1.34 cluster justifies Premium tier LTS before 30 November. On GKE you have until 25 January, which makes it the natural last item in the queue.

If you would rather hand the fleet inventory and upgrade sequencing to someone else, that is the work our DevOps and cloud engineering team does, and our Kubernetes implementation practice covers the node group and add-on steps that the control plane auto-upgrade leaves behind.