> ## Content Index > Fetch the complete content index at: https://stackurity.ai/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Amazon EKS 1.34 end of life: December 2, 2026 and what to do - URL: https://stackurity.ai/blog/amazon-eks-1-34-end-of-life/ - Published: 2026-11-08T01:35:03.000Z - Updated: 2026-11-08T01:35:03.000Z - Description: Amazon EKS 1.34 reaches end of life on December 2, 2026. See who is affected, how to check a cluster and how to plan the upgrade. - Author: Stackurity Research Team - Tags: Cloud Services, #deep-dive ## TL;DR - Amazon EKS 1.34 reaches end of life on December 2, 2026, according to endoflife.date. Standard support for the line ends that day. - The line was released on October 6, 2025\. The same record lists an extended support date of December 2, 2027. - No exploited vulnerability is tied to this date. It is a planning deadline for every cluster still on this Kubernetes version. - Find every EKS cluster and node group on 1.34, then schedule the upgrade to a version AWS still supports as standard. - Stackurity matches end-of-life dates against your inventory every day, including EKS, so clusters on this line show up without a manual audit. ## What reaches end of life, in plain English Amazon EKS is the managed Kubernetes service from AWS. AWS runs the control plane for you, and each Kubernetes minor version it offers is supported for a limited time. When that window closes, the version reaches end of life: AWS stops treating it as a version it fully supports, and fixes concentrate on newer versions. The [endoflife.date record for Amazon EKS](https://endoflife.date/amazon-eks) shows a release date of October 6, 2025 for version 1.34 and an end of life date of December 2, 2026\. It also lists an extended support date of December 2, 2027\. In practice that gives you two dates: December 2, 2026 is the end of standard support, and December 2, 2027 is the end of the extended period that the vendor offers beyond it. The record does not mark the version as a long term support release. Two things get confused here. The control plane is the part AWS operates, and its version is the one in the record. Your worker nodes, managed add-ons and any tooling that talks to the cluster each have their own versions and their own upgrade steps, and they have to stay within the range the control plane supports. ## Why it matters now Nothing breaks on the day. Your workloads keep running and your deployments keep working. What changes is the position you are in the next time a Kubernetes or EKS flaw is disclosed: for a version in standard support, the fix is available to you; for a version past it, you are asked to upgrade first, usually under time pressure and with a flaw already public. Kubernetes upgrades are also not a quick change. You have to check that the APIs your manifests use still exist, that your operators and ingress controllers support the new version, and that node groups can be rolled without dropping traffic. Doing that for several clusters, one at a time, takes weeks of calendar time even when each upgrade is short. The deadline is close enough that the work should be on a calendar now. There is also the audit angle. Customers and auditors ask which platform components are still supported by their vendor. A cluster on a version beyond standard support becomes a finding that needs an exception and an owner. It is cheaper to have the upgrade dated before the deadline than to explain afterwards why there was no plan. ## Am I affected? You are affected if any EKS cluster you run, in any account or region, uses Kubernetes version 1.34, whether in production, staging or a test environment nobody owns any more. Node groups that were created on 1.34 and never moved belong in the same list. To check one cluster by hand, ask AWS for the control plane version, then ask the cluster itself: ``` aws eks describe-cluster --name example-cluster --query cluster.version kubectl version kubectl get nodes ``` The first command prints the version of the control plane as AWS reports it. The second shows the client and server versions of the cluster you are connected to. The third lists the nodes with the kubelet version each one runs, which can lag behind the control plane. Repeat for every cluster and every region, since a command only answers for one cluster at a time. Replace `example-cluster` with the name of your cluster. ## How to upgrade Amazon EKS 1.34 before December 2, 2026 1. Make an inventory of every EKS cluster, with its control plane version, node group versions, owner and the applications that depend on it. Mark everything on 1.34. 2. Pick the Kubernetes version you will move to, using the AWS documentation for the versions EKS currently offers in standard support, and read its release notes for removed APIs and add-on requirements. 3. Rehearse on a non-production cluster that matches production: upgrade it, redeploy your workloads and run your application tests, looking for deprecated or removed API versions in your manifests and charts. 4. Upgrade the control plane of each production cluster in a maintenance window, one minor version at a time, since Kubernetes does not support skipping versions. 5. Upgrade managed add-ons, then roll the node groups to the new version so the nodes catch up with the control plane, watching that pods reschedule cleanly. 6. Confirm each cluster and node reports the new version with the commands above, and record the date of the upgrade against the cluster. If the upgrade cannot land before December 2, 2026, write down the exception with an owner and a date, read the AWS documentation on extended support for the line, and keep the cluster's network access and permissions as tight as you can while the work is scheduled. For help ordering work by urgency, see how Stackurity [turns findings into upgrade cards](https://stackurity.ai/docs/remediation). ## How to check with Stackurity Stackurity keeps one live inventory of the software on your servers, deployed applications, repositories, container images, Kubernetes and managed services such as EKS. End-of-life data is matched against that inventory every day, so a cluster on a version that is about to leave support appears in a short list, most urgent first, next to the vulnerabilities that matter more. The [Kubernetes documentation](https://stackurity.ai/docs/kubernetes) explains what is read from a cluster. After you upgrade, check again asks for a fresh report and records whether the issue is really gone, so you see the old line disappear instead of assuming the maintenance window worked. Read how [verification](https://stackurity.ai/docs/verification) works. The core is open source, and Stackurity Cloud offers a 14-day free trial without a card: [start a free trial](https://app.stackurity.dev/signup?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=cloud-services&utm%5Fcontent=amazon-eks-1-34-end-of-life). Other platforms are leaving support too. Our guides on [a PostgreSQL release leaving support](https://stackurity.ai/blog/postgresql-14-end-of-life/) and [a .NET runtime leaving support](https://stackurity.ai/blog/dotnet-8-end-of-life/) cover the database and runtime that often sit next to a cluster. ## FAQ ### When does Amazon EKS 1.34 reach end of life? According to endoflife.date, Amazon EKS 1.34 reaches end of life on December 2, 2026\. The same record lists an extended support date of December 2, 2027 for the line. ### Is Amazon EKS 1.34 still getting security updates? Until December 2, 2026 it is inside its standard support window. After that date, plan on it being outside standard support, and read the AWS documentation for exactly what the extended support period covers. ### What is extended support for Amazon EKS 1.34? The endoflife.date record shows December 2, 2027 as the extended support date. Extended support is a vendor program with its own terms, so check the AWS documentation for what it includes and what it costs before you rely on it. ### How do I check which Kubernetes version my EKS cluster runs? Ask AWS for the cluster version with the command shown above, or run the Kubernetes version command against the cluster. Check every cluster in every region and account, since forgotten test clusters are the ones that fall behind. ### Must worker nodes be upgraded as well as the control plane? Yes, plan for both. The control plane version is only part of the story: node groups, managed add-ons and any self-managed nodes must be moved to a version the new control plane supports, as the AWS upgrade documentation describes. Sources: [endoflife.date, Amazon EKS](https://endoflife.date/amazon-eks) and [Stackurity product facts](https://stackurity.ai/llms.txt).