Amazon EKS has recently introduced support for Kubernetes version rollbacks, letting practitioners revert a cluster's control plane to its previous Kubernetes version within 7 days of an upgrade if issues arise. The feature reduces the risk of in-place cluster upgrades by giving teams a safety net to recover quickly from problematic updates.

EKS reverts the Kubernetes API server and control plane components while preserving all etcd data, workloads, and persistent volumes. According to the documentation, for clusters running EKS Auto Mode, EKS automatically rolls back Auto Mode worker nodes before reverting the control plane, with options to speed up or cancel the process.

Explaining why "upgrading a Kubernetes control plane has long been a one-way door," Micah Walter, senior solutions architect at AWS, writes:

With Kubernetes releasing three minor versions per year, teams managing hundreds of clusters, especially in regulated environments, often delay upgrades entirely because they aren’t confident they can recover if something goes wrong. The result is clusters stuck on older versions, missing security patches, and eventually running up against extended support timelines.

Unlike Amazon ECS, AWS's proprietary container orchestrator, EKS is a managed AWS service that runs and maintains the Kubernetes control plane, allowing developers to deploy and operate containerized applications.

Rollbacks work one minor version at a time, mirroring EKS's incremental upgrade path. EKS runs cluster insights to check rollback readiness, surfacing issues like node version mismatches or add-on dependencies before you proceed. Use--force to skip these checks.

Open source Kubernetes lacked a control plane rollback, with KEP-4330 adding emulated versions to enable rollbacks, but this limitation has led organizations to adopt workarounds such as bake periods, staggered groups, automated sign-offs, and lengthy upgrade cycles. The rollback capability on EKS has been a long-standing request from the AWS community, with developers previously discussing various workarounds. Ismail Baig, senior cloud & DevOps leader at Uniphore, comments:

AWS just gave EKS teams something we've been asking for years: native Kubernetes rollback (...) Before this, teams had two workarounds, both expensive: Blue/green cluster deployments that doubled infra cost during upgrades. Manual snapshots that ate engineering hours and still weren't guaranteed to work cleanly.

AWS is not the first cloud provider to add rollback features to managed Kubernetes clusters: while Azure AKS offers only partial support, limited to node pool rollbacks, GKE introduced control plane minor-version rollbacks with GKE 1.33, built on an upstream Kubernetes capability that Google developed with the community. Walter adds:

To give you control over this process, we’ve introduced a cancel API that lets you stop a node rollback at any point. If you decide the rollback is taking too long or you want to change your approach, you can cancel and adjust your disruption budgets to accelerate things, or choose a different path forward.

Corey Quinn, chief cloud economist at The Duckbill Group, writes in his newsletter:

An undo button for Kubernetes upgrades, arriving only after years of ops teams building bake periods and month-long ceremonies to avoid the one-way door.

Ashref Gamoudi, DevOps engineer at Tnker, adds on LinkedIn:

AWS just solved one of the biggest fears of every Kubernetes engineer.

Kubernetes version rollbacks are available now at no additional cost in all regions where EKS is available. Control plane rollbacks apply to all EKS clusters, whereas node rollbacks are limited to clusters running EKS Auto Mode. Rollbacks are supported for Kubernetes versions in both EKS standard and extended support.