EKS CA-Rotation 2026: Was Cluster-Teams jetzt tun müssen
Die Cluster-CA von EKS ist 10 Jahre gültig, erste laufen 2028 ab. AWS rotiert automatisch, Kubeconfigs und eigene Nodes müssen Sie selbst umstellen.
TL;DR
Die EKS CA-Rotation betrifft jeden EKS-Cluster: Die Zertifizierungsstelle eines Clusters ist 10 Jahre gültig, Cluster aus 2018 erreichen damit 2028 das Ende. AWS hängt etwa 2 Jahre vor Ablauf eine Nachfolger-CA an und aktiviert sie spätestens 6 Monate vorher. Eigene Nodes, Kubeconfigs und CI/CD-Pipelines müssen Sie selbst umstellen.
Was hat AWS geändert?
AWS hat die Rotation der Cluster-CA als eigene Funktion eingeführt und zeigt ihren Status seit dem 28. Oktober 2026 auch im EKS Dashboard über alle Cluster hinweg. Die Ankündigung nennt keine Zusatzkosten und gilt für alle kommerziellen AWS-Regionen, also auch Frankfurt (eu-central-1).
Hintergrund: Jeder EKS-Cluster hat eine eigene CA, die die Zertifikate des API-Servers signiert. Laut EKS-Dokumentation ist die ursprüngliche CA 10 Jahre gültig, jede Nachfolger-CA nur noch 5 Jahre. Rotiert wird in drei Stufen: Nachfolger-CA anhängen, an AWS-verwaltete Komponenten verteilen, aktivieren. Dazwischen vertraut der Cluster beiden CAs (Dual-Trust-Phase), das Trust-Bundle enthält dann zwei PEM-Blöcke.
AWS hat feste Fristen relativ zum Ablaufdatum der CA festgelegt:
| Zeitpunkt vor Ablauf der CA | Was passiert | Ihre Aufgabe |
|---|---|---|
| 2,5 Jahre | Erinnerung per AWS Health, Cluster Insights, E-Mail | Clients und Nodes inventarisieren |
| etwa 2 Jahre | AWS hängt die Nachfolger-CA automatisch an | Kubeconfigs, Pipelines, Nodes aktualisieren |
| 60 Tage vor Auto-Aktivierung | Aktivierungswarnung | Restliche Clients nachziehen |
| etwa 6 Monate | Erste automatische Aktivierung, Rollback möglich | Verbindungen prüfen |
| 45 Tage | Finale Aktivierung (nur nach Rollback), kein Rollback mehr | keine Ausweichmöglichkeit |
Für Cluster aus 2018 und 2019 gilt ein angepasster Zeitplan, weil die berechneten Termine vor dem Start der Funktion liegen. Die erste Benachrichtigung nennt dann die konkreten Daten.
Was bedeutet das für Teams in Deutschland?
Die Verantwortung ist geteilt, und die Hälfte liegt bei Ihnen. AWS aktualisiert Control Plane, Auto-Mode-Nodes, Fargate und die EKS Capabilities (ACK, Argo CD, kro). Alles andere sieht AWS nicht: Managed Node Groups, Karpenter-, Self-managed- und Hybrid-Nodes sowie externe Clients.
Kritisch sind Systeme außerhalb von AWS: Laptops, GitLab- oder Jenkins-Runner im eigenen Rechenzentrum, Monitoring und Skripte mit fest eingebettetem certificate-authority-data. Nach der Aktivierung scheitert deren TLS-Prüfung, der Cluster selbst bleibt erreichbar. Anwendungen mit CA-Pinning oder strikter Prüfung auf genau eine CA müssen mehrere CAs akzeptieren. Wer Node-User-Data nahe am EC2-Limit von 16 KB hat, beachtet: Zwei CAs belegen rund 2,8 KB, komprimiert rund 1,9 KB.
Zur AWS European Sovereign Cloud macht die Ankündigung keine eigene Aussage, Stand dort: k. A.
Was sollten Sie jetzt tun?
Starten Sie mit der Inventur, nicht mit der Aktivierung. AWS empfiehlt, den Zeitplan selbst zu steuern, statt auf die Auto-Aktivierung zu warten.
- Ablaufdatum prüfen, pro Cluster und Region:
aws eks list-certificate-authorities --cluster-name my-cluster --region eu-central-1
aws eks describe-certificate-authority --cluster-name my-cluster \
--certificate-authority-id <ca-id> --region eu-central-1- Alle Clients mit Zugriff auf den API-Server erfassen: Pipelines, Monitoring, Automatisierung, Entwickler.
- Nachfolger-CA anhängen (
aws eks create-certificate-authority) und warten, bisdistributionStatusaufCOMPLETEsteht. - Kubeconfigs mit
aws eks update-kubeconfigerneuern, Managed Node Groups per Versions-Update rollend ersetzen, bei Karpenter Drift und Disruption Budget prüfen. - Erst dann
aws eks activate-certificate-authorityausführen und die Verbindungen testen. Bei Problemen ist ein Rollback möglich, solangerollbackAvailabletrue ist.
Ein Kubernetes-Upgrade ersetzt diesen Ablauf nicht, plant sich aber gut zusammen, etwa mit dem Wechsel auf EKS 1.37. Grunddaten zu Preis, SLA und Regionen stehen im EKS-Profil, andere Anbieter vergleicht die Vergleichsmatrix.
FAQ
Kostet die EKS CA-Rotation etwas?
Nein. Laut AWS ist die CA-Rotation für alle EKS-Cluster ohne Zusatzkosten verfügbar, auch das Dashboard kostet nichts. Kosten entstehen höchstens indirekt durch das Ersetzen von Nodes.
Fällt mein Cluster während der Rotation aus?
Die Control Plane bleibt nach Angabe von AWS in jeder Phase verfügbar. Ausfallen können nur Clients und Nodes, die die Nachfolger-CA noch nicht kennen, sobald diese aktiviert ist.
Wann läuft die CA meines Clusters ab?
Die ursprüngliche CA gilt 10 Jahre ab Erstellung des Clusters. Das genaue Datum steht im Feld validity.notAfter von describe-certificate-authority.
Muss ich bei EKS Auto Mode oder Fargate etwas tun?
Für die Nodes nicht, AWS aktualisiert sie selbst. Externe Clients wie Kubeconfigs und Pipelines müssen Sie aber auch dann umstellen.
Selbst aktivieren vs Auto-Aktivierung: was ist besser?
Selbst aktivieren passt für Teams, die Clients vollständig kennen, weil Sie den Termin in ein Wartungsfenster legen. Die Auto-Aktivierung etwa 6 Monate vor Ablauf ist nur das Sicherheitsnetz.
Quellen
- AWS What’s New: EKS Dashboard mit CA-Rotationsstatus, 28.10.2026
- Amazon EKS User Guide: Rotate the EKS cluster certificate authority, abgerufen 29.10.2026
- Amazon EC2 User Guide: User data, abgerufen 29.10.2026
Quellen
- AWS What's New: Amazon EKS Dashboard now provides fleet-wide visibility into CA rotation (28.10.2026) (abgerufen 29. Oktober 2026)
- Amazon EKS User Guide: Rotate the EKS cluster certificate authority (CA) (abgerufen 29. Oktober 2026)
- Amazon EC2 User Guide: User data (16 KB Limit) (abgerufen 29. Oktober 2026)