EKS CA Rotation: How to Rotate Your Cluster Certificate Authority Without Breaking Access

On 28 October 2026, AWS added certificate authority (CA) rotation visibility to the Amazon EKS Dashboard. You can now see the CA rotation status of every cluster across your accounts and Regions in one place. It points to a real deadline. AWS says EKS clusters created since 2018 have CAs with a 10-year validity period, and those CAs are now approaching the point where rotation should begin.

If you run Amazon EKS, EKS CA rotation will reach your clusters sooner or later. The cluster itself will stay up, but your CI/CD pipelines, laptops and self-managed nodes can lose access if you skip your part. Here is how it works and how to roll it out without surprises.

What Is EKS CA Rotation?

Every EKS cluster gets its own certificate authority when it is created. According to the Amazon EKS documentation, this CA signs the certificates for the Kubernetes API server. That is what lets control plane components, worker nodes and clients authenticate to the API server and connect over TLS. When a CA expires, the certificates it signed can no longer be validated, and anything that depends on them can no longer connect.

AWS launched managed CA rotation on 20 August 2026. It is available at no additional cost in all commercial AWS Regions, through the AWS CLI, EKS APIs, CloudFormation and the console. The original CA created with your cluster is valid for 10 years. Successor CAs created through rotation are valid for 5 years, so rotation becomes a recurring task.

How the Rotation Works

EKS CA rotation runs in three stages:

1. Append a successor CA. A new CA is added to the cluster. From then on, the cluster trusts both the outgoing and the successor CA, but certificates are still signed by the outgoing one. Nothing breaks.
2. Distribute. AWS updates the components it manages (the control plane, EKS Auto Mode nodes and AWS Fargate) to trust both CAs. You can track this through the CA’s distributionStatus. The successor CA cannot be activated until distribution is complete.
3. Activate. The cluster starts signing certificates with the successor CA. Any client that does not yet trust it will fail TLS verification and cannot connect.

The time between appending the successor and retiring the old CA is called the dual trust period. It lets you update nodes and clients gradually.

The automatic timeline

If you do nothing, AWS will still move the cluster forward. The documentation lists these milestones, counted back from the outgoing CA’s expiry date:

• 2.5 years before expiry: a CA expiry reminder.
• 2 years before: AWS appends a successor CA automatically if you have not already done it.
• 60 days before auto-activation: an activation warning.
• 6 months before expiry: AWS activates the successor CA automatically.
• 45 days before expiry: a final auto-activation, which only happens if you rolled back after the first one. No rollback is possible after this.

Notifications arrive through AWS Health, Cluster Insights and email. Clusters created in 2018-2019 get an adjusted notification schedule, and the first notice includes dates specific to that cluster.

Who Does What: The Shared Responsibility Split

AWS handles the control plane, EKS Auto Mode nodes, Fargate pods and EKS Capabilities (ACK, Argo CD and kro). You handle everything AWS cannot reach:

• External clients: developer kubeconfig files, CI/CD pipelines (Jenkins, GitHub Actions, GitLab), GitOps controllers running outside the cluster, monitoring agents and scripts that store certificate-authority-data.
• Worker nodes you manage: managed node groups, Karpenter-controlled nodes, self-managed nodes and hybrid nodes.

Even if your data plane runs entirely on EKS Auto Mode or Fargate, your external clients are still your job. As the AWS Containers blog deep dive notes, AWS cannot reach into those systems.

Step-by-Step: Rotating a Cluster CA Safely

1. Check your current CA and expiry

aws eks list-certificate-authorities --cluster-name my-cluster --region ap-south-1
aws eks describe-certificate-authority --cluster-name my-cluster \
  --certificate-authority-id <ca-id> --region ap-south-1

The validity.notAfter field shows when the CA expires. For a whole fleet, open the EKS Dashboard instead. It is viewed from us-east-1, needs trusted access enabled in your AWS Organizations management account, and costs nothing extra.

2. Append a successor CA on your own timeline

aws eks create-certificate-authority --cluster-name my-cluster --region ap-south-1

Starting early gives you the most time to find every client. Wait until the successor CA shows distributionStatus: COMPLETE before you move on.

3. Update external clients

On workstations, re-run aws eks update-kubeconfig --name my-cluster. It pulls the combined trust bundle that contains both CAs. For pipelines, Argo CD cluster secrets and monitoring tools, replace the stored CA data with the output of:

aws eks describe-cluster --name my-cluster \
  --query 'cluster.certificateAuthority.data' --output text

Watch for tools that pin a single CA certificate. AWS recommends trusting a CA bundle instead, because pinning will break when the bundle changes.

4. Refresh your worker nodes

• Managed node groups: run aws eks update-nodegroup-version to roll the nodes. New nodes bootstrap with the updated CA data. If you use a custom AMI, update the CA data in your launch template user data first, because AWS does not merge user data in that case.
• Karpenter: drift detection will cycle the nodes, but check your disruption budget. In the AWS example, a 10% weekly budget across 50 nodes takes about 10 weeks to replace every node.
• Self-managed nodes: update the launch template with the new CA data and run an instance refresh on the Auto Scaling group.

One limit to check: during dual trust the bundle is about 2.8 KB (about 1.9 KB gzipped). If your custom user data is already close to the EC2 16 KB limit, new nodes may fail to launch. Set Pod Disruption Budgets for critical workloads before you roll nodes.

5. Activate, verify, and roll back if needed

aws eks activate-certificate-authority --cluster-name my-cluster \
  --certificate-authority-id <successor-ca-id> --region ap-south-1
kubectl get nodes

If a forgotten pipeline or tool breaks, re-activate the previous CA’s ID to roll back while the rollback window is open. Check rollbackAvailable first. Also restart in-cluster controllers that use client-go, because client-go does not re-read the trust bundle on its own.

Limits worth knowing

• A cluster can have at most two CAs at a time.
• You cannot run a Kubernetes version upgrade and a CA rotation at the same time.
• Bring Your Own CA through AWS Private CA is not supported.
• Rotation APIs live outside the cluster resource, so Terraform and CloudFormation stacks do not show drift.

If kubeconfigs are scattered across Jenkins servers and laptops, our cloud DevOps services team can help you find and update every client. If you want to cut down how many nodes you manage at all, see our guide on EKS Auto Mode and the Gateway API.

Frequently Asked Questions

Does EKS CA rotation cause downtime?

The control plane stays available throughout, and pod-to-pod traffic does not use the cluster CA. The risk is to nodes and clients you have not updated. They lose access to the API server once the successor CA is activated.

Is there any cost?

No. CA rotation and the EKS Dashboard view are both available at no additional cost.

What if my cluster runs on EKS Auto Mode or Fargate?

AWS updates those nodes automatically. You still need to update external clients such as kubeconfig files, CI/CD pipelines and outside GitOps tools.

Can I rotate the CA before AWS starts it?

Yes. You can run create-certificate-authority at any time while the cluster is active.

Plan Your Rotation Before AWS Does It for You

Shanav Technologies helps startups and growing businesses run Amazon EKS reliably, from cluster audits to zero-surprise upgrades. If you are not sure which pipelines, tools and nodes depend on your cluster CA, talk to our team and we will help you map out an EKS CA rotation plan.