Amazon EKS adds Kubernetes rollback option for clusters

Amazon Web Services has introduced Kubernetes version rollbacks for Amazon EKS, allowing administrators to reverse a cluster upgrade within seven days.

The feature addresses a long-standing limitation in Kubernetes control plane upgrades, which have generally been irreversible once completed. Organisations often responded by building lengthy approval processes and delaying upgrades, particularly when managing large numbers of clusters or operating in regulated environments.

Under the new arrangement, Amazon EKS users can roll back one minor Kubernetes version at a time. A cluster upgraded from Kubernetes 1.34 to 1.35, for example, can be returned to 1.34 during the seven-day rollback window.

The rollback restores a cluster to its previous validated production version rather than leaving it in a transitional state. It is also intended to reduce the need to rebuild clusters when an upgrade creates compatibility problems.

How it works

Before a rollback begins, Amazon EKS checks whether the cluster is ready through its cluster insights system. These checks can highlight issues such as node version compatibility and add-on dependencies that may affect the rollback.

Administrators can bypass the checks with a force option if they choose to proceed without waiting for the assessment. The feature applies across EKS clusters, whether customers manage their own nodes or use AWS-managed infrastructure.

A separate layer of rollback support is available for EKS Auto Mode, AWS's managed setup for Kubernetes infrastructure. In that configuration, both the control plane and managed nodes are rolled back together, adding operational complexity compared with control plane-only changes.

Node rollbacks in EKS Auto Mode follow pod disruption budgets, so the pace depends on how customers have configured workload disruption limits. AWS has also added a cancel API, allowing administrators to stop a node rollback part way through if they want to change course.

By default, the service does not override disruption budgets during rollback. Users who want the process to move faster must change or remove those settings themselves.

Upgrade pressure

Kubernetes issues three minor releases a year, creating a demanding maintenance cycle for companies running many clusters. Without a straightforward way to reverse an unsuccessful upgrade, some teams postpone version changes and remain on older releases longer than intended.

That can leave systems without the latest security patches and bring them closer to support deadlines. AWS positioned the rollback option as a way to give operations teams more flexibility when an upgrade produces unexpected behaviour.

The wider Kubernetes community has been working on rollback-related improvements through KEP-4330, which introduces emulated versions to make reversions easier. AWS said its approach differs because it restores the previous version that had already been running in production.

Availability

The rollback feature is available in all commercial AWS regions where Amazon EKS operates, at no additional charge beyond normal EKS and compute fees.

Control plane rollbacks are available for all EKS clusters. Node rollbacks are limited to clusters using EKS Auto Mode.

The feature supports clusters running Kubernetes versions covered by EKS standard and extended support. A control plane rollback takes about 20 minutes, similar to the time required for a standard upgrade.

In a demonstration described by AWS, the cluster remained functional while the rollback was under way, and an Auto Mode cluster's nodes reverted in line with its disruption budget settings. Once complete, the cluster returned to its earlier Kubernetes version.