Kubernetes rapidly evolves with new features, design updates, and bug fixes. The community releases new Kubernetes minor versions (such as 1.33) on average once every four months. Amazon EKS follows the upstream release and deprecation cycle for minor versions. As new Kubernetes versions become available in Amazon EKS, we recommend that you proactively update your clusters to use the latest available version.
A minor version is under standard support in Amazon EKS for the first 14 months after itâs released. Once a version is past the end of standard support date, it enters extended support for the next 12 months. Extended support allows you to stay at a specific Kubernetes version for longer at an additional cost per cluster hour. If you havenât updated your cluster before the extended support period ends, your cluster is auto-upgraded to the oldest currently supported extended version.
Extended support is enabled by default. To disable, see Disable EKS extended support.
We recommend that you create your cluster with the latest available Kubernetes version supported by Amazon EKS. If your application requires a specific version of Kubernetes, you can select older versions. You can create new Amazon EKS clusters on any version offered in standard or extended support.
Available versions on standard supportThe following Kubernetes versions are currently available in Amazon EKS standard support:
For important changes to be aware of for each version in standard support, see Kubernetes versions standard support.
Available versions on extended supportThe following Kubernetes versions are currently available in Amazon EKS extended support:
For important changes to be aware of for each version in extended support, see Kubernetes versions extended support.
Amazon EKS Kubernetes release calendarThe following table shows important release and support dates to consider for each Kubernetes version. Billing for extended support starts at the beginning of the day that the version reaches end of standard support, in the UTC+0 timezone. The dates in the following table use the UTC+0 timezone.
NoteDates with only a month and a year are approximate and are updated with an exact date when itâs known.
To receive notifications of all source file changes to this specific documentation page, you can subscribe to the following URL with an RSS reader:
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/clusters/kubernetes-versions.adoc.atom1.33
April 23, 2025
May 29, 2025
July 29, 2026
July 29, 2027
1.32
December 11, 2024
January 23, 2025
March 23, 2026
March 23, 2027
1.31
August 13, 2024
September 26, 2024
November 26, 2025
November 26, 2026
1.30
April 17, 2024
May 23, 2024
July 23, 2025
July 23, 2026
1.29
December 13, 2023
January 23, 2024
March 23, 2025
March 23, 2026
1.28
August 15, 2023
September 26, 2023
November 26, 2024
November 26, 2025
1.27
April 11, 2023
May 24, 2023
July 24, 2024
July 24, 2025
Get version information with AWS CLIYou can use the AWS CLI to get information about Kubernetes versions available on EKS, such as the end date of Standard Support.
To retrieve information about available Kubernetes versions on EKS using the AWS CLIOpen your terminal.
Ensure you have the AWS CLI installed and configured. For more information, see Installing or updating to the latest version of the CLI.
Run the following command:
aws eks describe-cluster-versions
The command will return a JSON output with details about the available cluster versions. Hereâs an example of the output:
{
"clusterVersions": [
{
"clusterVersion": "1.31",
"clusterType": "eks",
"defaultPlatformVersion": "eks.21",
"defaultVersion": true,
"releaseDate": "2024-09-25T17:00:00-07:00",
"endOfStandardSupportDate": "2025-11-25T16:00:00-08:00",
"endOfExtendedSupportDate": "2026-11-25T16:00:00-08:00",
"status": "STANDARD_SUPPORT",
"kubernetesPatchVersion": "1.31.3"
}
]
}The output provides the following information for each cluster version:
clusterVersion: The Kubernetes version of the EKS cluster
clusterType: The type of cluster (e.g., "eks")
defaultPlatformVersion: The default EKS platform version
defaultVersion: Whether this is the default version
releaseDate: The date when this version was released
endOfStandardSupportDate: The date when standard support ends
endOfExtendedSupportDate: The date when extended support ends
status: The current support status of the version, such as STANDARD_SUPPORT or EXTENDED_SUPPORT
kubernetesPatchVersion: The specific Kubernetes patch version
In line with the Kubernetes community support for Kubernetes versions, Amazon EKS is committed to offering support for at least three Kubernetes versions at any given time. We will announce the end of standard support date of a given Kubernetes minor version at least 60 days in advance. Because of the Amazon EKS qualification and release process for new Kubernetes versions, the end of standard support date of a Kubernetes version on Amazon EKS will be after the date that the Kubernetes project stops supporting the version upstream.
A Kubernetes version received standard support for 14 months after first being available on Amazon EKS. This is true even if upstream Kubernetes no longer support a version thatâs available on Amazon EKS. We backport security patches that are applicable to the Kubernetes versions that are supported on Amazon EKS.
Yes. If any clusters in your account are running the version nearing the end of support, Amazon EKS sends out a notice through the AWS Health Dashboard approximately 12 months after the Kubernetes version was released on Amazon EKS. The notice includes the end of support date. This is at least 60 days from the date of the notice.
Amazon EKS supports all generally available (GA) features of the Kubernetes API. New beta APIs arenât enabled in clusters by default. However, previously existing beta APIs and new versions of existing beta APIs continue to be enabled by default. Alpha features arenât supported.
No. A managed node group creates Amazon EC2 instances in your account. These instances arenât automatically upgraded when you or Amazon EKS update your control plane. For more information, see Update a managed node group for your cluster. We recommend maintaining the same Kubernetes version on your control plane and nodes.
No. A self-managed node group includes Amazon EC2 instances in your account. These instances arenât automatically upgraded when you or Amazon EKS update the control plane version on your behalf. A self-managed node group doesnât have any indication in the console that it needs updating. You can view the kubelet version installed on a node by selecting the node in the Nodes list on the Overview tab of your cluster to determine which nodes need updating. You must manually update the nodes. For more information, see Update self-managed nodes for your cluster.
The Kubernetes project tests compatibility between the control plane and nodes for up to three minor versions. For example, 1.30 nodes continue to operate when orchestrated by a 1.33 control plane. However, running a cluster with nodes that are persistently three minor versions behind the control plane isnât recommended. For more information, see Kubernetes version and version skew support policy in the Kubernetes documentation. We recommend maintaining the same Kubernetes version on your control plane and nodes.
No. We strongly recommend running Fargate Pods as part of a replication controller, such as a Kubernetes deployment. Then do a rolling restart of all Fargate Pods. The new version of the Fargate Pod is deployed with a kubelet version thatâs the same version as your updated cluster control plane version. For more information, see Deployments in the Kubernetes documentation.
If you update the control plane, you must still update the Fargate nodes yourself. To update Fargate nodes, delete the Fargate Pod represented by the node and redeploy the Pod. The new Pod is deployed with a kubelet version thatâs the same version as your cluster.
Amazon EKS Hybrid Nodes supports the same Kubernetes versions as Amazon EKS clusters with other node compute types, including standard and extended Kubernetes version support. Hybrid nodes are not automatically upgraded when you upgrade your control plane version and you are responsible for upgrading your hybrid nodes. For more information, see Upgrade hybrid nodes for your cluster.
Standard support for a Kubernetes version in Amazon EKS begins when a Kubernetes version is released on Amazon EKS, and will end 14 months after the release date. Extended support for a Kubernetes version will begin immediately after the end of standard support, and will end after the next 12 months. For example, standard support for version 1.23 in Amazon EKS ended on October 11, 2023. Extended support for version 1.23 began on October 12, 2023 and ended on October 11, 2024.
You will need to enable extended support (see EKS extended support) for your cluster by changing the cluster upgrade policy to EXTENDED. By default, for all new and existing clusters, the upgrade policy is set to EXTENDED, unless specified otherwise. See Cluster upgrade policy to view the upgrade policy for your cluster. Standard support will begin when a Kubernetes version is released on Amazon EKS, and will end 14 months after the release date. Extended support for a Kubernetes version will begin immediately after the end of standard support, and will end after the next 12 months.
You can run clusters on any version for up to 12 months after the end of standard support for that version. This means that each version will be supported for 26 months in Amazon EKS (14 months of standard support plus 12 months of extended support).
If you donât want to be automatically enrolled in extended support, you can upgrade your cluster to a Kubernetes version thatâs in standard Amazon EKS support. To disable extended support, see Disable EKS extended support. Note: If you disable extended support, your cluster will be auto upgraded at the end of standard support.
Clusters running on a Kubernetes version that has completed its 26-month lifecycle (14 months of standard support plus 12 months of extended support) will be auto-upgraded to the next version. The auto-upgrade includes only the Kubernetes control plane. If you have EKS Auto Mode nodes, they may automatically update. Self managed nodes and EKS Managed Node Groups will remain on the previous version.
On the end of extended support date, you can no longer create new Amazon EKS clusters with the unsupported version. Existing control planes are automatically updated by Amazon EKS to the earliest supported version through a gradual deployment process after the end of support date. After the automatic control plane update, make sure to manually update cluster add-ons and Amazon EC2 nodes. For more information, see Update existing cluster to new Kubernetes version.
Amazon EKS canât provide specific time frames. Automatic updates can happen at any time after the end of extended support date. You wonât receive any notification before the update. We recommend that you proactively update your control plane without relying on the Amazon EKS automatic update process. For more information, see Update existing cluster to new Kubernetes version.
No. Cloud security at AWS is the highest priority. Past a certain point (usually one year), the Kubernetes community stops releasing common vulnerabilities and exposures (CVE) patches and discourages CVE submission for unsupported versions. This means that vulnerabilities specific to an older version of Kubernetes might not even be reported. This leaves clusters exposed with no notice and no remediation options in the event of a vulnerability. Given this, Amazon EKS doesnât allow control planes to stay on a version that reached end of extended support.
Yes, there is additional cost for Amazon EKS clusters running in extended support. For pricing details, see Amazon EKS extended support for Kubernetes version pricing on the AWS blog or our pricing page.
Amazon EKS clusters in Extended Support receive ongoing security patches for the Kubernetes control plane. Additionally, Amazon EKS will release patches for the Amazon VPC CNI, kube-proxy, and CoreDNS add-ons for Extended Support versions. Amazon EKS will also release patches for AWS-published Amazon EKS optimized AMIs for Amazon Linux, Bottlerocket, and Windows, as well as Amazon EKS Fargate nodes for those versions. All clusters in Extended Support will continue to get access to technical support from AWS.
While Extended Support covers all of the Kubernetes specific components from AWS, it will only provide support for AWS-published Amazon EKS optimized AMIs for Amazon Linux, Bottlerocket, and Windows at all times. This means, you will potentially have newer components (such as OS or kernel) on your Amazon EKS optimized AMI while using Extended Support. For example, once Amazon Linux 2 reaches the end of its lifecycle in 2025, the Amazon EKS optimized Amazon Linux AMIs will be built using a newer Amazon Linux OS. Amazon EKS will announce and document important support lifecycle discrepancies such as this for each Kubernetes version.
Yes.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4