Stay on EKS 1.33 and AWS Starts Billing You 6x From August

The change and the date

Amazon EKS Kubernetes version 1.33 reaches the end of standard support on July 29, 2026, and any cluster still running it on that date is automatically moved into EKS extended support. Extended support is billed at six times the standard control-plane rate: the per-cluster hourly charge rises from 0.10 US dollars to 0.60 US dollars at US list price. Your cluster keeps running and your workloads keep serving traffic, but from that day the surcharge accrues every hour, per cluster, and the standard patch cadence narrows to the extended-support track.

This is not a one-off quirk of 1.33. Every EKS minor version follows the same lifecycle: 14 months of standard support from its EKS release date, then 12 months of extended support at the higher rate, then a forced control-plane upgrade. 1.33 is simply the version whose clock runs out next. The same trap will catch 1.34, whose standard support ends December 2, 2026, and 1.35, which ends March 27, 2027. If you treat the 1.33 deadline as a single fire drill rather than a recurring calendar event, you will be back here in a few months.

Who gets hit hardest

The cost shape is linear in cluster count, so the pain is concentrated in fleets, not single clusters. A team running one cluster sees an extra 0.50 US dollars per hour, roughly the price of inattention. A platform team running fifty clusters on 1.33 sees that multiplied fifty times, every hour, with no change in what they get, an entirely avoidable line item that shows up on the next invoice and then keeps showing up. Multi-account, multi-region setups with dev, staging, and production clusters per team are exactly the profile that quietly drifts a major version behind and then pays for it across the whole estate.

The second group hit hardest is anyone who upgrades reactively. Extended support is enabled by default on all new and existing clusters: the upgrade policy is EXTENDED unless you have explicitly set it otherwise. There is no checkbox to click and no confirmation prompt before the surcharge begins. Billing for extended support starts at the beginning of the day the version reaches end of standard support, in the UTC+0 timezone. If nobody owns the version calendar, the first signal you get is the bill.

The failure mode in plain terms

The immediate failure mode is purely financial: you pay six times as much for a control plane that is doing the same job it did the day before. That is the easy part to reason about, and the easy part to fix.

The harder failure mode is what happens if you let extended support run its full 12 months and still do not upgrade. At the end of the extended-support window, EKS auto-upgrades the control plane for you, on its own schedule, and AWS states plainly that it cannot provide a specific time frame for that automatic update and that you will not receive a notification before it happens. An unattended control-plane bump on AWS time, rather than on a maintenance window you chose, is how a cost problem turns into an availability problem. The auto-upgrade moves only the control plane; your self-managed nodes and managed node groups stay on the previous version, which can leave the cluster in a version-skew state you did not plan for.

What to do before July 29, 2026

The goal is to land every 1.33 cluster on a standard-support version (1.34 or later) before the deadline, on your own maintenance window, with add-ons and nodes upgraded in step. A control-plane upgrade in EKS is one minor version at a time, so plan the hops accordingly and leave slack for testing between them.

• Inventory every cluster and its version across all accounts and regions. Confirm which are on 1.33. The command aws eks describe-cluster-versions returns the end-of-standard-support date per version.
• Scan for deprecated and removed APIs before upgrading. Run a tool such as kube-no-trouble or Pluto against live manifests and Helm releases, and check the EKS upgrade insights in the console, so a removed API version does not break a controller after the bump.
• Pin and pre-stage add-on, CSI, and CNI versions. Verify the VPC CNI, kube-proxy, CoreDNS, EBS and EFS CSI drivers, and any third-party operators all have versions that support your target Kubernetes version, and upgrade them in the supported order.
• Plan the node AMI path explicitly. Kubernetes 1.32 was the last version for which EKS published Amazon Linux 2 optimized AMIs, and EKS stopped releasing AL2 AMIs entirely on November 26, 2025. For 1.33 and later, only AL2023 and Bottlerocket AMIs are published, so an AL2-based managed or self-managed node group needs an OS migration, not just a version bump. Validate bootstrap scripts and launch templates against AL2023.
• Test on a non-production cluster first, then upgrade the control plane, then the nodes, then re-verify add-ons. Keep the control plane and nodes within the supported version skew throughout.
• If a specific cluster genuinely cannot move in time, treat extended support as a deliberate, budgeted decision with an owner and a date, not as an accident.

For a structured way to fold this kind of recurring lifecycle cost into your AWS spend planning, see our cloud cost optimization service.

An honest caveat

Extended support is not a punishment, and panic-upgrading is its own risk. AWS continues to ship control-plane security patches, plus patches for the VPC CNI, kube-proxy, and CoreDNS add-ons and the published EKS-optimized AMIs, for versions in extended support. For a small number of clusters with a hard dependency on a 1.33-era behavior, paying the surcharge for a few weeks while you test a clean upgrade is a perfectly reasonable, defensible choice. The surcharge is real money, but a rushed upgrade that breaks an Ingress controller or a CSI driver in production is worse. The point is to make the choice on purpose and with a date attached, not to discover it on an invoice. Treat the six-times rate as a clock, not a cliff.

The version lifecycle is also a moving target by design, with a new EKS minor version on average every four months. This same deadline mechanic is the pattern behind other AWS managed-service end-of-support events, such as the RDS for MySQL 8.0 end of standard support; the playbook of inventory, compatibility scan, staged upgrade, and a planned window is the same.

How a senior team de-risks it

A senior DevOps team does not experience an EKS end-of-support date as a surprise, because the version calendar is a tracked, owned artifact, with the next two or three end-of-standard-support dates on the roadmap and an owner for each. Upgrades are routine and rehearsed: API-deprecation scans in CI, add-on versions pinned in infrastructure-as-code, node groups templated so an AMI family change is a reviewed pull request rather than a scramble, and a non-production cluster that always gets the upgrade first. The six-times surcharge then becomes a deliberate lever you can choose to pull for a specific cluster, with a budget and an exit date, instead of a penalty the invoice applies for you. The difference between the two outcomes is not luck or AWS pricing. It is whether someone owns the calendar.

Sources

• Understand the Kubernetes version lifecycle on EKS (AWS EKS User Guide, release calendar)
• Amazon EKS pricing (standard vs extended support control-plane rate)
• Review release notes for Kubernetes versions on extended support (AWS EKS User Guide)
• Guide to EKS AL2 and AL2-Accelerated AMIs transition (AWS EKS User Guide)