EKS Extended Support - Upgrade Before You Pay 6x (2026)

Amazon EKS extended support charges $0.60 per cluster-hour instead of $0.10. That sixfold rate applies only to the fee for the control plane, the managed layer that runs the Kubernetes API, so your worker node costs stay where they are.

As of November 6, 2026, clusters on Kubernetes 1.31, 1.32 and 1.33 already pay the $0.60 rate. The 6x still lies ahead for 1.34 and newer, and billing on 1.34 starts at the beginning of December 2, 2026 UTC.

The fee isn't the only cost of delay. A version leaves standard support roughly every four months on the AWS calendar (our calculation), and each version that leaves standard support adds a hop to your backlog. A hop is one minor-version upgrade, such as 1.33 to 1.34. We have no reliable public figure for that upgrade effort, so estimate your own. Our reading is that recent hops also carry node work beyond the API version checks that common scanners document.

The Bottom Line

• Extended support raises the EKS control plane fee from $0.10 to $0.60 per cluster-hour, a 500% increase. Worker nodes and other charges don't change.
• Clusters on 1.31, 1.32 and 1.33 already pay the higher rate. Billing on 1.34 starts at the beginning of December 2, 2026 UTC.
• You can't switch a cluster to STANDARD once it enters extended support, and that setting means an auto-upgrade, not a free stay. Our advice is to change a 1.34 policy before billing starts.
• Auto-upgrades at the end of extended support come without notice and can't be rolled back. Managed node groups and self-managed nodes stay on the old version, Fargate Pods need a restart or redeploy, and Auto Mode nodes may update.
• Our reading is that recent upgrade blockers are mostly behavioral and node-level, while the docs for Pluto and kubent describe API version checks only.

What the 6x covers and who already pays

The 6x applies to one line item, the per-cluster control plane fee. AWS pricing lists $0.10 per cluster-hour in standard support and $0.60 in extended support, which is standard plus $0.50. That's a 500% increase on that fee alone. Node spend is unchanged, so right-sizing your EKS workloads remains a separate exercise.

AWS's own example puts standard support at $73.00 per month, and our calculation at 730 hours gives $438 per month in extended support. The premium comes to $4,380 per cluster per year ($0.50 x 8,760 hours).

The premium follows cluster count, not cluster size, so a quiet staging cluster pays the same fee as your busiest production cluster. Calculated annual premiums are $21,900 for 5 clusters, $43,800 for 10, $109,500 for 25 and $219,000 for 50, assuming each cluster spends the full year in extended support.

Annual extended support premium by fleet sizeCalculated at $0.50 per cluster-hour over 8,760 hours5 clusters$21,90010 clusters$43,80025 clusters$109,50050 clusters$219,000Source: Calculated from Amazon EKS pricing (retrieved 2026-11-06)Source: Calculated from Amazon EKS pricing, retrieved 2026-11-06.

Extended support is also the default. The supportType setting is EXTENDED for new and existing clusters unless you specify otherwise, so a cluster reaches the higher rate with no action from anyone. You can check each cluster with one command.

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

The EKS dates that set your deadline

Each Kubernetes version on EKS gets 14 months of standard support and 12 months of extended support, 26 months in total, according to the AWS version lifecycle page. Its calendar currently reads as follows.

The current calendar starts at 1.31. For anything older, AWS's general rule past end of extended support is an automatic update to the earliest supported version.

Billing starts earlier than the calendar date suggests for US teams, because AWS begins it at the start of the end-of-standard-support day, in UTC. For 1.34, that's 00:00 UTC on December 2, which is 4pm PST or 7pm EST on December 1. If your change calendar runs on US time, plan around December 1.

The EKS date drives your plan, not the upstream date. Upstream Kubernetes ended 1.34 support on October 27, 2026, but EKS still backports applicable security patches during standard support. AWS also announces each end of standard support at least 60 days ahead, so recheck the later rows before you commit to them.

What the premium buys and when paying makes sense

The premium buys time, and AWS doesn't abandon these clusters. Extended support still includes control plane security patches and AWS support. It also covers patches for the VPC CNI (pod networking), kube-proxy (Service network rules on each node), CoreDNS (cluster DNS), AWS AMIs (node machine images) and Fargate nodes.

Amazon Linux 2 (AL2) AMIs are the exception. EKS releases no updates to AL2 AMIs after November 26, 2025, for all Kubernetes versions and independent of support timelines. Our reading is that a 1.31 or 1.32 cluster paying for extended support gets no new EKS AL2 AMIs.

Running behind is also common. On October 1, 2025, Datadog's Kubernetes adoption data showed 78% of hosts on mainstream versions, 19% on extended and 3% on unsupported. Those figures count hosts across all providers, so they don't describe EKS clusters specifically.

Our recommendation is to treat the premium as a deliberate purchase. Paying is reasonable in these cases:

• The cluster has a firm retirement date inside the 12-month extended window.
• A third-party dependency blocks the next hop and has no compatible release yet.
• A peak sales period or release freeze rules out an upgrade for now. Set the fee beside what downtime on that cluster would cost you.

The weak case is a cluster with no owner and no target version, because the hop count keeps growing while you pay. To judge the trade, weigh the premium against the risk of deferring a hop that usually still has to happen.

Traps in the auto-upgrade and policy rules

A forced upgrade can land on another extended version. After extended support ends, EKS can auto-upgrade the control plane at any time, with no notification beforehand. AWS gives no specific time frame, and the rollout is gradual. Applying AWS's earliest-supported-version rule, our reading is that a 1.31 cluster upgraded after November 26 lands on 1.32. That version stays in extended support until March 23, 2027, so the cluster likely keeps paying $0.60.

Auto-upgrades can leave your compute behind. The same AWS page says managed node groups and self-managed nodes stay on the old version. Fargate Pods aren't upgraded and need a rolling restart or redeploy. Auto Mode nodes may update, with no timing given. The kubelet, the agent on each node, can trail the control plane by up to three versions. Our reading is that repeated control-plane-only upgrades eat that allowance.

Rollback is narrow. You can't roll back after an auto-upgrade at the end of extended support. A rollback you start yourself works within 7 days, and only one version back (N to N-1). Add-ons aren't rolled back with the cluster, and extended charges resume if you land on an extended version. Once 1.34 is in extended support, rolling 1.35 back to 1.34 would put that cluster on the $0.60 rate.

STANDARD is neither free time nor always available. You can set it only while the cluster runs a version in standard support. The setting means an auto-upgrade at the end of standard support, so a 1.34 cluster won't simply stay on 1.34. AWS gives a time of day for billing, not for this policy lock. Billing starts at the beginning of December 2 UTC, so our advice is to change the policy before then. Do that only on clusters that have cleared the 1.35 blockers below.

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

Upgrade insights can lag behind your fixes

A passing insight is a poor deadline signal this close to the dates above. EKS upgrade insights run on every cluster and refresh every 24 hours or on demand. Deprecated API checks use a rolling 30-day window, so a fixed resource can show as an error for up to 30 days. By our calculation, a fix shipped on November 6 could still appear on December 6, past both November 26 and December 2. Our advice is to verify affected resources directly rather than wait for a pass.

aws eks start-insights-refresh --region <region-code> --cluster-name <cluster-name>
aws eks list-insights --region <region-code> --cluster-name <cluster-name>

Insights also won't stop a bad upgrade for you. The same AWS page says they don't currently block an upgrade, because the --force enforcement is temporarily rolled back. You have to catch an open error yourself before you start.

How big your upgrade backlog is

Your backlog is a hop count, because the control plane moves one minor version at a time and add-ons do too. Once billing on 1.34 starts at the beginning of December 2 UTC, 1.35 becomes the oldest standard version. The table shows our calculated hops to reach standard support.

The 1.31 and 1.32 rows in the March 27, 2027 column may not hold. Both versions reach end of extended support before March 27, 2027, so an auto-upgrade may overtake those counts.

To size the work, multiply hops by engineer hours per hop and a loaded hourly rate. With placeholder inputs of 60 hours at $100 an hour, one hop costs $6,000 in engineering time. Those inputs are illustrative only, so use your own, and shared work across clusters can lower them. That cost usually comes on top of the premium, because paying defers a hop and doesn't replace it unless the cluster retires first.

Landing on 1.35 only holds until March 27, 2027. Our recommendation, where the work allows, is to aim for 1.36, which stays in standard support until August 2, 2027.

Blockers to clear at each hop

Each hop has its own work. The table below turns the EKS extended version notes, EKS standard version notes and Kubernetes deprecation guide into checks, and the check wording is ours.

Some terms need a plain definition first, and your platform team can take these rows as a checklist. FlowSchema and PriorityLevelConfiguration are objects that manage API server traffic priority. Static Pods run directly from files on a node. Ingress NGINX is a controller that routes outside traffic into a cluster. containerd is the container runtime, the software on each node that runs containers. cgroup v1 is the older version of the Linux feature that limits resources for processes. cAdvisor is a service that collects container resource data. SELinuxMount means the kubelet mounts a volume with its SELinux label instead of relabeling each file, and nodes without SELinux are unaffected.

Scanners cover only part of this list. Pluto scans for deprecated and removed apiVersions, and kubent checks deprecated API versions, including those due for removal. Their docs describe API version checks only, not node, runtime or kubelet settings.

kubent
pluto detect-all-in-cluster

The newest removal entry in that deprecation guide is v1.32, so our reading is that recent breakage is mostly behavioral and node-level. A clean scan helps on the hop to 1.32, and the later rows still need their own checks.

Treat the node layer as its own workstream. Version 1.32 is the last with AL2 AMIs, and you must migrate even on extended support, so any AL2 node group gates the hop to 1.33. Our recommendation is to start that migration first and rehearse each hop in a lower environment.

How to run each hop

Our recommendation is to check add-on compatibility first, then follow the AWS User Guide order of control plane, nodes, other apps, add-ons and clients. The Best Practices guide differs slightly, running control plane, add-ons, kubectl, then nodes.

Before each control plane update, confirm your cluster subnets have free IP addresses, since AWS asks for up to five. Plan for the fact that you can't pause an upgrade once it starts, though EKS reverts it if health checks fail.

aws eks update-cluster-version --name <cluster-name> --kubernetes-version <version-number> --region <region-code>

Blue/green is the alternative for clusters far behind. It means building a new cluster and moving workloads across, so it can jump versions but needs two clusters running in parallel, according to the same Best Practices guide. Compare that extra capacity with the effort of four in-place hops on a 1.31 cluster. Set supportType deliberately on the new cluster, since the default is EXTENDED.

A one-week first step for your fleet

Our suggested first week runs from inventory to policy to sequence, before any upgrade starts.

1. Inventory, days one and two. List each cluster with its version, supportType, node operating system and owner. The EKS cluster dashboard shows auto-upgrades due within 90 days, projected extended support cost and the support type split, across accounts and Regions. It needs AWS Organizations, is viewed in us-east-1, updates every 12 hours and excludes GovCloud and China. Cost allocation tags help when a cluster has no clear owner.
2. Policy, day three. Choose STANDARD or EXTENDED for each cluster on 1.34 and newer, starting with 1.34. For each cluster you keep in extended support, record the reason and an exit date.
3. Sequence, days four and five. Start with 1.31, where an auto-upgrade can come any time after November 26. Move 1.34 next, since one hop keeps it off the premium. Then take 1.32, which reaches its end of extended support on March 23, 2027, followed by 1.33 on July 29, 2027.

The result is one list of each cluster's owner, target version, blockers and date, which separates clusters facing a forced upgrade from clusters facing only a fee.

Get a second opinion on your upgrade plan

If you want help with hop order and blockers, book a 30-minute call with a cloud architect. Bring your cluster list, and we'll work through it with you.

The EaseCloud Team writes about cloud performance, reliability and cost for technical leaders. See the team page and about EaseCloud. Sources were retrieved on November 6, 2026, and analysis of ours is labeled as such.