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.
Rotation on a self-managed cluster
To measure what AWS adds, look at how rotation works on self-managed Kubernetes. In a kubeadm cluster, the control plane CA lives in files under /etc/kubernetes/pki. Rotating it means generating a new CA, signing fresh certificates for the API server, controllers, and kubelets, then restarting components in the right order. One sequencing error, and the cluster ends up inconsistent — the API server rejects kubelets, controllers lose their grip, and the diagnosis starts from a pile of certificates that no longer match.
cert-manager automates application TLS certificate rotation, but the cluster’s own root CA remains a manual asset in most deployments. Many teams discover it the day it expires, precisely because its ten-year lifespan outlasts the tenure of whoever installed it: the original cluster often outlives its creator.
That is the gap the EKS announcement fills for the managed service. The difference is less about technique than responsibility: AWS takes on the schedule tracking, notifications, and activation, while the operator keeps what is inherently theirs — their nodes and their external clients.
What actually breaks during a rotation
Understanding rotation means understanding what happens when it half-fails. A kubectl that does not trust the new CA sees its calls rejected with a TLS error; a node that was never replaced keeps presenting a certificate signed by the old root; an operator or webhook that validates the API server against a pinned CA fails silently.
The critical window is coexistence: the old and new CAs must both be accepted while clients cut over one by one. That is exactly what EKS’s managed lifecycle orchestrates — and what a manual rotation often gets wrong, by activating the new root before every client knows it. The simple rule: trust precedes the cutover, never the reverse.
Who this actually affects
The announcement matters most to teams running clusters that predate modern EKS defaults. A cluster launched in 2018 or 2019 has a CA nearing the end of its ten-year validity, and its operators have likely rotated through several generations of engineers since — the original author is often gone. Those are the clusters most at risk, and the ones the managed lifecycle is built to rescue: AWS will notify, append a successor, and activate if no one else does.
The second group is anyone with external clients hardwired to the cluster: self-hosted runners, GitLab or Jenkins agents, Terraform state backends, or monitoring probes. None of them are visible to AWS, and none of them will update themselves. The cost of forgetting one is a hard cut at activation time — the exact failure the rollback exists to catch.
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.