Supported Environments
Please review the information listed below to understand the supported versions.
Kubernetes VersionsΒΆ
The following versions of Kubernetes are currently supported. New EKS clusters can be provisioned using the following Kubernetes versions. Existing EKS clusters managed by the controller can be upgraded in-place to the following Kubernetes versions.
Important
Customers are strongly recommended to upgrade their EKS clusters to a recent supported version to ensure they continue to receive patches and security updates.
Kubernetes Version | End of Standard Support | Extended Support | 'New Cluster Provisioning' & 'Convert to Managed' support added with Controller release version | 'In-place upgrade' support added with Controller release version |
---|---|---|---|---|
v1.33.x | 29 July 2026 | 29 July 2027 | v3.7 | v3.7 |
v1.32.x | 23 Mar 2026 | 23 Mar 2027 | v3.2 | v3.2 |
v1.31.x | 26 Nov 2025 | 26 Nov 2026 | v2.10 Update 1 | v2.10 Update 1 |
v1.30.x | 23 July 2025 | 23 July 2026 | v2.7 | v2.7 |
v1.29.x | 23 Mar 2025 | 23 Mar 2026 | v2.4 | v2.4 |
v1.28.x | 26 Nov 2024 | 26 Nov 2025 | v2.1 | v2.1 Update 1 |
v1.27.x | 24 Jul 2024 | 24 Jul 2025 | v1.27 Update 1 | v2.0 |
v1.26.x | 11 Jun 2024 | 11 Jun 2025 | v1.25 Update 1 | v1.27 |
v1.25.x | 01 May 2024 | 01 May 2025 | v1.25 | v1.25 |
v1.24.x | 31 Jan 2024 | 31 Jan 2025 | v1.22 | v1.22 |
v1.23.x | 11 Oct 2023 | 11 Oct 2024 | v1.21 | v1.21 |
π¨ Important
Migrating to Amazon Linux 2023 (AL2023) for EKS 1.33
With EKS 1.33, Amazon Linux 2 (AL2) is no longer supported. If you are currently using AL2, you must migrate your worker nodes to Amazon Linux 2023 (AL2023).
From
EKS 1.33
onwards, newly created node groups will default to Node AMI family = AL2023.There are two possible scenarios depending on how your node groups are configured.
Scenario 1: Using Managed Node Groups with Node AMI Family = AmazonLinux2
If you are using the default AmazonLinux2 AMI family:
- Create a new managed node group and select AL2023 as the AMI type.
- Validate the new node group with your applications.
- Migrate your workloads (pods) from the old node group to the new one.
- Delete the old node group after confirming stability.
Scenario 2: Using a Custom AMI with Managed Node Groups
If you are using a custom AMI based on AL2:
- Build or obtain a custom AMI based on AL2023.
- Create a new managed node group using this custom AL2023 AMI.
- Validate the new node group by running test workloads.
- Migrate your workloads (pods) from the old node group to the new one.
- Delete the old node group after confirming stability.
- From Kubernetes version 1.30 and later, Amazon EKS no longer applies the default annotation to the
gp2
StorageClass resource for newly created clusters. This adjustment does not affect users who reference this storage class by its name. However, if you were depending on having a default StorageClass in your cluster, you will need to take action. It is recommended that you reference the StorageClass explicitly by the namegp2
.
- For new cluster creation from version 1.30 onward, you can deploy Amazon EBS with default storage class settings. Specifically, you can enable the
defaultStorageClass.enabled
parameter by setting it totrue
when installingaws-ebs-csi-driver
add-on. This will create a StorageClass with the default annotation. With this configuration, if your application deployment code utilizes the default annotation, it will continue to function without requiring modifications to your application deployment automation. You can include this configuration in the Amazon EBS CSI managed add-on section of your cluster configuration.--- addons: - name: coredns version: v1.11.1-eksbuild.8 - name: vpc-cni version: v1.18.1-eksbuild.3 - name: kube-proxy version: v1.30.0-eksbuild.3 - name: aws-ebs-csi-driver version: v1.35.0-eksbuild.1 configurationValues: |- { "defaultStorageClass": { "enabled": true } }
For more information about these changes, please refer to the AWS documentation for Kubernetes 1.30.