EKS Extended Support: Plan an Upgrade Without Rushing Production

An upgrade is a delivery project, not a console button

An EKS extended-support charge is often the visible symptom of an ownership problem. The cluster kept running, application delivery took priority, and nobody owned the next version change. The bill eventually makes that backlog hard to ignore.

The right response is a planned upgrade with evidence that workloads still behave correctly. This guide focuses on leaving extended support safely. For the wider operating model, see our managed Kubernetes service.

Establish the cost and the deadline

Record the current Kubernetes version, its support end dates, the cluster's upgrade policy and the current standard-versus-extended support rates. Use the live EKS release calendar and EKS pricing page when making the decision. A date or rate copied into a ticket months ago can be stale by the time someone acts on it.

Keep the control-plane support charge separate from worker nodes, storage, load balancers and other services. Upgrading the Kubernetes version does not remove those other costs.

For a planning worksheet, multiply the applicable hourly difference by the hours you expect to remain in extended support. Compare that avoidable charge with the engineering effort, required testing and business risk. This helps prioritize the work without pretending the upgrade is free.

Check the actual upgrade policy. Disabling extended support allows AWS to upgrade the control plane at the end of standard support. That setting is not a substitute for testing application compatibility in advance.

Build an inventory before choosing a target version

Start with a read-only cluster description:

aws eks describe-cluster --name YOUR_CLUSTER --region YOUR_REGION \
  --query 'cluster.{Version:version,Status:status,UpgradePolicy:upgradePolicy}'

kubectl get nodes
kubectl get deployments,statefulsets,daemonsets -A
kubectl get poddisruptionbudgets -A

Confirm your kubeconfig points at the intended cluster before running the Kubernetes commands. Inventory managed and self-managed add-ons, network and storage drivers, ingress controllers, admission webhooks, autoscalers and operators. Include the team or vendor that owns each component.

For every component, write down the deployed version, the supported target combination and the required upgrade step. An unsupported controller should become a visible blocker with an owner, not a surprise during the maintenance window.

Turn compatibility findings into a sequence

AWS's cluster upgrade guidance distinguishes the control plane from the data plane and calls out removed APIs, add-on compatibility, capacity and disruption planning. Work through the documented version transitions rather than assuming you can jump directly to any newer minor version.

Use upgrade insights alongside your own manifests, deployment history and workload tests. A clean report is useful evidence, but it cannot prove that a rarely used application workflow will still work.

Write the sequence as an executable checklist. Each step needs a prerequisite, an owner, a verification command or application test, and a stop condition. For example, do not drain the next node group while the previous group's replacement pods are still failing readiness checks.

Rehearse the things that make upgrades fail

Our suggested rehearsal covers four areas:

1. Scheduling: replacement pods fit, required capacity is available, and workloads are distributed as intended.
2. State: persistent volumes attach correctly and the team has tested a restore of important data.
3. Traffic: ingress, service discovery, external dependencies and background consumers work after replacement.
4. Delivery: the pipeline can deploy and roll back an application version on the upgraded environment.

Use representative staging workloads and controlled load. An empty test cluster mainly proves that an empty cluster can upgrade.

Record how long each step took and which dashboards or checks detected failures. That rehearsal becomes the basis for the production window and the staffing decision.

Be precise about rollback

EKS does not support downgrading a control plane to an earlier Kubernetes version. A plan that simply says "roll back the cluster" is incomplete. Verify this constraint in the version lifecycle documentation.

An application rollback, restoring data and moving traffic to another cluster are different operations. If you choose a separate replacement cluster, account for data synchronization, DNS, credentials, background consumers and the extra operating cost while both environments exist.

For an in-place upgrade, define which failures can be repaired forward and what recovery remains possible. Have the people who operate the application approve that plan before the production change.

Define done before the window starts

Close the upgrade only when the target control plane, nodes and add-ons are in the intended supported state; representative user journeys pass; error and latency metrics are acceptable; scheduled jobs run; and the team has a dated plan for the next version review.

Recheck billing after the relevant charges appear. A successful technical upgrade and a verified billing change are separate acceptance items.

If your team needs help turning this into a scoped project, discuss the cluster upgrade with InstaDevOps. Bring versions, deadlines and the workload constraints. We can agree the assessment, delivery steps and acceptance evidence before implementation; this does not imply guaranteed zero downtime or an unstaffed response commitment.