EKS 1.34 standard support ends on December 2, 2026. For a startup team, that date is both an engineering deadline and a budget decision. If an eligible cluster remains on the version under extended support, the published control-plane price rises from $0.10 to $0.60 per cluster-hour. The application may look unchanged while the bill changes underneath it.
The useful response is to establish what you run, what blocks an upgrade and how long testing will take. A date alone does not tell you whether a cluster is ready. This guide explains the cost and the work to plan, using the AWS Kubernetes version calendar and AWS EKS pricing verified on October 7, 2026.
What the December deadline means
Amazon EKS provides standard support for a Kubernetes minor version for about 14 months, followed by 12 months of extended support. These are service support periods, not promises that your workload will remain compatible without maintenance. For 1.34, the verified standard-support end date is December 2, 2026, and the extended-support end date is December 2, 2027.
Do not confuse this with EKS 1.33: its standard support ended July 29, 2026. A fleet containing both versions therefore has different cost exposure today. Check every account and Region, including staging, development and clusters created for temporary projects. A cluster with no running application pods can still incur the control-plane charge.
AWS support policies and the configured upgrade policy determine what happens to a cluster at a support boundary. Extended support should be a deliberate decision, with an owner and an exit plan. At the end of extended support, AWS can automatically upgrade an unsupported cluster. Waiting for that event gives your team less control over the timing and preparation.
Put a number on the delay
At a planning assumption of 730 hours per month, one standard-support cluster costs $73 for its control plane. The same number of cluster-hours at the extended-support rate costs $438. The incremental estimate is $365 per cluster per month, or $1,095 for three clusters. These figures are derived from the published hourly rates, not a forecast of your whole AWS bill.
Compute, EBS volumes, load balancers, networking and other AWS resources are separate. A calendar month also has its own number of hours. Use actual cluster-hours and billing records for reconciliation. Our extended-support cost calculator helps compare the two rates without requesting access to your account.
That surcharge is not automatically larger than the cost of a rushed upgrade. An application with an untested storage migration or a fragile controller may need time to prepare. The point of calculating exposure is to make the tradeoff explicit: what is the additional spend, what does the delay buy, and when will the blocker be removed?
Start with an inventory, not the update command
Record each cluster’s Kubernetes version, support policy, account, Region and owner. Then identify the add-ons, node provisioning method and controllers that make the cluster useful. Include VPC CNI, CoreDNS, kube-proxy, CSI drivers, ingress components and admission webhooks. Record how versions are managed: an EKS add-on, a Helm release or another deployment mechanism.
Inspect EKS upgrade insights and API usage alongside the manifests your team maintains. Removed APIs can appear in generated manifests, operator code or infrequent automation. A dashboard that looks quiet during a short observation window is not proof that no old client will return. Check scheduled jobs and integrations that run only during releases or maintenance.
Make the target version and sequence explicit. EKS control-plane updates move one minor version at a time. An EKS 1.35 upgrade should therefore be planned as a compatibility step from 1.34, with a supported path for add-ons and nodes. Do not assume the latest version is the right destination without checking your dependencies.
Rehearse the parts that can interrupt service
A representative test cluster should exercise the application paths that matter: login, reads and writes, background workers, ingress, DNS and storage. Include your monitoring and alerting so the team can distinguish expected replacement activity from an application problem. Testing only whether pods become Ready leaves many failure modes invisible.
Node replacement needs particular attention. Review PodDisruptionBudgets, replica distribution, topology constraints and spare capacity. A restrictive disruption budget can prevent a drain; a permissive one does not make a single-replica service resilient. Check whether a new node can pull images, attach storage and satisfy scheduling constraints before relying on it during the change.
Write down the acceptance criteria and the person who makes the go or stop decision. A rehearsal should produce evidence and timings your team can use to choose a production window. It should also expose assumptions about dependencies outside Kubernetes, including databases, queues and identity providers.
Be precise about recovery
Before scheduling the 1.34 upgrade, document whether your cluster is eligible for version rollback and which application changes need a separate recovery path. The upgrade checklist’s recovery section explains the window, checks and limits to include in that plan.
If the recovery plan involves another cluster, validate that path before the production change. Infrastructure definitions, restored data, credentials, networking and traffic routing all need to work together. A backup inventory is useful evidence, but it is not a successful restore. Scope any recovery rehearsal separately, especially if it creates resources or handles production data.
Turn the deadline into owned work
Create a short plan with blockers, owners, prerequisites and a test window. Separate the control-plane update from the rest of the work so add-on reconciliation and node replacement do not disappear into a single checkbox. Reserve time after the change to verify application behavior, alerts and the actual cluster state.
As of October 8, 2026, there are 55 days until the 1.34 standard-support deadline. That is a useful planning window only if someone owns the preparation now. Recheck the AWS calendar before executing; this article records verified dates rather than inferring future releases.
If you need help establishing the plan, the EKS Production Readiness Review is a one-week, read-only assessment for $1,500. It identifies upgrade blockers and prioritizes the work. Upgrade assistance is quoted afterward, once the dependencies and customer obligations are understood.