EKS 1.35 end of standard support (27 March 2027): your EKS upgrade calendar

Summary. Amazon EKS ends standard support for Kubernetes 1.35 on 27 March 2027, and AWS's release calendar still shows that date on 11 November 2026. From 00:00 UTC that day, a 1.35 cluster whose upgrade policy is EXTENDED pays $0.60 per cluster-hour instead of $0.10: $438 against $73 in a 730-hour month, or $4,392 extra over the 366-day extended year. A cluster set to STANDARD is upgraded by AWS instead and pays no extended fee. Extended support for 1.35 ends on 27 March 2028; after that, AWS upgrades the control plane at a time of its choosing, without notice, and leaves node groups and add-ons where they were. Two EKS features lower the risk of moving early: an in-place upgrade can be rolled back one minor version within 7 days, and rollback-readiness insights flag what would block that rollback. Add-ons are still never upgraded for you, and 1.32 was the last version with AWS-published Amazon Linux 2 AMIs. Three EKS deadlines arrive sooner: 1.31 extended support ends on 26 November 2026, 1.34 standard support on 2 December 2026 and 1.32 extended support on 23 March 2027. Verdict: set the policy on each cluster now and finish production upgrades by mid-March.

About this article. For platform, DevOps and FinOps leads running Amazon EKS. On 11 November 2026 we checked every date, price and behaviour against the Amazon EKS user guide, the EKS pricing page, AWS announcements and the Kubernetes project's release pages, and recomputed every figure. AWS updates its calendar as versions move, so re-check before you commit a change window; prices are in US dollars, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

This guide covers Amazon EKS only. For upstream end-of-life dates and the breaking changes between 1.34 and 1.37, see our Kubernetes 1.35 end-of-life upgrade calendar. For how the EKS policy compares with Azure and Google, see EKS vs AKS vs GKE version support calendars in 2027.

What happens to an EKS 1.35 cluster on 27 March 2027

AWS gives each Kubernetes minor version 14 months of standard support from its EKS release, then 12 months of extended support, 26 months in all. EKS released 1.35 on 27 January 2026, which puts the two end dates on 27 March 2027 and 27 March 2028.

Extended billing starts at the beginning of the end-of-standard-support day in UTC, and the calendar's dates are UTC dates. For a team in Gurugram or Bengaluru, that is 05:30 IST on Saturday 27 March 2027.

What happens next depends on one cluster setting, the upgrade policy (upgradePolicy.supportType):

• EXTENDED. The cluster stays on 1.35, enters extended support and the fee rises to $0.60 per hour.

• STANDARD. The cluster becomes eligible for an automatic upgrade to the next version in standard support, which will be 1.36, and it incurs no extended charges.

AWS's documentation disagrees with itself on the default. Its lifecycle FAQ and policy page say EXTENDED applies to new and existing clusters unless you choose otherwise. Its page on enabling extended support says clusters created in the AWS console start with extended support disabled, while clusters created through the API start with it enabled. Read the setting on every cluster rather than assuming either.

The policy has two traps. AWS strongly recommends setting EXTENDED before standard support ends and says it cannot guarantee the change takes effect once an automatic upgrade has started. And the choice locks after the date: a cluster in extended support cannot switch it off, because the policy can only be changed while the cluster runs a standard-support version. To stop paying $0.60 for a 1.35 cluster after 27 March, you upgrade it.

Extended support is not a reduced tier. AWS keeps patching the control plane, the VPC CNI, kube-proxy and CoreDNS add-ons, its published AMIs for Amazon Linux, Bottlerocket and Windows, and Fargate nodes, and technical support stays available. You are paying for time.

When extended support ends, AWS says the automatic control plane upgrade can happen at any time after the date, with no advance notification. Only the control plane moves: managed node groups and self-managed nodes stay on the old version, though Auto Mode nodes may update. A cluster upgraded this way cannot be rolled back.

The table sums up the outcomes from AWS's policy, rollback and pricing pages.

AWS commits to announcing each end-of-standard-support date at least 60 days ahead, and accounts with clusters on the affected version get a notice in the AWS Health Dashboard about 12 months after the version reached EKS.

The EKS calendar from 1.31 to 1.37

This is AWS's calendar as published on 11 November 2026, with two columns we added: days EKS trailed upstream, and status today.

Three patterns matter for planning.

EKS standard support outlasts upstream. The Kubernetes project ends 1.35 on 28 February 2027, so EKS keeps backporting applicable security fixes to 1.35 for 27 days after upstream stops. AWS says its end date will always fall after the upstream one.

Abandoned clusters get upgraded more than once. When extended support ends, AWS moves the cluster to the oldest version still in extended support. An untouched 1.31 cluster therefore goes to 1.32 some time after 26 November 2026, still at $0.60 an hour, and to 1.33 after 23 March 2027: two unplanned upgrades in about four months.

Kubernetes 1.38 is not on the EKS calendar yet. The upstream release team plans v1.38.0 for 16 December 2026. EKS shipped each of the seven versions above 36 to 44 days after upstream; if that held, 1.38 would reach EKS between about 21 and 29 January 2027. That is our extrapolation, not an AWS commitment.

Pull the same dates from the API rather than from a screenshot in a wiki:

            aws eks describe-cluster-versions \
  --query 'clusterVersions[].[clusterVersion,status,endOfStandardSupportDate,endOfExtendedSupportDate]' \
  --output table
          

What extended support adds to the bill

The EKS pricing page lists two version-support rates: $0.10 per cluster per hour in standard support and $0.60 in extended support, described as the standard rate plus $0.50. The $0.60 rate took effect with the April 2024 billing cycle, and the page still lists it on 11 November 2026. The table uses AWS's 730-hour month.

The 1.35 extended year is 366 days long because it includes 29 February 2028, so it runs 8,784 hours. AWS's own pricing example averages a cluster that runs the full 26 months without an upgrade at $0.33 per hour.

Other EKS charges stack on top of the version fee:

• Provisioned Control Plane. The XL, 2XL, 4XL and 8XL tiers cost $1.65, $3.40, $6.90 and $13.90 per cluster-hour on top of the version-support fee. An XL cluster left on 1.35 pays $1.65 plus $0.60, or $2.25 an hour.

• Auto Mode, EKS Capabilities and Hybrid Nodes. Each has its own meter, and none changes with the version tier.

• Rollbacks into extended support. Rolling back from a standard-support version to an extended-support one restarts extended charges.

Pick the upgrade policy cluster by cluster

Leaving every cluster on whatever policy it was created with means finding out the cost in April. Choose per cluster before the date.

To list version and policy for every cluster in a Region, and to switch a cluster to STANDARD while it still runs a standard-support version:

            for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
  aws eks describe-cluster --name "$c" \
    --query 'cluster.[name,version,upgradePolicy.supportType]' --output text
done

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

Run the loop in every Region and account you use.

Upgrade insights: what they catch and what they miss

EKS runs recurring checks on every cluster, visible on the console's upgrade insights tab or through the ListInsights API. They cover deprecated API usage, kubelet and kube-proxy version skew, cluster health and EKS add-on compatibility. An ERROR status usually means the problem affects the next version (N+1); a WARNING usually means a version two or more ahead.

Four details change how you read them:

1. Insights refresh every 24 hours. After a fix, trigger a refresh with aws eks start-insights-refresh rather than waiting.

1. Deprecated API checks look back 30 days. AWS says the status can take up to 30 days to clear after you stop calling a deprecated API, because the check scans a rolling 30-day window. Fix clients early, or the insight stays red through your change window.

1. The add-on check covers EKS add-ons. It reads the versions of installed EKS add-ons. Controllers you installed with Helm, such as a load balancer controller, Karpenter, cert-manager or an ingress controller, are yours to verify.

1. Insights are not enforced today. AWS planned to require a --force flag to upgrade past certain findings, then paused that enforcement in March 2025, and its upgrade guide still calls the pause temporary. Treat a red insight as a stop sign anyway.

            aws eks start-insights-refresh --cluster-name my-cluster
aws eks list-insights --cluster-name my-cluster \
  --filter '{"categories": ["UPGRADE_READINESS"], "statuses": ["ERROR","WARNING"]}'
          

Insights do not test your workloads. AWS's release notes for 1.36 flag the permanent disabling of the gitRepo volume, strict IP and CIDR validation that rejects leading zeros and non-canonical CIDRs on new writes, and SELinux volume labelling changes; the 1.35 notes say nodes need containerd 2.0 or later before the next version. Our Kubernetes 1.36 breaking changes guide and containerd 2.0 migration guide cover these in depth.

The 7-day rollback window

EKS can roll an in-place upgrade back to the previous minor version, which changes the risk of moving production before 27 March. The rules are tight:

• Start the rollback within 7 days of the upgrade completing, and go back only one minor version (1.36 to 1.35, no further).

• Clusters created on their current version cannot roll back, and neither can clusters that AWS upgraded at the end of extended support.

• Rolling back to a version in extended support needs the EXTENDED policy and restarts the $0.60 fee. After 27 March, a rollback from 1.36 to 1.35 is a rollback into extended support.

• etcd data, workloads, persistent volumes and add-on versions stay as they are. Roll managed node groups back first with update-nodegroup-version; self-managed and hybrid nodes are yours to revert, and Auto Mode nodes are rolled back for you.

• Fargate pods cannot be rolled back. Delete pods running the newer kubelet before the rollback, or bypass the resulting skew error with --force.

• Rollback-readiness insights, under the ROLLBACK_READINESS category, block the rollback on ERROR or UNKNOWN unless you pass --force, and they appear only for 7 days after an upgrade.

In practice: upgrade production early in the week, keep node groups on 1.35 for a day or two after the control plane moves, and make the rollback decision inside the 7 days.

Nodes: AL2 is finished, so check AL2023 and Bottlerocket by version

The control plane upgrade is the easy part on EKS. Nodes are where 1.35 to 1.36 upgrades stall, because AWS never upgrades managed node groups or self-managed nodes when the control plane moves. The table draws on AWS's AMI transition guide and version release notes.

Some details from AWS's AMI guidance that surprise teams:

• AL2 is independent of extended support. AWS says the AL2 AMI end-of-support date does not follow the Kubernetes standard and extended timelines, so paying for extended support on 1.32 does not bring AL2 AMIs back. The Amazon Linux 2 operating system itself reached end of support on 30 June 2026.

• Old Java breaks on cgroup v2. JDK 8 builds before 8u372 cannot read container memory limits under cgroup v2, so the JVM sizes its heap from node memory and pods get killed for running out of memory. Upgrade the JDK before moving those workloads to AL2023.

• GPU nodes have their own floor. EC2 G7 instances need NVIDIA driver 595. AWS's AL2023 NVIDIA AMIs include it on all supported versions; Bottlerocket NVIDIA AMIs include it only from 1.37.

• Match versions before the next hop. Nodes up to three minor versions behind still work, but AWS requires managed and Fargate nodes to match the control plane's minor version before you upgrade the control plane again.

If you also run Ubuntu-based nodes or CI runners, the operating system has its own 2027 deadline; see our Ubuntu 22.04 end of standard support plan.

Add-ons: the order after the control plane

EKS does not update an add-on when a new version appears or when you move the cluster to a new minor version; you start every add-on update yourself. That gap is the most common reason clusters drift. AWS's order is: control plane, then nodes, then other cluster applications such as Cluster Autoscaler, then the EKS add-ons, then clients such as kubectl.

For each EKS add-on, find the default version for the target Kubernetes version before you start:

            for a in vpc-cni coredns kube-proxy aws-ebs-csi-driver; do
  aws eks describe-addon-versions --kubernetes-version 1.36 --addon-name "$a" \
    --query 'addons[].addonVersions[?compatibilities[0].defaultVersion==`true`].addonVersion' \
    --output text
done

aws eks update-addon --cluster-name my-cluster --addon-name kube-proxy \
  --addon-version VERSION_FROM_ABOVE --resolve-conflicts PRESERVE
          

Use PRESERVE if you have customised add-on settings; OVERWRITE resets them to EKS defaults. Cluster Autoscaler should match the cluster's minor version, GPU clusters need an updated NVIDIA device plugin, and kubectl must be within one minor version of the control plane. On Auto Mode clusters, AWS upgrades the built-in compute, block storage and load balancing capabilities for you.

Worked example: 12 EKS clusters on 1.35 in January 2027

Take an estate of 12 clusters on 1.35 on 1 January 2027, all on the EXTENDED policy: 3 production, 3 staging and 6 development or CI. Prices are from the EKS pricing page, at AWS's 730-hour month.

Plan A, on time. Staging moves to 1.36 in February, production in the first half of March, and the 6 development clusters are switched to STANDARD so AWS upgrades them. Control plane spend stays at 12 × $0.10 × 730 = $876 a month, with no extended charges.

Plan B, a two-month slip and a forgotten fleet. Production and staging slip to late May; nobody touches development for six months.

• Production: 3 clusters × $0.50 × 730 hours × 2 months = $2,190

• Staging: 3 × $0.50 × 730 × 2 = $2,190

• Development: 6 × $0.50 × 730 × 6 = $13,140

• Extra control plane spend: $17,520, against a normal bill of $876 a month

The hidden cost in Plan B is time. 1.36 leaves EKS standard support on 2 August 2027, so a cluster that reaches 1.36 on 27 May has 67 days before the next deadline. The slip squeezes two upgrades into one summer.

A 1.35 to 1.36 runbook for EKS

There are 136 days, about 19 weeks, between 11 November 2026 and 27 March 2027. A workable schedule:

1. By 20 November 2026: inventory every cluster with version, upgrade policy, node types and add-ons. Deal first with clusters on 1.31, whose extended support ends on 26 November, and 1.34, whose standard support ends on 2 December.

1. By mid-December 2026: set STANDARD on clusters that can take an AWS-timed upgrade, and move any remaining AL2 or custom-AMI nodes to AL2023 or Bottlerocket on their current version.

1. By mid-January 2027: replace gitRepo volumes, fix non-canonical CIDRs in charts, and confirm containerd 2.0 or later on custom AMIs. Refresh upgrade insights and clear every ERROR, allowing for the 30-day lookback on deprecated APIs. Check the cluster subnets too: EKS needs up to five free IP addresses for a control plane update.

1. February: upgrade staging. Control plane first (aws eks update-cluster-version --name my-cluster --kubernetes-version 1.36), then node groups, then add-ons, inside the rollback window.

1. By mid-March: upgrade production early in the week, and hold nodes on 1.35 for a day after the control plane moves.

1. After 27 March: check the April bill for any cluster still at $0.60 and give each one an owner and an exit date.

One more reason to move: Nitro Sandboxes, which AWS launched for EKS on 9 November 2026 to run pods in hardware-isolated virtual machines, need Kubernetes 1.36 or later and are supported on the two latest versions.

Notes for India-based teams

For organisations on an April-to-March financial year, 27 March falls four days before year-end close, when many teams freeze production changes, so finish production upgrades by early March. The EKS pricing page lists one per-cluster rate rather than a regional table, so clusters in Mumbai or Hyderabad pay the same $0.10 and $0.60, in US dollars. At the ECB reference cross rate of ₹93.93 per US dollar on 10 November 2026, the $365 monthly extended premium is about ₹34,284 per cluster, and the $4,380 yearly premium about ₹4.11 lakh. Billing flips at 05:30 IST, so a cluster upgraded later that morning has already accrued hours at $0.60.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cloud computing services team plans and runs EKS upgrade programmes, from cluster and policy inventory to AL2023 node migrations and staged control plane upgrades. Talk to us at /contact-us/.

Last updated: 11 November 2026.

References

1. Understand the Kubernetes version lifecycle on EKS — Amazon EKS User Guide, Amazon Web Services

1. Amazon EKS pricing — Amazon Web Services

1. View current cluster upgrade policy — Amazon EKS User Guide, Amazon Web Services

1. Roll back a cluster to a previous Kubernetes version — Amazon EKS User Guide, Amazon Web Services

1. Guide to EKS AL2 and AL2-accelerated AMIs transition features — Amazon EKS User Guide, Amazon Web Services

1. Add flexibility to plan Kubernetes version upgrades by enabling EKS extended support — Amazon EKS User Guide, Amazon Web Services

1. Prevent increased cluster costs by disabling EKS extended support — Amazon EKS User Guide, Amazon Web Services

1. Releases — Kubernetes

1. Kubernetes v1.38 release information — Kubernetes SIG Release, GitHub

1. Amazon EKS extended support for Kubernetes versions pricing, 16 January 2024 — AWS Containers Blog

1. View cluster insights — Amazon EKS User Guide, Amazon Web Services

1. Prepare for Kubernetes version upgrades and troubleshoot misconfigurations with cluster insights — Amazon EKS User Guide, Amazon Web Services

1. Update existing cluster to new Kubernetes version — Amazon EKS User Guide, Amazon Web Services

1. Document history — Amazon EKS User Guide, Amazon Web Services

1. Review release notes for Kubernetes versions on standard support — Amazon EKS User Guide, Amazon Web Services

1. Amazon Linux 2 FAQs — Amazon Web Services

1. Update an Amazon EKS add-on — Amazon EKS User Guide, Amazon Web Services

1. Introducing AWS Nitro Sandboxes on Amazon EKS, ECS and EC2 for hardware isolated pods, tasks and VMs, 9 November 2026 — AWS What's New

1. Euro foreign exchange reference rates, 90-day history (USD and INR, 10 November 2026) — European Central Bank