EKS Extended Support: Kosten und Upgrade-Planung

Was EKS Extended Support ist

Jede Kubernetes-Minor-Version (zum Beispiel 1.33) ist in Amazon EKS in den ersten 14 Monaten nach ihrem EKS-Release im Standard Support. Danach folgt für die nächsten 12 Monate der Extended Support. Insgesamt wird eine Version 26 Monate unterstützt.

Mit Extended Support bleiben Sie länger auf einer Kubernetes-Version. Das kostet extra pro Cluster und Stunde.

Im Extended Support veröffentlicht AWS weiter Sicherheits-Patches für die Kubernetes Control Plane. Dazu kommen Patches für die Add-ons Amazon VPC CNI, kube-proxy und CoreDNS sowie für die von AWS bereitgestellten EKS-optimierten AMIs (Amazon Linux, Bottlerocket und Windows) und für EKS-Fargate-Nodes. Der technische Support von AWS bleibt verfügbar.

Extended Support ist kein Weg, Upgrades zu vermeiden. Die AWS-Dokumentation sagt: Planen Sie regelmäßige Upgrades, auch wenn Sie Extended Support nutzen.

Was es kostet

Die EKS-Preisseite nennt zwei Preise pro Cluster und Stunde: $0,10 für eine Version im Standard Support und $0,60 für eine Version im Extended Support. Der Extended-Preis ist der Standardpreis plus $0,50. Prüfen Sie vor der Planung die aktuellen Zahlen auf der Preisseite.

Die Abrechnung für Extended Support beginnt zu Beginn des Tages (UTC), an dem die Version das Ende des Standard Support erreicht.

Beispiel: ein Cluster und ein Monat mit 730 Stunden. Das ist eine Annahme für das Beispiel. Ihre Rechnung hängt von den echten Stunden ab.

• Standard Support: 730 h x $0,10 = $73,00 pro Cluster und Monat.
• Extended Support: 730 h x $0,60 = $438,00 pro Cluster und Monat.
• Unterschied: 730 h x $0,50 = $365,00 pro Cluster und Monat.
• Zehn Cluster auf einer Extended-Version: das Zehnfache des Unterschieds.

Welche Version in welcher Phase ist

Am 31.10.2026 nennt die AWS-Dokumentation die Versionen 1.34 bis 1.37 im Standard Support und die Versionen 1.31, 1.32 und 1.33 im Extended Support. Die Dokumentation nennt diese Termine (UTC):

• 1.31: Standard Support endete am 26. November 2025. Extended Support endet am 26. November 2026.
• 1.32: Standard Support endete am 23. März 2026. Extended Support endet am 23. März 2027.
• 1.33: Standard Support endete am 29. Juli 2026. Extended Support endet am 29. Juli 2027.
• 1.34: Standard Support endet am 2. Dezember 2026. Extended Support endet am 2. Dezember 2027.

aws eks describe-cluster-versions

Was am Ende von Extended Support passiert

EKS lässt eine Control Plane nicht auf einer Version, deren Extended Support abgelaufen ist. Sie können mit dieser Version keine neuen Cluster mehr anlegen. Bestehende Control Planes aktualisiert EKS nach dem Enddatum in einem schrittweisen Rollout auf eine unterstützte Version.

EKS kann nicht sagen, wann das geschieht. Das Upgrade kann jederzeit nach dem Enddatum kommen, und Sie werden vorher nicht benachrichtigt. Die AWS-Dokumentation empfiehlt, die Control Plane vorher selbst zu aktualisieren.

Das automatische Upgrade betrifft nur die Control Plane. Self-managed Nodes und Managed Node Groups bleiben auf der alten Version. Nodes von EKS Auto Mode werden eventuell selbst aktualisiert. Nach dem Upgrade müssen Sie die Add-ons und die Amazon-EC2-Nodes von Hand aktualisieren. Ein auf diese Weise aktualisiertes Cluster lässt sich nicht zurückrollen.

Die Upgrade-Policy lesen

Die Upgrade-Policy des Clusters bestimmt, was am Ende des Standard Support geschieht. Sie hat zwei Werte. STANDARD heißt: Das Cluster wird automatisch aktualisiert, und Sie zahlen keine Extended-Support-Gebühr. EXTENDED heißt: Das Cluster geht in den Extended Support, und Sie zahlen den Extended-Preis. EXTENDED ist der Standardwert für neue und bestehende Cluster.

So lesen Sie den aktuellen Wert eines Clusters:

aws eks describe-cluster \
  --name <cluster-name> \
  --query "cluster.upgradePolicy.supportType"

Extended Support abschalten und die Grenzen

Setzen Sie die Policy mit diesem Befehl auf STANDARD. In der Konsole gehen Sie auf Configuration, dann Manage, dann Kubernetes version settings, und wählen Standard support.

Es gibt eine feste Grenze. Sie können Extended Support nicht mehr abschalten, sobald das Cluster ihn erreicht hat. Die Policy lässt sich nur ändern, solange das Cluster auf einer Version im Standard Support läuft. Treffen Sie diese Entscheidung also vor dem Ende des Standard Support.

Auch in die andere Richtung ist Vorsicht nötig. Wenn Sie Extended Support wollen, empfiehlt AWS, ihn vor dem Ende des Standard Support zu aktivieren. EKS kann eine späte Änderung nicht garantieren, wenn ein automatisches Upgrade schon gestartet ist.

Ist ein Cluster schon im Extended Support, stoppen Sie die Gebühr nur, indem Sie es auf eine Version im Standard Support aktualisieren.

aws eks update-cluster-config \
  --name <cluster-name> \
  --upgrade-policy supportType=STANDARD

So planen Sie das Upgrade

Diese Schritte folgen der AWS-Anleitung zum Aktualisieren eines Clusters. Gehen Sie in dieser Reihenfolge vor.

• Zuerst testen. Lassen Sie Ihre Anwendungen in einem Test-Cluster oder in einem CI-Workflow gegen die neue Version laufen, bevor Sie Produktion anfassen.
• Versionen vergleichen. Mit kubectl version sehen Sie die Control Plane, mit kubectl get nodes die Nodes. Managed Nodes und Fargate-Nodes müssen vor dem Upgrade der Control Plane auf derselben Minor-Version wie die Control Plane sein.
• Veraltete APIs prüfen. Nutzen Sie die Amazon EKS Upgrade Insights (Teil der Cluster Insights) und den Deprecated API Migration Guide von Kubernetes. Die Insights suchen veraltete API-Nutzung in einem gleitenden Fenster von 30 Tagen. Der Status kann deshalb nach einer Korrektur bis zu 30 Tage brauchen, bis er sich ändert.
• Die Control Plane jeweils um eine Minor-Version aktualisieren. Von 1.31 auf 1.33 gehen Sie zuerst auf 1.32 und dann auf 1.33. Ein gestartetes Upgrade lässt sich nicht pausieren.
• Die Nodes auf dieselbe Minor-Version wie die Control Plane bringen. Managed Node Groups und self-managed Nodes werden nicht mit der Control Plane aktualisiert.
• Die Add-ons Amazon VPC CNI, CoreDNS und kube-proxy sowie weitere Werkzeuge wie cluster-autoscaler aktualisieren. Danach kubectl so aktualisieren, dass es höchstens eine Minor-Version von der Control Plane abweicht.

aws eks update-cluster-version --name <cluster-name> \
  --kubernetes-version <version-number> --region <region-code>