AWS automates EKS certificate authority rotation, ahead of 2018 clusters hitting their 10-year expiry
On August 20, 2026, Amazon EKS announced certificate authority rotation with a managed lifecycle and automated safeguards for every cluster. Clusters created since 2018 are approaching the ten-year validity limit of their CA: rotation is a shared responsibility, and the worker-node and external-client side remains the operator’s job.
August 20, 2026. Amazon EKS announces certificate authority (CA) rotation for every cluster, delivered through a managed lifecycle with automated safeguards. Since 2018. Each EKS cluster has its own CA that encrypts connections to the cluster’s Kubernetes API, with a ten-year validity period. Now. Clusters from that era are reaching the point where rotation must begin.
For a team operating EKS, this is a reminder that certificates expire even when you never see them — and that AWS just turned a piece of operational debt into a feature.
A ten-year countdown
The mechanics are simple to understand and easy to forget. Every Amazon EKS cluster has its own certificate authority, used to establish encrypted, authenticated connections to the cluster’s API server. AWS issues these CAs with a ten-year validity.
Clusters created since the service launched in 2018 are therefore approaching the expiry of their root certificate. This is not a bug: it is the arithmetic of the lifespan chosen at the start. But for teams that never had to think about it, the first rotation of a cluster CA is a delicate exercise — a wrong move can sever the connection of every component to the control plane.
AWS is now formalizing the process as a managed one. Rotation follows a lifecycle: the API and AWS-managed components are updated to trust the successor CA, and the operator no longer has to orchestrate the cutover by hand.
A shared responsibility, stated plainly
The core of the announcement is the split of roles. AWS manages the rotation lifecycle and automatically updates the components it administers. But rotating a cluster CA is a shared responsibility: the customer remains responsible for two things.
First, replacing worker nodes. EKS Auto Mode instances and Fargate nodes are updated automatically by AWS, but customer-managed node groups must be replaced to pick up the new CA.
Second, updating external clients. Anything that connects to the API server from outside the cluster — deployment tooling, CI/CD pipelines, developers’ kubectl, operators, controllers — must learn to trust the successor CA before it is activated. A client that does not recognize the new root gets rejected at cutover time.
AWS’s phrasing is careful: activation of the successor CA must precede the client updates, or access breaks.
The automated safeguards
This is where the offering earns its keep. Amazon EKS provides automated safeguards throughout the process: advance notifications before CA expiry, automatic appending of a successor CA if the customer does not create one, and automatic activation if the customer does not activate on their own schedule.
The most useful piece is the rollback capability. If the cutover to the successor CA reveals a problem — a forgotten client, an unreplaced node — the operator can revert to the previous CA to resolve the incident before retrying. That is the safety net every manual rotation lacked: the ability to back out without rebuilding the cluster.
The feature is available at no additional cost in all commercial AWS Regions, through the CLI, EKS APIs, CloudFormation, and the console.
Verdict
If you operate EKS clusters created between 2018 and 2020, check your CA’s validity date this week — the ten-year window is expiring, and an unhandled expiry cuts off API server access with no notice. The earlier you plan the rotation, the more you can do it at your own pace rather than in an emergency.
If you use EKS Auto Mode or Fargate, the AWS-managed side updates itself, but your external clients — pipelines, kubectl, operators — remain your responsibility. Inventory them before activating the successor CA, and keep rollback close for the cutover.
If you manage other certificate authorities — internal PKI, Vault, cert-manager — the lesson transfers: a ten-year CA is an asset you forget precisely because it lasts so long. Automate rotation before it becomes an incident.