AWS veröffentlicht Version Currency SLAs für Aurora und RDS

Wer jemals versucht hat, ein Postgres-Major-Upgrade für eine Zahlungsplattform zu terminieren, weiß: Der eigentliche Engpass ist nicht der pg_upgrade-Befehl, sondern der Kalender. Das Produkt will das neue Feature, die Sicherheitsabteilung will die CVE geschlossen sehen, und AWS hat Ihnen nie schriftlich mitgeteilt, wann die Version tatsächlich in der Konsole erscheint. Das hat sich diese Woche geändert.

AWS hat nun Versions-Zeitpläne für Aurora und RDS für PostgreSQL, MySQL und MariaDB veröffentlicht. Zum ersten Mal haben Plattformverantwortliche ein dokumentiertes Fenster, das sie ohne Vorbehalte in eine Roadmap aufnehmen können.

Was passiert ist

Wie Amazon Web Services (AWS) berichtete, veröffentlicht das Unternehmen Ziel-Zeitfenster für neue Major- und Minor-Versionen. Die Zahlen sind konkret genug für die Planung und erklären, warum Aurora-Upgrades nie so schnell wirkten wie RDS-Upgrades.

Beginnen wir mit RDS. Minor-Versionen von RDS für PostgreSQL erscheinen innerhalb von 7 Tagen nach dem Community-Release. RDS für MySQL und MariaDB Minor-Versionen erscheinen innerhalb von 30 Tagen. Major-Versionen von RDS für PostgreSQL kommen innerhalb von 30 Tagen nach dem Community-Release <major>.1. RDS für MariaDB Major-Versionen erscheinen innerhalb von 3 Monaten nach dem ersten Patch-Release der Community. RDS für MySQL Major-Versionen erhalten 6 Monate ab dem Community-Release <major>.1, und nur für Oracle MySQL LTS Majors.

Aurora ist von Natur aus langsamer. Aurora PostgreSQL Minor-Versionen werden innerhalb von 3 Monaten nach dem Community-Release ausgeliefert. Aurora PostgreSQL Major-Versionen innerhalb von 8 Monaten nach dem Community-Release <major>.1. Aurora MySQL Minor-Versionen innerhalb von 3 Monaten. Aurora MySQL Major-Versionen innerhalb von 12 Monaten nach dem Community-Release <major>.1. Aurora LTS-Releases pro Major erscheinen bei beiden Engines innerhalb von 12 Monaten nach dem Aurora Major GA.

AWS erläuterte auch die Ausgangspunkte. Postgres-Produktionsreleases auf AWS basieren typischerweise auf dem Community-Release <major>.1, der üblicherweise etwa drei Monate nach dem initialen Major erscheint. MariaDB-Zeitpläne werden ab dem ersten Patch-Release der Community gemessen. MySQL-Zeitpläne gelten nur für Oracle MySQL LTS Majors, gemessen ab <major>.1.

Das Unternehmen wies erneut auf die begleitenden Werkzeuge hin: automatische Minor-Version-Upgrades während Wartungsfenstern, AWS Organizations Upgrade-Rollout-Richtlinien, RDS Database Preview für frühzeitiges Testen, Blue/Green Deployments für den Cutover sowie Amazon RDS Extended Support für Workloads nach dem Community-End-of-Life.

Technischer Hintergrund

Der Unterschied zwischen RDS- und Aurora-Zeitplänen ist die eigentlich interessante Engineering-Geschichte. AWS führt ihn auf zwei Faktoren zurück: die Entwicklungsweise der Upstream-Communities und das, was Aurora unterhalb der Engine hinzufügt.

PostgreSQL und MariaDB entwickeln offen. AWS kann Commits ziehen, Validierungen durchführen und interne Builds weit vor einem Community-GA aufbauen. MySQL-Commits sind laut AWS erst kurz vor dem öffentlichen Release verfügbar, was das Pre-GA-Validierungsfenster verkürzt. Das allein erklärt, warum RDS für PostgreSQL Minor-Versionen in einer Woche ausgeliefert werden, während RDS für MySQL Minor-Versionen einen vollen Monat erhalten.

Aurora ist ein anderes Tier. Es ersetzt die Community-Storage-Engine durch eine verteilte Storage-Schicht und fügt Global Database- und Serverless-Funktionen hinzu. Jede neue Engine-Version muss gegen dieses Substrat neu validiert werden. Read Replicas, Log Shipping, Crash Recovery und Serverless-Skalierungspfade müssen alle weiterhin funktionieren. Deshalb benötigt Aurora PostgreSQL 3 Monate für einen Minor, den RDS in 7 Tagen ausliefert, und deshalb erhalten Aurora MySQL Majors 12 Monate gegenüber 6 Monaten bei RDS MySQL.

Der <major>.1-Ankerpunkt ist ein weiterer wichtiger Aspekt. Postgres 18.0 ist nicht das, was zuerst auf AWS landet. Es ist Postgres 18.1, etwa drei Monate später, nachdem die erste Runde produktiver Bugs aufgetaucht und behoben wurde. Wer die Postgres Release Notes kennt, weiß, dass das .1-Release üblicherweise bedeutende Edge Cases bereinigt. AWS kodifiziert damit eine betriebliche Präferenz, die viele erfahrene DBAs bereits haben: Führen Sie .0 auf nichts aus, das Sie nachts anruft.

Meine Einschätzung: AWS gibt damit zu, dass sein Versions-Rhythmus immer ein versteckter Kapazitätsplanungs-Input war, und behandelt ihn endlich als solchen. Die Veröffentlichung der SLA ist nützlicher als ihre Verkürzung.

Wer betroffen ist

Die unbequeme Wahrheit: Teams, die auf Aurora wegen des „Managed Everything"-Versprechens standardisiert haben, sehen sich nun mit dokumentierten Verzögerungen konfrontiert, die RDS-Kunden nicht tragen müssen. Wenn Sie Aurora PostgreSQL betreiben und eine kritische CVE in einem Community-Minor auftaucht, warten Sie bis zu 3 Monate. RDS für PostgreSQL-Kunden warten bis zu 7 Tage. Bei sicherheitssensitiven Workloads ist das kein Rundungsfehler.

iGaming-Plattformen spüren dies am stärksten. Regulatoren in mehreren EU-Ländern erwarten eine zeitnahe Behebung bekannter Schwachstellen. Ein 3-Monats-Fenster bei Aurora Minors bedeutet, dass Sie eine kompensatorische Kontrollstrategie bereit haben müssen, oder Sie verlagern patch-sensitive Workloads zurück in Richtung RDS. Produktionsvorfälle, die ich im Zusammenhang mit verzögertem Datenbank-Patching gesehen habe, werden meistens von Auditoren entdeckt, bevor Angreifer sie finden – aber beides kommt vor.

Fintechs, die Aurora MySQL für Ledger-Systeme betreiben, erhalten die härteste Zahl: 12 Monate für eine Major-Version. Das ist ein vollständiger jährlicher Planungszyklus. Wenn Oracle MySQL LTS einen Major mit einem Feature ausliefert, auf das Sie für Q1 gesetzt haben, und Sie Aurora MySQL betreiben, werden Sie es mit ziemlicher Sicherheit nicht in Q1 erhalten. Teams, mit denen ich gearbeitet habe, unterschätzen diese Verzögerung typischerweise um die Hälfte.

Ad-Tech-Unternehmen, die Aurora für das Serverless-Skalierungsversprechen betreiben, sollten LTS in Betracht ziehen. Das 12-Monats-LTS-Fenster pro Major bei Aurora bedeutet, dass Sie einen stabilen Minor festlegen und Major-Upgrades mit Ihrem eigenen Release-Train ausrichten können, anstatt dem Community-Rhythmus hinterherzulaufen. Das ist die richtige Haltung für High-Throughput-Analytics, bei denen Engine-Wechsel mehr Schmerzen verursachen als fehlende Features.

MariaDB-Shops, größtenteils von Self-Hosted migrierte Nutzer, die zu RDS wechseln, erhalten ein sauberes Angebot: 30-Tage-Minors, 3-Monats-Majors ab dem ersten Patch. Hier gibt es nichts zu beklagen.

Playbook für Engineering-Teams

Erledigen Sie dies in den nächsten zwei Wochen.

Erstens: Ordnen Sie Ihre aktuellen Engine-Versionen den veröffentlichten Zeitplänen zu. Identifizieren Sie jede Datenbank, die mehr als einen Minor-Release zurückliegt, und berechnen Sie, wann das nächste Community-Release realistischerweise auf AWS verfügbar sein wird. Setzen Sie diese Termine in denselben Kalender wie Ihre Produkt-Roadmap. Wenn Ihre Aurora PostgreSQL-Flotte mehr als zwei Minors zurückliegt, ist das ein Governance-Problem, kein technisches.

Zweitens: Aktivieren Sie automatische Minor-Version-Upgrades für alles, was kein Tier-0-Revenue-System ist. Das 7-Tage-Fenster von RDS Postgres ist wertlos, wenn Patches unangewendet bleiben, weil niemand das Wartungsfenster übernehmen möchte. Kombinieren Sie es mit AWS Organizations Upgrade-Rollout-Richtlinien, damit Dev und Test das Risiko absorbieren, bevor es in die Produktion geht.

Drittens: Führen Sie Blue/Green Deployments als Standardweg für Major-Upgrades ein. Ein Cutover mit minimaler Ausfallzeit ist der Unterschied zwischen einem Upgrade am Dienstagnachmittag und einem Wochenend-Krisenraum. Kombinieren Sie es mit OpenTelemetry-Instrumentierung auf der Anwendungsseite, damit Sie die Query-Latenz zwischen Blue und Green vergleichen können, bevor Sie den Traffic umschalten.

Viertens: Nutzen Sie RDS Database Preview für Major-Version-Tests. Wenn Ihr App-Team einen neuen PostgreSQL- oder MySQL-Major in einer Nicht-Produktionsumgebung vor dem Aurora GA in den Händen hält, hat es Monate Zeit, Breaking Changes in Query Plannern, Extension-Kompatibilität und Treiber-Verhalten zu erkennen.

Fünftens: Wenn Sie sich dem Community-End-of-Life nähern, kaufen Sie Zeit mit Amazon RDS Extended Support und nutzen Sie es. Betrachten Sie es nicht als dauerhaftes Zuhause. Behandeln Sie es als Startbahn, um das bereits geplante Upgrade abzuschließen.

Wichtigste Erkenntnisse

• RDS für PostgreSQL Minor-Versionen werden innerhalb von 7 Tagen nach dem Community-Release ausgeliefert. Aurora PostgreSQL Minors benötigen bis zu 3 Monate. Planen Sie Security-Patching nach der langsameren Zahl.
• Aurora Major-Versionen liegen konzeptbedingt hinter RDS zurück, weil die verteilte Storage-Schicht, Global Database und Serverless-Layer bei jedem Release neu validiert werden müssen.
• Postgres- und MariaDB-Zeitpläne werden ab dem ersten Patch-Release gemessen, nicht ab .0. AWS baut den Instinkt „Niemals Dot-Zero betreiben" als Richtlinie ein.
• Aurora LTS-Releases innerhalb von 12 Monaten nach Aurora Major GA geben stabilitätsorientierten Teams eine dokumentierte mehrjährige Baseline. Nutzen Sie dies, wenn Engine-Wechsel mehr schmerzen als fehlende Features.
• Aktivieren Sie automatische Minor-Upgrades, nutzen Sie Blue/Green für Majors und setzen Sie RDS Database Preview und Extended Support als taktische Werkzeuge ein, nicht als dauerhafte Lösungen.