EKS Extended Support Cost: The Nov 26 Forced Upgrade and a 2-Week Exit Plan

EKS extended support costs $0.60 per cluster per hour, six times the $0.10 standard rate, which works out to about $4,380 extra per cluster per year. And the bill is the smaller problem. On November 26, 2026, EKS 1.31 leaves extended support entirely, and AWS will then upgrade those control planes on its own schedule, without notice, leaving your nodes and add-ons behind.

If you have one forgotten cluster on an old version, this is an annoyance. If you have a fleet of dev, staging and per-team clusters that nobody upgraded since 2024, it is a five or six figure line item plus an unplanned change window that AWS picks for you. Here is the math, what actually breaks, and a two week plan to get out.

How much does EKS extended support cost per cluster?

The AWS pricing page is short: standard Kubernetes version support is $0.10 per cluster per hour, and extended support is $0.60 per cluster per hour, described as the standard fee plus $0.50. That premium applies to the control plane only. Your EC2, Fargate or Auto Mode compute is billed the same either way.

Using AWS’s usual 730 hours per month:

Billing starts at the beginning of the day (UTC) that a version reaches end of standard support, per the EKS release calendar. There is no grace period and no warning on the invoice beyond a new line item.

The quiet part is how teams end up here. Extended support is enabled by default on every new and existing cluster. Unless someone set the upgrade policy to STANDARD, a cluster rolls into the $0.60 tier automatically on its end of standard support date. For multi-account AWS setups, that often means sandbox and staging clusters nobody owns are the ones paying the premium.

Which EKS versions are paying the premium right now?

Straight from the EKS Kubernetes release calendar (dates in UTC):

Two things fall out of this table. First, the forced upgrade does not get you off the premium. EKS auto-upgrades an expired control plane to the earliest supported version, which for 1.31 is 1.32, and 1.32 is billed at $0.60 until March 2027. Second, 1.34 is not a safe target either, because it starts billing at extended rates on December 2. If you are doing the work anyway, aim for 1.35 or newer, and 1.36 buys you until August 2027.

What happens when EKS force-upgrades the control plane?

AWS’s own FAQ is blunt about this. After the end of extended support date, EKS updates existing control planes “through a gradual deployment process.” It cannot give specific timing, the update “can happen at any time,” and you “won’t receive any notification before the update.” Clusters that were automatically upgraded cannot be rolled back, unlike a manual upgrade, which you can roll back within 7 days.

Only the control plane moves. Per the same docs, managed node groups and self-managed nodes remain on the previous version, Fargate pods keep their old kubelet until they are restarted, and you are told to “manually update cluster add-ons and Amazon EC2 nodes” afterwards. EKS Auto Mode nodes are the exception and may update on their own.

So the day after a forced 1.31 to 1.32 upgrade, you have a mixed cluster. Here is what that means in practice.

Node and kubelet skew

Kubernetes supports a kubelet up to three minor versions older than the API server, so 1.31 nodes under a 1.32 control plane are within policy and will keep running. The risk is not day one. It is that you are now one hop closer to the edge, and the next upgrade, forced or not, stacks more skew on nodes you were already behind on.

There is also an AMI trap. 1.32 is the last version with EKS-optimized Amazon Linux 2 AMIs. From 1.33 onward, EKS ships only AL2023 and Bottlerocket. If your node groups or launch templates still use AL2, your path past 1.32 includes an OS migration, with different bootstrap (nodeadm on AL2023) and potentially different kernel and cgroup behaviour.

Add-on skew

The control plane moving does not update Amazon VPC CNI, CoreDNS, kube-proxy, the EBS CSI driver or anything you installed via Helm. Each has a supported version range per Kubernetes minor. Leave them behind and you are running an untested combination at the exact moment you did not plan to be changing anything.

API and auth changes that land with 1.32

• Removed API: flowcontrol.apiserver.k8s.io/v1beta3 (FlowSchema and PriorityLevelConfiguration) stops being served in 1.32. Anything still applying v1beta3 manifests, including older Helm charts, will fail on the next deploy.
• Anonymous auth restricted: starting with EKS 1.32, unauthenticated requests are only allowed to /healthz, /livez and /readyz. Anything that relied on system:unauthenticated reaching other endpoints gets a 401.
• Deprecation warnings start piling up: 1.33 deprecates the Endpoints API in favour of EndpointSlices, so older controllers and scripts will get noisier as you move forward.

None of these are dramatic on their own. Together, landing on a day AWS chooses, they are how an “unexpected control plane upgrade” turns into a Saturday incident.

Should you just disable extended support?

You can. Setting the cluster upgrade policy to STANDARD stops EKS from enrolling it in extended support. But the docs are explicit that a STANDARD cluster is then auto-upgraded at the end of standard support instead. You are trading a bill for a forced upgrade 12 months sooner.

Our default recommendation:

• New clusters: create with STANDARD and a calendar reminder. If you cannot upgrade a cluster within 14 months, that is a platform problem to fix, not a premium to pay.
• Clusters already in extended support: do not flip the policy and hope. Upgrade them, then set STANDARD.
• Genuinely frozen workloads (a vendor appliance certified on one version, a regulated system in a change freeze): extended support is a reasonable paid bridge. Put an end date on it.

What does a 2-week EKS extended support exit plan look like?

This is the plan we run for a typical cluster with Infrastructure as Code and a reasonable add-on footprint. EKS upgrades the control plane one minor version at a time, so a 1.31 cluster needs four hops to reach 1.35. Where that is too many, we build a fresh cluster on the target version and move workloads across instead.

1. Days 1-2: inventory and bill. List every cluster, version and upgrade policy across accounts (aws eks describe-cluster per cluster, then cross-check the EKS lines in Cost Explorer). Rank by cost and by risk: production on 1.31 goes first.
2. Days 2-3: run EKS upgrade insights and an API scan. Use the EKS cluster insights checks plus a deprecated API scanner such as Pluto against live clusters and your Helm charts. Fix flowcontrol v1beta3, check for anonymous access dependencies, and pin compatible add-on versions for each hop.
3. Days 3-4: decide in-place or blue/green. One or two hops with healthy node groups: upgrade in place. Three or more hops, AL2 nodes, or snowflake config: stand up a new cluster on 1.35 or 1.36 from your Terraform and cut over.
4. Days 4-9: hop, one minor at a time. For each hop: control plane, then managed add-ons, then node groups (or Karpenter NodePools), then smoke tests. Check PodDisruptionBudgets before draining so a maxUnavailable: 0 does not stall the rollout.
5. Days 9-12: move AL2 nodes to AL2023 or Bottlerocket before you cross 1.32, and validate DaemonSets (logging, security agents, CNI plugins) on the new OS.
6. Days 12-14: lock it in. Set upgrade policy to STANDARD, add a version and end of support check to your CI or monthly ops review, and put the next upgrade on the calendar.

For GCC teams running EKS in me-central-1 or the Saudi region, the same calendar applies. Plan change windows around your own release freezes, because AWS’s auto-upgrade will not.

The bottom line

EKS extended support pricing is designed to be a bridge, not a home. At $4,380 extra per cluster per year it rarely makes sense for anything you could upgrade, and after November 26 the choice for 1.31 is no longer yours. Upgrade before AWS does it for you, aim for 1.35 or newer so December 2 does not catch you again, and switch clusters to STANDARD once they are current.

If you have clusters on 1.31 to 1.33 and no spare platform capacity before the deadline, our EKS Upgrade Sprint is a fixed-scope engagement: inventory, deprecated API cleanup, add-on and node upgrades, and a hand-back with the upgrade policy locked down, delivered in 10 business days per cluster group. If ingress is also on your list, read our ingress-nginx to Gateway API migration checklist next. Book an EKS upgrade scoping call and we will tell you within one call whether in-place or blue/green is the faster path.