On this page · 12 sections
- What actually shipped
- The timetable AWS runs whether or not you do
- The failure mode is on your side of the line
- The 16 KB cliff nobody will see coming
- Two contradictions worth reading carefully
- Rollback, and the point where it stops existing
- How to tell if this is you
- India-specific considerations
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. Amazon EKS announced certificate authority rotation on 20 August 2026. Every EKS cluster created since the 2018 launch has its own CA with a 10-year validity period, which puts the first cohort inside the rotation window now. AWS appends a successor CA roughly 2 years before expiry, activates it roughly 6 months before expiry if you have not, and performs a final activation 45 days out with no rollback. AWS charges $0 for the feature, and the 2018 cohort expires in 2028. The expensive part is on your side: every managed node group, Karpenter node, self-managed node, hybrid node, kubeconfig and CI/CD runner that trusts only the outgoing CA loses the API server the moment the successor is activated. Successor CAs carry a 5-year validity, not 10, so this becomes a recurring platform chore rather than a one-off.
What actually shipped
Five new actions landed in the Amazon EKS API reference: CreateCertificateAuthority, ActivateCertificateAuthority, DescribeCertificateAuthority, ListCertificateAuthorities and DeleteCertificateAuthority. The cluster's Certificate object gained an active member pointing at whichever CA is currently signing. All five actions were live in the reference on 22 August 2026.
A cluster can hold at most two CAs at once. `CreateCertificateAuthority` appends a successor with signingStatus of NOT_USED, which adds its public certificate to the trust bundle without signing anything. AWS then pushes that CA out to the control plane, EKS Auto Mode instances and Fargate nodes, tracked through distributionStatus (IN_PROGRESS, COMPLETE, FAILED, DELETING). You cannot activate a successor until distribution reads COMPLETE.
`ActivateCertificateAuthority` promotes the successor to IN_USE and retires the outgoing CA to NOT_USED. The outgoing CA stays in the trust bundle. Both operations are asynchronous and return an update object you track with DescribeUpdate.
No new IAM permissions are required. The EKS user guide states plainly that if you can call EKS APIs for your cluster today, you can perform CA rotation. AWS CLI 2.x or later is needed, and the feature is in every commercial Region where EKS runs. There is no charge: AWS prices CA rotation at $0 in every Region, as of 22 August 2026.
The timetable AWS runs whether or not you do
This is the part worth putting in a calendar. The notification and automation milestones in the EKS user guide on CA rotation are computed backwards from your CA's expiry date.
| Milestone | When it fires | What AWS does |
|---|---|---|
| CA expiry reminder | 2.5 years before expiry | Notifies you to plan rotation |
| Successor CA appended | 2 years before expiry | Auto-appends a successor and begins distribution |
| Activation warning | 60 days before auto-activation | Warns that activation is imminent |
| First auto-activation | 6 months before expiry | Activates the successor; rollback still available |
| Final auto-activation | 45 days before expiry | Activates again if you rolled back; no rollback |
The scheduledEvents object on a successor CA exposes firstAutoActivation and finalAutoActivation as Unix timestamps, so a fleet script can read the real dates rather than infer them. The outgoing CA does not carry scheduledEvents; only the successor does.
Two safeguards remove options you might have expected to keep. An AWS-appended successor CA cannot be deleted while it is the only successor on the cluster. And a successor you appended yourself becomes undeletable once the cluster passes the two-year-before-expiry mark. Past that point the rotation path is fixed.
The failure mode is on your side of the line
AWS is explicit that this is a shared responsibility, and the split is unusually sharp. AWS updates the control plane, EKS Auto Mode instances, Fargate pods and EKS Capabilities (ACK, Argo CD and kro). You update everything else, and AWS gives a candid reason why: "There is no protocol-level mechanism for the API server to query whether a client has updated its trust bundle."
The user guide states the consequence without softening it: "Nodes not updated before the successor CA is activated will lose connectivity to the EKS cluster's API server until they are replaced or CA rollback is performed."
Four node types need different work:
| Node type | Action required | Failure if skipped |
|---|---|---|
| EKS Auto Mode / Fargate | None, AWS updates them | None |
| Managed node group | update-nodegroup-version rolling replacement |
Nodes lose API server after activation |
| Karpenter with drift detection | None if the disruption budget allows a full cycle in time | Nodes not replaced inside the budget window are stranded |
| Self-managed / hybrid | Update launch template user data or on-node trust store, then replace | Nodes lose API server; new nodes fail to join |
The Karpenter case has a trap that a running platform team will recognise. Drift detection cycles nodes so they pick up the successor CA, but a restrictive disruption budget, such as a narrow maintenance window or a low replacement percentage, can mean not all nodes are replaced before the activation date. Drift being enabled is not the same as drift completing in time.
Custom AMIs are worse. AWS does not merge user data for node groups deployed with a custom AMI, so the CA trust bundle in your launch template is yours to update. A node without the successor CA fails to join the cluster outright.
The 16 KB cliff nobody will see coming
During the dual trust period the cluster's trust bundle holds two base64-encoded CAs, about 2.8 KB combined, or roughly 1.9 KB gzipped. EC2 user data is capped at 16 KB in raw form before base64 encoding.
If your launch template user data already sits near that ceiling, adding the second CA can push it over, and the guide is specific about the result: launch template creation fails and new nodes cannot be provisioned. That is a scale-out outage triggered by a security operation, discovered at the worst moment. Check the size of your decoded user data before you append a successor, not after.
Gzip is the documented workaround. It is also the reason to audit user data now while the change is cheap.
Two contradictions worth reading carefully
AWS answers "Does CA rotation cause downtime for my cluster?" with "No", and for the control plane that is accurate, since it stays available at every stage. The same document also says unready worker nodes "will lose connectivity to the control plane after the successor CA is activated". Both statements are true of different things. Anyone reading only the FAQ headline will plan the wrong change window. The control plane does not go down; your data plane can.
The second one is easier to miss. Under "Do I need to restart my pods?" the answer opens with pods being unaffected, then adds that in-cluster controllers and operators using client-go "might need to be restarted after activation of the successor CA, as client-go does not dynamically re-read the CA trust bundle". Admission webhooks, operators and controllers that talk to the API server are exactly the workloads whose failure looks like a cluster problem rather than a certificate problem. Plan a restart of that set immediately after activation.
The guide also warns against CA pinning: clients should trust a bundle, not a single certificate. Any client-side TLS configuration that pins one CA breaks when the bundle changes.
Rollback, and the point where it stops existing
Rollback re-activates the previous CA by calling activate-certificate-authority against the older CA ID. Both CAs stay in the trust bundle, so clients already updated keep working and clients that were missed resume immediately. Kubelet reconnects through its own retry loop.
Check availability with the rollbackAvailable boolean from describe-certificate-authority. It is available after a customer-initiated activation or after the first AWS auto-activation, until the rollback window closes. It is not available after final auto-activation at 45 days before expiry, which only happens if you rolled back the first one. At that point the rotation goes forward regardless.
One more scheduling constraint: cluster version upgrades and CA rotation cannot run at the same time. A version upgrade is rejected while a CA operation is in progress, and vice versa. Teams that batch a Kubernetes upgrade and a CA rotation into one maintenance window will have to sequence them. If you are already planning around EKS 1.33 standard support ending, add the CA operation as a separate window rather than a parallel task.
How to tell if this is you
Run this per cluster and read the expiry date rather than guessing from the cluster's creation year:
aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2 \
--query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
--output table
Then the discovery work that actually takes the time. AWS names the client categories: developer workstations, CI/CD pipelines (Jenkins, GitHub Actions, GitLab, Argo CD), monitoring and observability tools, automation scripts, and anything holding a stored kubeconfig. In a multi-team cluster this list is longer than the platform team's inventory of it, and there is no server-side way to verify readiness. The real cost here is discovery across teams, not the API call.
Updating a local kubeconfig is one command, because aws eks update-kubeconfig pulls the combined bundle. Updating a kubeconfig that a pipeline stores as a secret means finding every one of those secrets. That is the work.
Teams standardising this across a fleet usually fold it into the same controls they already use for Kubernetes 1.36 upgrade breaking changes and node-image currency, because the mechanism is the same, namely replacing nodes on a schedule you control, before a deadline someone else sets.
India-specific considerations
Indian enterprises running EKS in ap-south-1 and ap-south-2 face the same timetable, and the compliance angle is the kubeconfig sprawl rather than the certificate itself. Under the Digital Personal Data Protection Act 2023, a stored kubeconfig with cluster credentials sitting in an unmanaged CI runner is an access-control finding regardless of the CA behind it. The discovery pass this rotation forces is a reasonable moment to inventory and centralise those credentials.
Budget realistically. A fleet of 20 to 40 clusters with mixed node types is typically ₹8,00,000 to ₹20,00,000 of platform-engineering effort at prevailing Indian senior-SRE rates, most of it in client discovery and node-group replacement scheduling rather than in the rotation calls themselves. The AWS charge for the feature is $0.
What is still unknown
AWS does not publish the length of the rollback window in days — the documentation says only "a limited period", and points you at the rollbackAvailable field. Clusters created in 2018-2019 are on "an adjusted schedule" whose milestones are not published either, because the standard 2.5-year and 2-year notifications for that cohort fall before the feature existed. If you run a 2018-era cluster, your first AWS Health notification carries your real dates, and that notification is the only place they appear.
Bring Your Own CA, backing an EKS cluster with AWS Private CA, is still unsupported. Certificate revocation is not supported either, which matches upstream Kubernetes, because there is no CRL or OCSP, so replacing the CA is the only revocation primitive available.
FAQ
How eCorpIT can help
Our senior engineering teams run this as a fleet exercise rather than a per-cluster one: inventory every CA expiry date and scheduledEvents timestamp across accounts and Regions, audit launch-template user data against the 16 KB limit before the second CA lands, map stored kubeconfigs across CI/CD and observability tooling, then sequence node replacement so activation is a non-event. That work sits inside our managed Kubernetes and AI platform service. eCorpIT is CMMI Level 5, MSME Certified and ISO 27001:2022 certified. Tell us your cluster count and node-type mix on our contact page and we will size the rotation window.
References
- Amazon EKS now supports certificate authority (CA) rotation with automated lifecycle management — AWS What's New, 20 August 2026
- Rotate the EKS cluster certificate authority (CA) — Amazon EKS User Guide
- CreateCertificateAuthority — Amazon EKS API Reference
- ActivateCertificateAuthority — Amazon EKS API Reference
- DeleteCertificateAuthority — Amazon EKS API Reference
- CertificateAuthority data type — Amazon EKS API Reference
- CertificateAuthorityScheduledEvents data type — Amazon EKS API Reference
- CertificateAuthorityValidity data type — Amazon EKS API Reference
- Amazon EKS API Reference: Actions index — Amazon EKS API Reference
- Certificate data type — Amazon EKS API Reference
- Run commands when you launch an EC2 instance with user data — Amazon EC2 User Guide
- Karpenter disruption: drift, consolidation and budgets — Karpenter documentation
- Secure workloads with Kubernetes certificates — Amazon EKS User Guide
Last updated: 22 August 2026.
