Versteckte AWS Extended Support Kosten und wie man sie erkennt

Amazon Web Services hat seine Strategie für alternde Managed Services geändert. Anstatt sofortige Upgrades zu erzwingen, werden nicht unterstützte Versionen in eine kostenpflichtige Extended-Support-Stufe überführt. Diese Änderung, die in einem technischen Leitfaden vom November 2026 detailliert beschrieben wird, betrifft beliebte Dienste wie EKS, RDS, Aurora und ElastiCache. Für viele Engineering-Teams erfolgt diese Umstellung unbemerkt, was zu unerwarteten Posten auf den monatlichen Rechnungen führt, ohne dass es zu Dienstunterbrechungen oder Fehlermeldungen kommt.

Das Kernproblem besteht darin, dass die Anmeldung zu dieser Premium-Support-Stufe oft automatisch erfolgt. Wenn eine bestimmte Softwareversion das Ende des Standard-Supports erreicht, hält AWS die Ressource zwar am Laufen, erhebt aber einen erheblichen Zuschlag. Dies schafft ein verstecktes Kostenzentrum, das monatelang bestehen bleiben kann, wenn Teams die Versionsstände ihrer Infrastruktur nicht aktiv mit den Lifecycle-Daten von AWS abgleichen.

Was passiert ist

Wenn eine Version eines Managed Service abläuft, schaltet AWS den Cluster oder die Datenbank nicht ab. Stattdessen wird die Ressource in den Extended Support überführt, wobei eine Gebühr zusätzlich zum normalen Nutzungspreis erhoben wird. Es wird kein Ticket erstellt, kein Deployment-Fehler ausgelöst und keine Alarmierung an die Bereitschaftsdienst-Ingenieure gesendet. Der erste Hinweis auf diese Änderung ist oft ein Anstieg im Cost Explorer Diagramm, der erst bei routinemäßigen finanziellen Überprüfungen auffällt.

Diese Stille ist beabsichtigt. Die Ressource funktioniert weiterhin normal, sodass operative Monitoring-Tools keine Anomalien feststellen. Die Auswirkungen auf die Abrechnung sind jedoch sofort spürbar. Ein EKS-Cluster, der eine veraltete Version ausführt, verursacht beispielsweise zusätzliche Kosten von 0,50 USD pro Cluster-Stunde. Für einen einzelnen Cluster entspricht dies etwa 365 USD extra pro Monat. In Multi-Environment-Setups mit Entwicklungs-, Staging- und Produktions-Clustern auf derselben alten Version können die monatlichen Verschwendungen 1.000 USD überschreiten.

Das Problem wird durch Standardeinstellungen verschärft. EKS-Cluster sind standardmäßig für den Extended Support registriert, und RDS-Instanzen, die über die API erstellt werden, sind ebenfalls standardmäßig angemeldet. Obwohl die AWS-Konsole möglicherweise anzeigt, dass das Kontrollkästchen deaktiviert ist, aktiviert das zugrunde liegende API-Verhalten es oft, was zu inkonsistenten Zuständen zwischen verschiedenen Teams führt. Darüber hinaus werden Warnungen per AWS Health E-Mails an die Kontokontakte gesendet, die in großen Organisationen häufig in geteilten Postfächern ignoriert werden.

Wichtige Details

• EKS-Zuschlag: Kostet zusätzlich 0,50 USD pro Cluster-Stunde, insgesamt also 0,60 USD pro Stunde. Der Extended Support dauert 12 Monate, bevor ein erzwungener automatischer Upgrade erfolgt.
• RDS und Aurora: Erhebt einen zusätzlichen Betrag von 0,10 USD pro vCPU-Stunde in den ersten zwei Jahren, steigend auf 0,20 USD pro vCPU-Stunde im dritten Jahr. Dies gilt für Primärinstanzen, Standby-Instanzen und Read-Replikate.
• ElastiCache: Fügt einen Zuschlag von 80 % auf den On-Demand-Preis für Knoten in den ersten zwei Jahren hinzu, der im dritten Jahr auf 160 % steigt. Rabattierungen für Reservierungen gelten nicht für diesen Aufpreis.
• Automatische Anmeldung: Viele Dienste aktivieren sich standardmäßig über die API, was bedeutet, dass Ressourcen berechnet werden, auch wenn das Team beabsichtigte, sie zu aktualisieren oder stillzulegen.
• Stille Umstellung: Es werden keine operativen Warnungen ausgelöst. Die einzige Benachrichtigung erfolgt über AWS Health E-Mails, die in Multi-Account-Setups oft übersehen werden.
• Kommende Fristen: Ab November 2026 geht EKS 1.34 am 2. Dezember in den Extended Support, gefolgt von RDS PostgreSQL 14 am 28. Februar 2027.

Hintergrund

Extended Support ist eine Lifecycle-Phase, die die Lücke zwischen dem Ende des Standard-Supports und der obligatorischen Stilllegung überbrückt. Cloud-Anbieter hätten historisch gesehen Upgrades erzwingen oder Benutzer verwundbar lassen können. AWS bietet nun eine kostenpflichtige Gnadenfrist an, die Teams mehr Zeit für die Planung von Migrationen gibt. Dieser Komfort hat jedoch seinen Preis. Die Zuschläge sollen schnelle Upgrades incentivieren, setzen aber voraus, dass Kunden die Änderungen in der Abrechnung bemerken.

Das Verständnis des Unterschieds zwischen Standard- und Extended Support ist entscheidend für die Budgetplanung. Der Standard-Support umfasst regelmäßige Patches und Minor Updates. Der Extended Support bietet nur kritische Sicherheitskorrekturen. Sobald der Extended Support endet, führt AWS ein automatisches Upgrade nach seinem eigenen Zeitplan durch, was zu Breaking Changes führen kann, wenn die Anwendung nicht bereit ist. Daher ist ein proaktives Management unerlässlich, um sowohl finanzielle Verschwendung als auch operative Risiken zu vermeiden.

Warum es wichtig ist

Für Teams, die Self-Hosting betreiben oder komplexe Cloud-Infrastrukturen verwalten, untergraben diese versteckten Kosten die Budgeteffizienz. Eine einzelne vergessene RDS-Instanz mit mehreren Read-Replikaten kann Hunderte von Dollar unnötiger monatlicher Gebühren verursachen. Skaliert man dies auf Dutzende von Diensten und Accounts, werden diese Belastungen zu einer signifikanten Leckage in den Cloud-Ausgaben. IT-Leiter und DevOps-Ingenieure müssen die Versionshygiene als finanzielle Kontrolle betrachten, nicht nur als technische Aufgabe.

Darüber hinaus ist es riskant, sich auf automatische Upgrades am Ende des Extended Periods zu verlassen. AWS aktualisiert die Control Plane oder Engine nach seinem eigenen Zeitplan, der möglicherweise nicht mit Ihrem Release-Zyklus übereinstimmt. Dies kann zu Kompatibilitätsproblemen mit Anwendungscode oder Abhängigkeiten führen. Indem Teams diese Fristen ignorieren, tauschen sie vorhersehbare Wartungsfenster gegen chaotische, erzwungene Migrationen unter Druck, was potenziell zu Ausfallzeiten führen kann.

Was Sie tun können

• Audit-Skript ausführen: Verwenden Sie ein schreibgeschütztes Python-Skript mit boto3, um alle Regionen und Accounts zu scannen. Identifizieren Sie Ressourcen im Extended Support und berechnen Sie den monatlichen Zuschlag für jede Ressource.
• EKS-Upgrade-Bereitschaft prüfen: Führen Sie aws eks list-insights aus, um veraltete APIs zu identifizieren, die Upgrades blockieren. Aktualisieren Sie Add-ons und Control Planes immer nur um eine Minor-Version.
• Bei Bedarf abmelden: Deaktivieren Sie den Extended Support für unkritische Umgebungen über die API, um stattdessen ein automatisches Upgrade zu erzwingen, anstatt Gebühren zu zahlen. Verwenden Sie --engine-lifecycle-support open-source-rds-extended-support-disabled für RDS.
• EventBridge-Warnungen einrichten: Erstellen Sie eine Regel für AWS_*_PLANNED_LIFECYCLE_EVENT Typen. Leiten Sie diese Ereignisse an ein SNS-Thema weiter, um Ihr Team vor Ablauf der Fristen über Slack oder E-Mail zu benachrichtigen.
• Valkey für ElastiCache in Betracht ziehen: Wenn das Upgrade von Redis komplex ist, erwägen Sie eine Migration zu Valkey, das derzeit außerhalb des Extended Support Zyklus liegt und niedrigere Listenpreise bietet.
• Multi-AZ-Kosten überprüfen: Denken Sie daran, dass Zuschläge für jedes Replikat und jeden Standby gelten. Nehmen Sie diese in Ihre Kostenberechnungen auf, wenn Sie Upgrades planen.