Amazon EKS Version End of Life: 14 Months of Standard Support, Then the Bill Is the Notification — Every Version's Dates and the 6× Price

Published: August 11, 2026  ·  EOL Watch — deadline coverage  ·  Dates verified against AWS's EKS release calendar and pricing page, and our tracked lifecycle data — methodology

Most software tells you it has reached end of life through a CVE that never gets patched. Amazon EKS tells you through your AWS bill. When a Kubernetes version on EKS leaves standard support, nothing breaks, nothing stops, and no action is required of you — which is precisely the trap. Per AWS's EKS documentation, every new and existing cluster carries an upgrade policy that defaults to EXTENDED, meaning the cluster is enrolled in extended support automatically: no opt-in, no confirmation step. What changes is the control-plane price, per AWS's EKS pricing page: from $0.10 per cluster per hour to $0.60 per cluster per hour — six times the rate, roughly $438 a month per cluster instead of $73. Billing starts, per AWS's release calendar, at the beginning of the end-of-standard-support day in UTC.

This is not a hypothetical. EKS 1.33 left standard support on July 29, 2026 — two weeks ago. Every 1.33 cluster whose owner did not upgrade in time has been metering at the extended-support rate since that morning. A meaningful share of the teams paying it will discover the fact the way most teams do: not from the AWS Health Dashboard notice that went out months earlier, but from a Cost Explorer line item that is suddenly six times larger than it was in July.

And the meter is not the end of the story. Extended support lasts 12 months per version. After that, AWS states that the cluster control plane is auto-upgraded — its documentation puts it plainly: "your cluster is auto-upgraded to the oldest currently supported extended version" — through a gradual deployment process that can begin at any time after the end date, with no notification before the update. EKS 1.31's extended support ends November 26, 2026: any 1.31 cluster still running that day is in force-upgrade territory.

How the EKS clock actually works — and why it isn't the upstream Kubernetes clock

Upstream Kubernetes supports each minor version for roughly 14 months, and the community releases a new minor about every four months — the cadence covered in our Kubernetes end-of-life guide. EKS runs its own clock on top of that. Per AWS's version lifecycle documentation, the 14 months of standard support are measured from the day the version becomes available on EKS, which is typically one to two months after the upstream release. That lag works in your favor: AWS commits to backporting applicable security patches even after upstream support ends, so an EKS version's standard window always outlives its upstream twin — and the extended window runs a further year beyond that, for 26 months of patched life in total.

AWS announces each end-of-standard-support date at least 60 days in advance, and sends a Health Dashboard notice to affected accounts roughly 12 months after the version's EKS release. Those notices are real, but they arrive in the same channel as every other AWS operational notice — which is why, in practice, the price change is the notification that lands.

Every Amazon EKS version's support dates

This is the full table — every Kubernetes version EKS has shipped, from the current 1.36 back to 1.18. The middle column is the date the 6× meter starts; the right column is the date AWS takes the upgrade decision out of your hands. Dates come from our tracked lifecycle data, cross-checked against AWS's published release calendar, and each version links to its lifecycle page with live status and risk score.

Dates from our tracked dataset (verification pass 2026-08-11), cross-checked against AWS's EKS Kubernetes release calendar. Between the two right-hand dates the cluster is in extended support and the control plane bills at $0.60 per cluster per hour instead of $0.10, per AWS's pricing page; billing starts at the beginning of the end-of-standard-support day (UTC). Versions 1.20 and earlier predate the extended-support program and have no extended-support dates. AWS marks far-future dates as approximate until finalized; we list the currently published dates.

The bill is the notification

Run the numbers on what auto-enrollment means. A single cluster in extended support costs an extra $0.50 per hour — about $365 more per month, $4,380 more per year, taking the control-plane line from roughly $876 to roughly $5,256 a year. That is per cluster: the fee attaches to every cluster on the old version, so the standard dev/staging/prod trio on EKS 1.33 has been accruing an extra ~$1,095 a month since July 29. Organizations that treat clusters as cheap disposable units — one per team, one per environment, one per region — multiply the meter accordingly.

It is worth being precise about what the money buys, because it is not nothing. Per AWS's documentation, extended support means the control plane keeps receiving security patches, AWS also patches the core add-ons (VPC CNI, kube-proxy, CoreDNS) and its published EKS-optimized AMIs for the version, and technical support continues. It is a legitimate product — deliberately priced so that using it as a parking space hurts. AWS's stated rationale is security: past roughly a year beyond upstream EOL, the Kubernetes community stops patching and discourages CVE reports against dead versions, so AWS refuses to let control planes sit on unsupported versions at any price.

EKS is the second AWS product this year to route end-of-life through the billing system rather than the incident channel — RDS for MySQL 8.0 did the same on August 1, with the same automatic-unless-disabled enrollment. The pattern is worth internalizing: on AWS, a version deadline is increasingly a pricing event, and the teams that find out late are the ones whose lifecycle tracking lives in Cost Explorer.

What happens at the end of extended support: the force-upgrade

Extended support is a 12-month window, not a destination, and AWS is unusually explicit about what happens when it closes. Per the EKS documentation: clusters that complete the 26-month lifecycle are automatically upgraded to the oldest version still in extended support. The update is gradual, can begin at any time after the end-of-extended-support date, and comes with no notification before it happens — AWS says it cannot provide specific time frames and recommends not relying on the automatic process. Two details make this sharper than it first sounds:

Only the control plane moves. The auto-upgrade covers the EKS control plane (and EKS Auto Mode nodes may update). Self-managed nodes, managed node groups, Fargate pods and add-ons stay where they were — meaning an ignored cluster ends up with a control plane one or more versions ahead of its nodes. Kubernetes tolerates limited version skew, but a cluster assembled by inaction is not a configuration anyone tested. And per AWS's rollback policy, a cluster that was auto-upgraded at the end of extended support cannot be rolled back.

The next force-upgrade date is November 26, 2026. That is when EKS 1.31's extended support ends — the version has already been in the 6× tier since November 26, 2025, so any cluster still on it has paid roughly a year of extended-support fees on the way to a forced migration. EKS 1.32 follows on March 23, 2027, and 1.33 — the version that just crossed — on July 29, 2027.

The cadence math: what "staying current" costs instead

The honest alternative to paying the meter is an upgrade rhythm, and it is worth sizing truthfully. EKS ships roughly three Kubernetes versions a year, and each version's standard window is 14 months. If you always run the newest version, you upgrade about three times a year; if you ride each version to the end of its standard window, you upgrade about once a year but always under a deadline. Most disciplined teams land in between: one to two planned control-plane upgrades a year, each followed by node-group and add-on updates.

What you cannot do is skip. Kubernetes control-plane upgrades — on EKS as upstream — go one minor version at a time, so a cluster three versions behind is three sequential upgrade projects, not one. This is how teams end up in extended support "temporarily" and stay: the backlog compounds at three versions a year while the project queue does not. One mitigation worth knowing: per AWS's version documentation, in-place upgrades can be rolled back to the previous minor version within 7 days of completion (for clusters on the extended upgrade policy), which takes much of the terror out of pulling the trigger. And new clusters can be created on any version still in standard or extended support — useful for blue/green migrations, though a new cluster on an extended-support version bills at the extended rate from day one.

EKS vs upstream Kubernetes vs the other clouds

For context, one honest paragraph. Upstream Kubernetes supports each minor version for roughly 14 months, free, and then stops — no extended tier exists at any price; our Kubernetes EOL guide covers that schedule version by version. Amazon EKS wraps that in 14 months of standard support plus 12 months of paid extended support, with automatic enrollment and a forced upgrade at the end. Google GKE and Microsoft AKS both offer their own longer-support mechanisms — GKE has an extended support channel for aging versions, and AKS designates certain versions for long-term support with roughly two years of coverage — but their calendars, prices and mechanics differ from EKS's and from each other, and they publish their own release schedules; verify against the provider's page rather than assuming the EKS model transfers. The one constant across all three clouds: the managed control plane extends the runway, and the nodes remain your problem on every provider.

Frequently Asked Questions

Related

• All Amazon EKS versions with live status · EKS 1.33 · EKS 1.34 · EKS 1.31 — dates and risk scores
• Kubernetes End-of-Life Dates — Official EOL Schedule for Every Version — the upstream schedule this clock is built on
• AWS Starts Charging for MySQL 8.0 on August 1 — the same automatic-enrollment pattern on RDS
• AWS Quietly Moved Lambda's Runtime Cutoffs to 2027 — the third AWS lifecycle clock worth tracking
• The 2026 EOL Calendar — everything else with a date this year