Skip to content

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:

  1. Create a new managed node group and select AL2023 as the AMI type.
  2. Validate the new node group with your applications.
  3. Migrate your workloads (pods) from the old node group to the new one.
  4. 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:

  1. Build or obtain a custom AMI based on AL2023.
  2. Create a new managed node group using this custom AL2023 AMI.
  3. Validate the new node group by running test workloads.
  4. Migrate your workloads (pods) from the old node group to the new one.
  5. 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 name gp2.

  • 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 to true when installing aws-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.