Amazon EKS 1.33 standard support ends 29 July 2026: the upgrade path and the $4,380 cost of waiting

Summary. Amazon EKS 1.33 leaves standard support on 29 July 2026, nine days from now. On that date the per-cluster charge rises from $0.10 to $0.60 per hour, a $0.50 difference that costs $4,380 per cluster per year for a cluster running continuously. Extended support is enabled by default on every new and existing cluster, so nobody has to opt in to the higher rate. It happens automatically. A separate deadline lands sooner: EKS 1.30 reaches the end of extended support on 23 July 2026, three days from now, after which AWS auto-upgrades the control plane with no notification. The path from 1.33 to the current 1.36 crosses three minor versions and at least six breaking changes, including cgroup v1 removal in 1.35, the end of containerd 1.x support, and the permanent disabling of gitRepo volumes in 1.36. This is the upgrade plan, in order, with the failure modes at each hop.

The cost is the easy part to explain to a CFO. The reason to move is that 1.33 stops receiving the same qualification treatment, and the jump gets harder the longer it is deferred.

The dates that matter

Amazon EKS gives every minor version 14 months of standard support followed by 12 months of extended support, for a 26-month total lifecycle. Billing for extended support starts at the beginning of the day the version reaches end of standard support, in UTC+0.

Version	EKS release	End of standard support	End of extended support
1.36	2 June 2026	2 August 2027	2 August 2028
1.35	27 January 2026	27 March 2027	27 March 2028
1.34	2 October 2025	2 December 2026	2 December 2027
1.33	29 May 2025	29 July 2026	29 July 2027
1.32	23 January 2025	23 March 2026	23 March 2027
1.31	26 September 2024	26 November 2025	26 November 2026
1.30	23 May 2024	23 July 2025	23 July 2026

Two rows deserve immediate attention. If you are on 1.33, you have nine days before the rate change. If you are still on 1.30, you have three days before AWS begins auto-upgrading your control plane, and the documentation is explicit that "automatic updates can happen at any time after the end of extended support date" and "you won't receive any notification before the update."

The auto-upgrade covers the control plane only. Self-managed nodes and EKS Managed Node Groups stay on the previous version. EKS Auto Mode nodes may update. That asymmetry is where outages come from: a control plane that has moved and a fleet that has not.

What the delay actually costs

The arithmetic is simple and worth putting in front of whoever signs the bill.

Scenario	Rate per cluster hour	Annual cost per cluster	Delta vs standard
Standard support	$0.10	$876	baseline
Extended support	$0.60	$5,256	+$4,380
10 clusters, standard	$1.00	$8,760	baseline
10 clusters, extended	$6.00	$52,560	+$43,800
50 clusters, extended	$30.00	$262,800	+$219,000

At 8,760 hours in a year, the $0.50 per hour premium is $4,380 per cluster. AWS's own worked example puts a cluster left alone for the full 26-month lifecycle at a blended $0.33 per hour, more than three times the standard rate.

The number that stings is the multi-cluster one. Organisations that split clusters per environment or per team rarely have one. A platform running dev, staging and production across three regions is nine clusters, and that is $39,420 a year for the privilege of not upgrading. Control-plane charges are also invisible in most rightsizing work, because the tooling is pointed at node spend. This is the sort of line item that a FinOps review of AWS, Azure and GCP spend surfaces late, after it has been running for two quarters.

You can decline extended support. Setting the cluster upgrade policy to STANDARD avoids the higher rate, but the trade is severe: at the end of standard support the cluster is auto-upgraded rather than parked. For most teams that is worse than paying, because it converts a cost problem into an unscheduled change.

The upgrade path from 1.33 to 1.36

EKS supports upgrading one minor version at a time, so 1.33 to 1.36 is three sequential hops. The Kubernetes project tests control plane and node compatibility across three minor versions, so 1.33 nodes keep running under a 1.36 control plane, but AWS recommends matching versions on both.

Take the hops in order and treat each as a separate change window.

Hop 1: 1.33 to 1.34

Two things bite here.

AWS does not publish an EKS-optimised Amazon Linux 2 AMI for 1.34, and did not for 1.33 either. If any node group still runs AL2, this is where it stops. Migrate to Amazon Linux 2023 first, as a separate change, before touching the control plane.

VolumeAttributesClass graduates to GA in 1.34, moving from storage.k8s.io/v1beta1 to storage.k8s.io/v1. If you use the EBS CSI driver with AWS-managed sidecars, volume modification keeps working on 1.31 through 1.33 clusters because AWS patches those sidecars to support the beta API. That patching stops at the end of EKS 1.33 standard support, which is the same 29 July 2026 date. If you self-manage CSI sidecars, you may need to pin older sidecar versions on pre-1.34 clusters to keep VolumeAttributesClass working.

AppArmor is deprecated in 1.34. Move to seccomp or Pod Security Standards.

Also in 1.34: the external JWT signer for service account tokens reaches beta, and --service-account-extend-token-expiration is no longer fully respected when an external signer is in use. The API server enforces the lower of the desired one-year extension and the signer's 24-hour limit. If you have anything reading a long-lived projected token, check it.

Hop 2: 1.34 to 1.35

This is the hop that breaks nodes.

Kubernetes 1.35 deprecates cgroup v1, and the kubelet refuses to start by default on a cgroup v1 node. AL2023 uses cgroup v2 by default and behaves like upstream. Bottlerocket 1.35 also defaults to cgroup v2 but sets failCgroupV1: false, preserving backward compatibility. Fargate continues on cgroup v1. If you manually configured AL2023 for cgroup v1, either migrate to v2 or set failCgroupV1: false in the kubelet config before upgrading.

The --pod-infra-container-image flag is removed from kubelet in 1.35. Custom AMI users must strip it from kubelet configuration first, or nodes will not come up. This is the single most common self-inflicted failure on this hop, because the flag sits in bootstrap scripts that nobody has read in two years.

1.35 is also the last release supporting containerd 1.x. You must be on containerd 2.0 or later before upgrading past it. We covered that migration in detail in our Kubernetes 1.35 and containerd 2.0 upgrade guide.

IPVS mode in kube-proxy is deprecated in 1.35 and removed in 1.36. If you run IPVS, this is a two-release fuse and it is already lit.

On the upside, in-place pod resource updates go stable in 1.35, which lets you change CPU and memory on a running pod without a restart. That is a real rightsizing lever, and we have written about in-place pod resize for rightsizing.

Hop 3: 1.35 to 1.36

Three changes need pre-work.

The gitRepo volume type is permanently disabled in 1.36 and cannot be re-enabled. The API still accepts pods that declare one, but the kubelet refuses to run them and returns an error. That failure mode is nasty: your manifests apply cleanly and the workload never starts. Migrate to an init container or a git-sync sidecar first.

StrictIPCIDRValidation is on by default for built-in API kinds. IP and CIDR values with leading zeros such as 010.000.000.005 are rejected, as are ambiguous CIDRs such as 192.168.0.5/24 where 192.168.0.0/24 was meant. Existing stored objects survive through validation ratcheting, but new creates and updates fail. Custom resources are unaffected. Grep your Helm charts and Terraform for non-canonical addresses before the upgrade, not after.

SELinux volume labelling goes GA and now defaults to all volumes, using mount -o context rather than recursive relabelling. Sharing a volume between privileged and unprivileged pods on the same node can break. If you run SELinux in enforcing mode, audit seLinuxChangePolicy and volume labels first.

Also in 1.36: user namespaces are stable, giving container breakouts no administrative power on the node, and externalIPs on Services is deprecated with removal planned for 1.43.

The one that is not on the version calendar

Ingress NGINX is being retired by the upstream Kubernetes project, announced by the Steering and Security Response Committees. AWS's guidance in the 1.35 notes is direct: evaluate whether you depend on it and plan migration to Gateway API or a third-party ingress controller, because there will be no further bug fixes or security patches after retirement. Existing deployments keep working. They just stop being patched.

None of the alternatives are drop-in replacements. Budget engineering time, not a config change. For a lot of teams this is a bigger project than the three version hops put together, and it does not appear on any EKS support calendar, which is exactly why it gets missed.

A nine-day plan if you are on 1.33

You cannot cross three minor versions safely in nine days. That is fine, because the goal in nine days is not to reach 1.36. It is to stop the meter or to decide deliberately to pay it.

Days 1 to 2: inventory. Run aws eks describe-cluster-versions and list every cluster, its version, its upgrade policy, and its node group AMI types. Find the AL2 node groups and the clusters still on 1.30 or 1.31, because those are on a shorter fuse than 1.33.

Days 3 to 5: clear the 1.34 blockers. Migrate AL2 node groups to AL2023. Check CSI sidecar management. Remove AppArmor profiles.

Days 6 to 8: upgrade the control plane to 1.34 in non-production, then production. One hop only. This takes you back into standard support, and 1.34 runs on standard support until 2 December 2026, which buys four months to plan the rest properly.

Day 9: verify node groups match the control plane, and confirm the cluster upgrade policy on every remaining cluster.

Then schedule 1.35 and 1.36 as real projects in Q4, with the containerd 2.0 migration and the gitRepo and CIDR audits as their own tickets.

The honest engineering judgement: one hop to 1.34 before the deadline is worth more than a rushed sprint to 1.36 that breaks the fleet. Standard support is the goal, not the newest number.

India-specific considerations

For Indian platform teams, two patterns show up repeatedly.

The first is cluster sprawl driven by per-client isolation. Services organisations running a cluster per customer environment carry the extended-support premium multiplied by the client count, and it lands on delivery margin rather than an infrastructure budget line. A ten-client footprint at one cluster each is $43,800 a year of pure version-lag cost. That is worth a scheduled upgrade programme rather than ad hoc remediation.

The second is the notification gap. AWS sends end-of-standard-support notices through the AWS Health Dashboard roughly 12 months after a version's EKS release, at least 60 days before the date. Teams that do not route Health Dashboard events into an on-call channel or a ticket queue find out when the bill changes. Wiring those events into whatever your team actually reads costs an afternoon.

Data residency and DPDP obligations do not change the upgrade calculus, but they do constrain the shortcut some teams reach for: spinning up a fresh cluster on 1.36 and migrating workloads. If the workload holds personal data, treat the migration as a data movement with the same controls as any other, not as a deployment.

FAQ

When exactly does EKS 1.33 stop being supported?

Standard support for Amazon EKS 1.33 ends on 29 July 2026, fourteen months after its EKS release on 29 May 2025. Extended support then runs for twelve months, ending on 29 July 2027. Billing at the higher extended rate starts at the beginning of the end-of-standard-support day, in the UTC+0 timezone.

How much does EKS extended support cost?

Extended support costs $0.60 per cluster per hour against $0.10 per cluster per hour for standard support. The $0.50 difference works out to $4,380 per cluster per year for a cluster running continuously. Ten clusters left in extended support add $43,800 annually, and the charge applies per cluster regardless of node count.

Do I get enrolled in extended support automatically?

Yes. The cluster upgrade policy defaults to EXTENDED on all new and existing clusters unless you change it. No action is required to start paying the higher rate. You can set the policy to STANDARD to avoid the cost, but then the cluster is auto-upgraded at the end of standard support instead of staying put.

What happens if I ignore the deadline entirely?

The cluster moves to extended support and the rate rises. After twelve more months, at the end of extended support, AWS auto-upgrades the control plane to the earliest supported version with no advance notification and no committed timing. Managed and self-managed node groups are not upgraded with it, so you must update nodes and add-ons yourself.

Can I upgrade from 1.33 straight to 1.36?

No. EKS upgrades proceed one minor version at a time, so 1.33 to 1.36 requires three sequential hops through 1.34 and 1.35. Control plane and node skew is tolerated across three minor versions, so 1.33 nodes still run under a 1.36 control plane, but AWS recommends matching control plane and node versions.

Which upgrade step breaks the most clusters?

The 1.34 to 1.35 hop. Kubernetes 1.35 deprecates cgroup v1 and the kubelet refuses to start on cgroup v1 nodes by default, and the --pod-infra-container-image flag is removed from kubelet, so custom AMIs carrying that flag in bootstrap scripts fail to join. Both are node-level failures, not control plane ones.

What is the gitRepo volume problem in 1.36?

The gitRepo volume type is permanently disabled in Kubernetes 1.36 and cannot be re-enabled. The API server still accepts pods declaring one, but the kubelet refuses to run them and returns an error. Migrate to init containers or a git-sync sidecar before upgrading, because manifests will apply cleanly and then silently fail.

Is Ingress NGINX affected by any of this?

Not by the version calendar, but the upstream Kubernetes project is retiring Ingress NGINX, and AWS advises EKS customers to plan migration to Gateway API or a third-party controller. Existing deployments keep running without further bug fixes or security patches. No alternative is a drop-in replacement, so budget engineering time.

How eCorpIT can help

eCorpIT runs Kubernetes upgrade and platform reliability work for teams that cannot take an unplanned outage, and our senior engineering teams have taken clusters through the AL2 to AL2023, containerd 2.0 and cgroup v2 transitions in production. We inventory your fleet, sequence the hops, and clear the node-level blockers before touching a control plane. If EKS 1.33 is on your account and 29 July is close, contact us and we will scope the shortest safe path back to standard support.

References

1. Understand the Kubernetes version lifecycle on EKS - Amazon EKS User Guide, release calendar and support FAQs.
2. Amazon EKS pricing - AWS, standard and extended cluster pricing.
3. Review release notes for Kubernetes versions on standard support - Amazon EKS User Guide, per-version breaking changes.
4. Amazon EKS extended support for Kubernetes versions pricing - AWS Containers Blog.
5. Kubernetes v1.36 release announcement - Kubernetes Blog.
6. Kubernetes v1.35 release announcement - Kubernetes Blog.
7. Ingress NGINX retirement statement - Kubernetes Steering and Security Response Committees.
8. SELinux volume label changes go GA - Kubernetes Blog.
9. User namespaces in Kubernetes are GA - Kubernetes Blog.
10. Kubernetes 1.35: in-place pod resize graduates to stable - Kubernetes Blog.
11. Kubernetes version and version skew support policy - Kubernetes documentation.
12. Upgrade from Amazon Linux 2 to Amazon Linux 2023 - Amazon EKS User Guide.
13. View current cluster upgrade policy - Amazon EKS User Guide.
14. KEP-5040: gitRepo volume removal - Kubernetes Enhancements.
15. KEP-4858: strict IP and CIDR validation - Kubernetes Enhancements.

Last updated: 20 July 2026.