Kubernetes 1.34 Hit End of Life on EKS: Find Every Affected Cluster Before the 6x Bill Lands

Key Points:

• On Amazon EKS, a cluster that passes its end-of-standard-support date is automatically enrolled in Extended Support, and the control plane price goes from $0.10 to $0.60 per cluster-hour, exactly 6x, for up to 12 extra months. Nothing breaks and nothing stops. The bill just changes.
• Upstream Kubernetes 1.34 reached end of life on October 27, 2026. On EKS, the AWS release calendar lists December 2, 2026 as the end of standard support for 1.34, which is the day Extended Support billing starts. Check the calendar for your own versions before acting, because dates shift and this post will age.
• At $0.60 per hour, one forgotten cluster costs about $438 per month instead of $73. A 20-cluster estate pays roughly $8,760 per month instead of $1,460.
• Find every affected cluster in one pass by looping aws ec2 describe-regions, aws eks list-clusters and aws eks describe-cluster across every AWS account, not just the one you log into.
• EKS upgrades one minor version at a time. Each hop is control plane, then nodes, then add-ons (CoreDNS, kube-proxy, VPC CNI, EBS CSI driver). The control plane is the easy part. Stale Helm charts, controllers pinned to old versions, and PodDisruptionBudgets are what stall the job.
• GKE and AKS sell the same tier at the same $0.60 per cluster-hour, so this is an industry pricing pattern rather than an AWS quirk.

The cheapest line on most Kubernetes bills is about to become six times more expensive, and most teams will find out from Cost Explorer rather than from a calendar. An EKS control plane costs $0.10 per hour in standard support and $0.60 per hour in Extended Support, according to the Amazon EKS pricing page. AWS moves your cluster from one to the other automatically.

So, to the question I keep getting this week: yes, Kubernetes 1.34 is out of upstream support as of October 27, 2026, and yes, EKS clusters still on 1.34 start billing at Extended Support rates when standard support ends on the date AWS publishes for 1.34 (December 2, 2026 on the calendar today). This post walks through the sweep that finds every affected cluster, the checks to run before you touch anything, and the upgrade sequence that gets you out.

What exactly happens when an EKS cluster passes end of standard support?

AWS does not break, freeze or delete the cluster. It enrolls the cluster in Extended Support and bills the control plane at $0.60 per cluster-hour instead of $0.10 for up to 12 more months, then auto-upgrades the control plane once Extended Support ends.

The mechanism is the cluster's upgrade policy. AWS documents that the upgrade policy is set to EXTENDED by default for all new and existing clusters, so you never click anything to opt in. Billing starts at the beginning of the end-of-standard-support day, UTC. AWS posts a notice to the AWS Health Dashboard at least 60 days ahead, which helps if somebody reads the Health Dashboard for every account.

Here is the arithmetic, using 730 hours per month:

• Standard support: $0.10 x 730 = $73 per cluster per month
• Extended Support: $0.60 x 730 = $438 per cluster per month
• The difference is $365 per cluster per month, or $4,380 per cluster over a full 12 months of Extended Support
• At 20 clusters: $1,460 per month becomes $8,760 per month

The surcharge only applies to the control plane. Worker nodes, EBS volumes, load balancers and data transfer bill exactly as before.

What you keep in Extended Support: AWS still ships security patches for the control plane, patches for the VPC CNI, kube-proxy and CoreDNS add-ons, updated EKS optimized AMIs, and technical support. What you give up is everything new: new Kubernetes features, and any third-party controller that has dropped your version from its support matrix.

The alternative is setting the upgrade policy to STANDARD. That refuses Extended Support entirely, and AWS auto-upgrades the cluster at the end of standard support instead. You get a predictable bill and an unpredictable upgrade date. My rule: STANDARD for dev, preview and CI clusters where an unplanned upgrade is a shrug, and EXTENDED (paid, deliberate, ticketed) for production clusters you cannot upgrade in time.

One detail matters a lot this month. AWS states that once a cluster has entered Extended Support, you cannot disable it. To change the policy, the cluster has to be on a version in standard support. If you want STANDARD on a 1.34 cluster, set it before the deadline:

aws eks update-cluster-config \
  --name <cluster-name> \
  --upgrade-policy supportType=STANDARD

Do not take my dates as final. Run aws eks describe-cluster-versions or open the AWS EKS release calendar for your version. That advice applies to this post too.

aws eks describe-cluster-versions \
  --query 'clusterVersions[].[clusterVersion,status,endOfStandardSupportDate,endOfExtendedSupportDate]' \
  --output table

How do I find every EKS cluster running an end-of-life Kubernetes version?

Run a scripted sweep over every AWS account and every enabled region with aws eks list-clusters and aws eks describe-cluster. The clusters that cost you 6x are usually the ones nobody remembers creating, in regions nobody opens.

Start with a single account. This script prints account, region, cluster name, Kubernetes version, upgrade policy and creation date for every cluster the current credentials can see:

#!/usr/bin/env bash
# eks-version-sweep.sh - every EKS cluster in every enabled region of the current account
set -euo pipefail

ACCOUNT=$(aws sts get-caller-identity --query Account --output text)

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  clusters=$(aws eks list-clusters --region "$region" --query 'clusters[]' --output text 2>/dev/null || true)
  for cluster in $clusters; do
    aws eks describe-cluster --region "$region" --name "$cluster" \
      --query '[cluster.name,cluster.version,cluster.upgradePolicy.supportType,cluster.createdAt]' \
      --output text \
    | awk -v a="$ACCOUNT" -v r="$region" '{print a"\t"r"\t"$0}'
  done
done

Then filter for anything on 1.34 or older:

./eks-version-sweep.sh | awk -F'\t' '{split($4,v,"."); if (v[2] <= 34) print}'

Multi-account is where most audits fail. People run the sweep in the account their SSO session defaults to and call it done. If you use AWS Organizations, iterate every active account and assume a role into each one:

#!/usr/bin/env bash
# eks-org-sweep.sh - run eks-version-sweep.sh in every active account of the organization
ROLE=OrganizationAccountAccessRole   # replace with your cross-account read role

for acct in $(aws organizations list-accounts --query 'Accounts[?Status==`ACTIVE`].Id' --output text); do
  creds=$(aws sts assume-role \
    --role-arn "arn:aws:iam::${acct}:role/${ROLE}" \
    --role-session-name eks-version-sweep \
    --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
    --output text) || { echo "skip ${acct}: cannot assume ${ROLE}" >&2; continue; }
  read -r AK SK ST <<< "$creds"
  AWS_ACCESS_KEY_ID="$AK" AWS_SECRET_ACCESS_KEY="$SK" AWS_SESSION_TOKEN="$ST" ./eks-version-sweep.sh
done

Without Organizations, loop over named profiles instead: for p in $(aws configure list-profiles); do AWS_PROFILE=$p ./eks-version-sweep.sh; done.

Then cross-check against three other signals:

1. EKS cluster insights. The console's upgrade insights flag version end-of-support and deprecated API usage per cluster. From the CLI: aws eks list-insights --cluster-name <name> --region <region>.
2. Cost Explorer. Filter Service to Amazon Elastic Kubernetes Service and group by Usage Type. If an extended-support usage line appears next to the standard per-cluster hours, you are already paying, and that is the fastest proof you can show finance.
3. AWS Health Dashboard. AWS posts version end-of-support notices there. Use it as a second net, and check it in every account, not only the payer account.

The clusters that slip through are almost never the production ones in Terraform. They are the workshop cluster from a conference, the CI cluster someone created by hand, and the proof of concept from last year that still has a node group running.

Most estates are not single-cloud, so run the same sweep on GKE and AKS while you are at it:

for p in $(gcloud projects list --format='value(projectId)'); do
  gcloud container clusters list --project "$p" \
    --format='table(name,location,currentMasterVersion,releaseChannel.channel)' 2>/dev/null
done

# AKS: current subscription
az aks list --query '[].{name:name,rg:resourceGroup,version:currentKubernetesVersion,tier:sku.tier}' -o table

What actually breaks during an EKS upgrade, and how do I check before I start?

The managed control plane upgrade is reliable and keeps the API endpoint available. What breaks is your side of the cluster: stale manifests and Helm charts, third-party controllers that do not support the new version, node groups outside the version skew window, and node drains that cannot finish.

AWS performs rolling updates of API server instances during an upgrade, so clients that reconnect properly (recent kubectl and the official client libraries do) see no outage. If a health check fails, EKS reverts the infrastructure deployment and the cluster stays on the old version.

The good news for this specific hop: the Kubernetes deprecated API migration guide lists no API removals in 1.35, 1.36 or 1.37. The most recent removal was flowcontrol.apiserver.k8s.io/v1beta3 in 1.32. That makes the 1.34 to 1.35 hop gentler than the 1.24 or 1.25 upgrades many teams still remember, but it is no excuse to skip detection. Clusters that drifted for a while often carry manifests from older eras, and the same checks find them.

Check live traffic first, then static manifests and Helm releases:

kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

# Static scan of the cluster and Helm releases (kube-no-trouble)
kubent

# Static scan of Helm releases and manifest files (Pluto)
pluto detect-helm -o wide
pluto detect-files -d ./manifests

kubent and Pluto catch deprecated apiVersion values before you apply them. The metric catches the ones a client calls at runtime, which static tools cannot see.

Version skew decides how far nodes can lag. The upstream version skew policy allows kubelet to be up to three minor versions older than kube-apiserver. AWS still asks that managed nodes and Fargate nodes run the same minor version as the control plane before each control plane update, so plan to bring nodes along on every hop.

EKS pins managed add-on versions per Kubernetes version. List the compatible versions before each hop:

for addon in coredns kube-proxy vpc-cni aws-ebs-csi-driver; do
  aws eks describe-addon-versions --kubernetes-version 1.35 --addon-name "$addon" \
    --query 'addons[].addonVersions[].[addonVersion,compatibilities[0].defaultVersion]' --output table
done

In my experience, the components that actually break are third-party: the AWS Load Balancer Controller, ingress-nginx, cert-manager, cluster-autoscaler (its minor version should match your Kubernetes minor version), Karpenter, service meshes, metrics-server, and Prometheus operator CRDs. Check each one's compatibility matrix against your target version.

Then there are the two mechanical stallers. A PodDisruptionBudget that allows zero disruptions blocks the drain that a managed node group rolling update depends on. And EKS needs up to five free IP addresses in the cluster subnets just to update the control plane, plus room for surge nodes.

Here is the pre-flight checklist I would paste into the upgrade ticket:

1. Confirm the target version's dates with aws eks describe-cluster-versions.
2. Review EKS upgrade insights: aws eks list-insights --cluster-name <name>.
3. Check live deprecated API calls: kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis.
4. Run kubent and pluto detect-helm -o wide, then fix every finding.
5. Confirm node versions match the control plane: kubectl get nodes.
6. List compatible add-on versions with aws eks describe-addon-versions for CoreDNS, kube-proxy, VPC CNI and EBS CSI.
7. Check third-party controller compatibility matrices (ingress, cert-manager, autoscaler or Karpenter, mesh, metrics-server, Prometheus operator).
8. Find blocking PDBs: kubectl get pdb -A and look for ALLOWED DISRUPTIONS at 0.
9. Check free IPs in the cluster subnets: aws ec2 describe-subnets --subnet-ids $(aws eks describe-cluster --name <name> --query 'cluster.resourcesVpcConfig.subnetIds' --output text) --query 'Subnets[].[SubnetId,AvailableIpAddressCount]' --output table
10. Take a backup (Velero or AWS Backup for EKS) and run the full path on a non-production clone first.

What is the fastest safe upgrade path from Kubernetes 1.34 to a supported version?

EKS does not let you skip minor versions, so you upgrade one hop at a time: control plane, then nodes, then add-ons, then verify, then the next hop. Getting from 1.34 to 1.35 is enough to stop the December 2 surcharge. Going to 1.37 takes three hops.

AWS is explicit that you can update only one minor version at a time. Here is the order for each hop:

1. Run the pre-flight checklist above.
2. Upgrade the control plane.
3. Upgrade managed node groups, or let Karpenter or Auto Mode replace nodes.
4. Upgrade the managed add-ons to the versions compatible with the new release.
5. Upgrade self-managed controllers (cluster-autoscaler, ingress, cert-manager).
6. Verify workloads, dashboards and alerts.
7. Start the next hop.

With the AWS CLI:

aws eks update-cluster-version --name <cluster> --kubernetes-version 1.35 --region <region>
aws eks describe-update --name <cluster> --update-id <update-id> --region <region>

# 2. Managed node groups (defaults to the cluster version and latest EKS optimized AMI)
aws eks update-nodegroup-version --cluster-name <cluster> --nodegroup-name <nodegroup>

# 3. Managed add-ons, using a version from describe-addon-versions
aws eks update-addon --cluster-name <cluster> --addon-name coredns \
  --addon-version <vA.B.C-eksbuild.N> --resolve-conflicts PRESERVE

With eksctl:

eksctl upgrade cluster --name <cluster> --version 1.35 --approve
eksctl upgrade nodegroup --cluster <cluster> --name <nodegroup> --kubernetes-version 1.35
eksctl update addon --cluster <cluster> --name coredns --version <vA.B.C-eksbuild.N>

AWS says the control plane update takes several minutes. I still budget about an hour per hop per cluster for the control plane, add-ons and verification, plus node rollout time that grows with node count and PDBs.

For nodes, you have two strategies. An in-place rolling update of a managed node group is the default and is fine for stateless fleets. Blue/green node groups (create a new group on the new version, cordon and drain the old one, delete it) cost more for an hour but give you a real rollback: uncordon the old group. With Karpenter, do not roll node groups at all. Update the AMI selection in your EC2NodeClass and let Karpenter's drift detection replace nodes within your disruption budgets.

Do non-production first, on the same day, using the same commands. You want the broken ingress controller to show up in staging first.

Do the timeline math honestly. Take 20 clusters across dev, staging and production, two hops each, at half a day per cluster-hop once you include node rollout and verification. That is 40 cluster-hops and about 20 engineer-days. With five weeks to December 2, that needs a project plan and an owner this week.

On rollback: EKS now lets you roll back an in-place upgrade to the previous minor version within 7 days. After that window, the only way back is a new cluster and a workload migration. Treat the upgrade as one-way in your planning, keep backups, and use the 7-day window as a safety net rather than a plan.

If you genuinely cannot finish a cluster in time, keep it on EXTENDED on purpose, attach a dated ticket with an owner, and move on. That is a decision with a known price. The expensive outcome is the cluster nobody listed.

Why do teams keep missing Kubernetes end-of-life deadlines?

Teams rarely miss these dates out of ignorance. They miss them because Kubernetes ships a new minor version about every four months, each EKS version gets 14 months of standard support, and upgrade work is invisible when it succeeds, so it loses every sprint planning to roadmap work.

AWS documents both numbers: upstream releases a minor version "on average once every four months," and EKS gives each one 14 months of standard support. Upstream itself provides about one year of patch support per minor version, per the Kubernetes releases page. So any estate is permanently a few months away from its next forced upgrade.

The incentives are lopsided. A perfect upgrade changes nothing anyone can see. A bad one causes an incident with your name on it. That asymmetry is why "next quarter" wins, and Extended Support is priced for exactly that loop. Every major cloud now sells it.

Cluster sprawl multiplies both sides. The CNCF Annual Cloud Native Survey published in January 2026 reports that 82% of container users run Kubernetes in production. Every team, environment and region that adds a cluster adds another $365 per month of potential surcharge and another upgrade to schedule.

Paying Extended Support for a cluster you will decommission in six weeks is the correct call. The failure mode is paying without knowing it. The fix is organizational:

• One named owner per cluster, recorded as a tag
• A recurring calendar entry tied to the AWS lifecycle page, 90 days before each end-of-standard-support date
• Kubernetes version drift on the same dashboard as cost, so the person who sees the bill also sees the cause

Do GKE and AKS charge for extended support the same way EKS does?

Yes. GKE and AKS both sell a paid extended-support tier, and both land at the same $0.60 per cluster-hour as EKS. The difference is that both are opt-in, while EKS enrolls you by default.

On GKE, the pricing page lists an extended period cluster management fee of $0.50 per cluster-hour on top of the regular $0.10, for a total of $0.60. It only applies to clusters enrolled in the Extended release channel, after their minor version leaves standard support, and the channel keeps a minor version supported for up to 24 months. The GKE release schedule currently shows standard support for 1.34 on GKE ending January 25, 2027, later than on EKS. When a version reaches end of support, GKE auto-upgrades the cluster.

On AKS, long-term support (LTS) adds a second year after the one-year community support window, for roughly 24 months in total. It requires the Premium tier and an explicit opt-in with --tier premium --k8s-support-plan AKSLongTermSupport. The Azure Retail Prices API lists the Long Term Support meter at $0.60 per cluster-hour (East US) versus $0.10 for the Standard tier. Microsoft also announced that from June 1, 2027, AKS will auto-upgrade clusters on unsupported versions after a 60-day grace period, without respecting maintenance windows or blocking PDBs.

The practical takeaway: run one version-drift inventory across all three clouds on a fixed cadence, rather than three consoles checked when somebody remembers.

How does Qovery keep Kubernetes clusters upgraded without a dedicated platform team?

Qovery runs managed Kubernetes clusters inside your own AWS, GCP, Azure or Scaleway account, or on your existing Kubernetes cluster, and performs the cluster version upgrades, including keeping cluster add-ons on compatible versions. Staying ahead of end of standard support stops depending on someone remembering.

The cluster, the VPC and the cloud bill stay in your account and your name, so your Savings Plans and committed-spend discounts keep applying. Qovery operates the cluster. It does not resell you compute.

On upgrades, Qovery moves the control plane and the nodes and keeps the add-ons it manages on versions compatible with the target release. That sequencing is exactly the work that takes weeks across a fleet when done by hand. If you would rather keep your own cluster, self-managed, on-prem or any distribution, Qovery plugs into it instead of creating one.

A few adjacent features make upgrades safer in practice. Preview environments per pull request let you test against a cluster on the new version with real changes. Auto-stop shuts down non-production environments outside working hours. Git-push deployments and per-environment RBAC mean the upgrade does not change how developers ship.

There are good alternatives, and I would rather you pick the right one:

• EKS Auto Mode and GKE Autopilot genuinely remove node-level toil, but each one keeps you on a single cloud.
• Azure AKS automatic upgrade channels handle patch and minor upgrades well, again on one cloud.
• eksctl plus a disciplined runbook works if upgrades are explicitly someone's job and stay on their calendar.
• Terraform with terraform-aws-eks provisions clusters reproducibly but leaves add-on and controller sequencing to you.
• Rancher is strong for fleet management if you already run a platform team.
• Porter, Northflank and Platform9 also offer managed Kubernetes experiences with different trade-offs on BYOC and cloud coverage, so compare them on your own requirements.

One limit applies to every option on this list. Qovery does not rewrite removed APIs in your manifests or Helm charts, and neither does any other platform. That part of the pre-flight checklist stays yours.

How do I audit and upgrade these clusters from Claude Code or Cursor?

Install the Qovery Agent Skills, connect the Qovery MCP Server, and your coding agent can list clusters, explain which ones are out of support, and help drive the upgrade. The MCP Server is read-only by default, so an audit cannot change anything.

Install the Agent Skills globally for your compatible agents (Claude Code, Cursor and others):

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope the install to the current project only:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Connect Claude Code to the Qovery MCP Server over OAuth. This is read-only, which is what an audit should be:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Only when you want the agent to change things, connect with write access. Write actions also require write access to be enabled in the Qovery Console under Settings > MCP Server:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills include qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup and qovery-preview. The Skills deploy. The MCP Server operates what already exists.

Then ask in plain language: "List my clusters and their Kubernetes versions, tell me which ones are past end of standard support, and what would break if I upgrade them." Setup details are in the AI agent quickstart and the Claude Code integration page.