What does leaving EKS Extended Support take?

This article draws on support work performed in August 2026. Client and infrastructure identifiers have been anonymized.

The starting point was extended support cost

Client A ran a monitoring platform on Amazon EKS. Services were running, but the Kubernetes version had passed its standard support period and entered Extended Support.

EKS version support costs $0.10 per cluster-hour under standard support and $0.60 under extended support. The same cluster therefore incurs an additional $0.50 per hour depending on its support tier.¹

The client asked us to move to a version under standard support. Changing the control plane version alone would not complete the work.

Our initial checks found a Kubernetes 1.32 control plane with Kubernetes 1.29 workers on Amazon Linux 2. Databases and workloads using persistent volumes shared those nodes.

Before reducing the support charge, we needed to establish whether the environment could run again on new nodes.

We prepared recovery options before upgrading

We inventoried running workloads, persistent volumes, add-ons, and node configuration. We paid particular attention to single-instance components and services whose storage would need to reattach during a node move.

We created snapshots of 9 associated EBS volumes and confirmed that every snapshot completed. We restored selected snapshots as temporary volumes to check that volume creation worked.

That test had a defined scope. EBS snapshots and volume restoration are part of recovery preparation; they do not prove database application consistency or complete service recovery.

A recovery plan needs more than a version reversal procedure. Current AWS documentation describes rollback to the previous minor version within 7 days of completing an upgrade, provided the cluster meets the prerequisites. Add-ons and regular managed node groups require separate handling. This current feature guidance is distinct from the EBS restoration checks performed in this case.²

New nodes exposed an image supply problem

We created an Amazon Linux 2023 node group to replace the Amazon Linux 2 group and moved workloads incrementally.

Some containers could not download their images. They were database and cache images that had been running successfully on the old nodes.

The image cache on those nodes had masked the problem. When a new node requested the same tag, it could no longer retrieve that tag from the registry.

We checked the running image digests and their availability in the registry. We pinned deployment configuration to obtainable digests, then verified actual downloads and execution on the new nodes. We also applied the changes to the GitOps-managed configuration.

A running container does not establish that the same container can be redeployed after a failure. That needs a separate check.

Pinning a digest improves deployment reproducibility. It does not resolve vulnerabilities or guarantee long-term image retention. A private registry copy and an image refresh policy remained follow-up work.

We upgraded one minor version at a time and tested storage behavior

After preparing the nodes, we upgraded Kubernetes in this sequence:

1.32 → 1.33 → 1.34 → 1.35 → 1.36

EKS requires upgrades one minor version at a time. At each stage, we reviewed compatibility findings and checked the control plane, worker nodes, and associated add-ons.³

Reaching the final target version was not necessary just to exit extended support. In this engagement, the scope with the client continued beyond the return to standard support and reached 1.36.

We also updated the EBS CSI storage driver for the target version. Rather than stopping at running driver Pods, we used temporary volumes to test:

• Whether data written before the upgrade could still be read unchanged afterward.
• Whether a volume reattached when its Pod moved to another node in the same availability zone.
• Whether a new volume could be created, written to, and read after the update.

We removed the temporary test resources and retained the existing persistent volumes and backup snapshots.

Back on standard support, with infrastructure checks recorded

These were the infrastructure observations at the post-upgrade checkpoint.

At published rates, the support charge difference is $365 per cluster for a 730-hour month, or $4,380 for an 8,760-hour year. This is a reduction of about 83% in that fee category.¹

The difference is neither a reduction in the entire AWS bill nor savings confirmed on an actual invoice. EC2, EBS, networking, backup retention, and transition costs require separate accounting. Its scope also differs from our AWS account rightsizing case, which addressed the wider account cost.

Healthy Pods still needed a separate external collection check

The engagement also surfaced follow-up work. After the cluster upgrade, some externally installed Grafana Agents were reported as showing Agent Down.

The investigation found records of HTTP 500 responses to Cortex metric ingestion requests during node rolling. Logs reported that too few healthy replicas were available to process writes.

Those records alone do not establish the cause of an Agent Down indication that persists afterward. The agent status rules, last collection time, retries, and actual recovery of data ingestion still need to be checked.

We therefore do not describe this result as a zero-downtime migration or complete restoration of every collection path. The verified outcome was a return to standard support and the recorded infrastructure checks. End-to-end collection from external agents remained a separate task.

Kubernetes health and the client's definition of a healthy service are different. Verification needs to extend beyond running Pods to external data arriving, being stored, and appearing on dashboards.

Making the next upgrade a smaller task

Extended Support charges resulted from delayed version maintenance. The difficulties in the transition, however, involved the node operating system, image supply, storage, and service availability.

Client A's follow-up work addressed those areas: managing support deadlines in advance, retaining container images, improving the availability of single-instance components, and testing collection from external agents through to dashboards.

We moved Client A's EKS cluster to a version under standard support and identified the operational work to complete before the next maintenance window.

When preparing an EKS upgrade, check more than the current version. Establish whether workloads can be redeployed on new nodes, data can be recovered, and external service paths can be verified.

To review EKS support deadlines and upgrade readiness, see the assessment and migration scope of our Cloud & Infrastructure service.

References