Zusammenfassung

  • AWS verortet die Control Planes von IAM, Route 53 und CloudFront in us-east-1 und warnt, dass eine Wiederherstellung über Create-, Update-, Delete- oder List-Operationen scheitern kann, solange diese Region beeinträchtigt ist.
  • Bei derselben Beeinträchtigung löst Route 53 weiterhin Namen auf und führt Health Checks aus: Ein vorkonfigurierter Wechsel hält, ein Wechsel per Record-Änderung hält nicht.

Niemand kauft eine Cloud wegen ihrer Regionen. Gekauft wird das Versprechen, dass der Rest weiterläuft, wenn ein Teil bricht. Dieses Versprechen ist eine kommerzielle Abstraktion. Darunter liegt eine Liste von Operationen, jede an einen bestimmten Ort gebunden, und diese Liste sagt sehr viel häufiger „Virginia“, als der Prospekt zugibt.

AWS veröffentlicht diese Liste. Das Whitepaper zu Fehlerisolationsgrenzen setzt die Control Planes von IAM, Route 53 und CloudFront für die kommerzielle Partition nach us-east-1 und erinnert zugleich daran, dass ihre Data Planes verteilt sind. Die Formulierung ist eindeutig: „These service operations have a cross-Region control plane dependency.“ (AWS Fault Isolation Boundaries: global services)

Das ist kein Eingeständnis schlechter Zuverlässigkeit, sondern die Beschreibung, wo eine Klasse von Aktionen ausgeführt wird. Für einen Vorstand lautet die Frage deshalb nicht, ob us-east-1 zuverlässig ist. Sie lautet, ob der Plan für einen schlechten Tag in us-east-1 eine Operation benötigt, die in us-east-1 läuft.

Health Checks überleben den Vorfall. Runbooks überleben ihn meist nicht.

Dieselbe Dokumentenserie trennt die beiden Hälften des DNS-Wechsels ungewöhnlich klar. Namensauflösung, die Ausführung von Health Checks und die daraus folgenden Routing-Änderungen gehören zur Data Plane von Route 53. Das Bearbeiten von Records, das Ändern von Gewichten und das Anlegen neuer Records dagegen: „These approaches depend on the Route 53 control plane.“ (Partitional services best practices)

Das gängigste Failover-Design der Branche hängt also konstruktiv an der Control Plane. Ein Runbook, das bei einer beeinträchtigten Region einen CNAME umschreibt, gleicht funktional dem Versuch, dem Defekten mit dem Defekten zu entkommen. Ein eingerichteter Health Check verlagert Verkehr, ohne dass jemand etwas editiert: Das eine wirkt während des Vorfalls, das andere erst danach.

Dieselbe Seite markiert eine zweite Falle. Sind CloudWatch-Metriken aus der beeinträchtigten Region nicht lesbar, können Health Checks auf dem zuletzt bekannten Zustand stehen bleiben. Der Alarm, der den Wechsel auslösen sollte, wird selbst zur Abhängigkeit – und die Empfehlung des Betreibers lautet, die betroffenen Alarme außerhalb der zu schützenden Region zu platzieren.

Bei Credentials zählt das Detail, nicht die Überschrift.

„AWS STS will process your request based on the originating Region and DNS resolver used.“ Anfragen aus einer standardmäßig aktivierten Region, über den Amazon-DNS-Server aufgelöst, können lokal bedient werden; Anfragen aus Opt-in-Regionen oder über einen anderen DNS-Anbieter werden weiterhin in us-east-1 bedient (AWS STS Regions and endpoints). Der globale Domainname erlaubt den Gegenschluss nicht: Nur die CloudTrail-Felder zu Endpunkttyp und bedienender Region entscheiden.

Was einen Wechsel wirklich umbringt, ist die zirkuläre Abhängigkeit.

Im September 2026 veröffentlichte das Architekturteam von AWS einen Fall, der nützlicher ist als die meisten Störungsberichte. Beim Test der Multi-Region-Notfallwiederherstellung für Terraform Enterprise stellten die Autoren fest, dass Failover-Skripte außerhalb der Primärregion weiterhin Kennungen aus State-Dateien im S3 jener Region benötigten. Wurde die S3-Verbindung blockiert, scheiterten die Skripte: Der Wiederherstellungsweg hing an dem Objekt, das wiederhergestellt werden sollte (Validating multi-Region DR for Terraform Enterprise with AWS FIS).

Die Korrektur passt in eine Zeile: „Remove recovery dependencies on the Region you are recovering from.“ Laufzeit-Statusabfragen wurden durch vorkonfiguriertes DNS-Failover ersetzt; die Wiederherstellung liest nicht mehr aus der betroffenen Region, genau dann, wenn sie es am dringendsten bräuchte.

Wie ein Kundenbericht aussieht, wenn die Abhängigkeit real ist.

Der Bericht von Coinbase zum Vorfall vom 7. Mai 2026 macht aus der Abstraktion einen konkreten Fall. Drei von fünf Matching-Engine-Knoten lagen in derselben Placement Group; als die Availability Zone ausfiel, fiel das Quorum mit. „There was no automated cross-zone failover.“ Zusätzlich verhinderte ein Defekt in der Control Plane des Managed Kafka die Neuwahl von Partition Leadern, betroffen waren Cluster mit zwei wie mit drei Availability Zones, und der Ausfall pflanzte sich über Gebührenberechnung und Quoting fort (Coinbase, 7. Mai 2026).

Das Dokument erlaubt zwei bequeme Lesarten nicht. Es belegt kein Versagen regionaler Isolation: ein Zonenereignis, eine Konzentrationsentscheidung auf Anwendungsebene und ein Defekt eines Managed Service sind nicht der Ausfall ganz Virginias. Es erlaubt aber auch nicht, alle Verantwortung beim Kunden abzuladen, weil Coinbase einen Teil der Dauer einem Service-Defekt zuschreibt. Beides gehört in denselben Absatz; beim Vorstand kommt meist nur das Beruhigende an.

Der Ausgang existiert. Er ist eine Option.

AWS dokumentiert auch den Rückweg der Control Plane selbst: Für öffentliche Hosted Zones gibt es Accelerated Recovery über us-west-2, mit dem Ziel von rund 60 Minuten nach Erkennung einer Beeinträchtigung in us-east-1. Entscheidend sind die Grenzen. „Accelerated recovery is available only for public hosted zones.“ Sie muss vor der Störung aktiviert sein, deckt private Hosted Zones nicht ab, und während des Failovers steht nur eine Teilmenge der API-Operationen zur Verfügung (Enabling accelerated recovery for managed public hosted zones). Anlegen und Löschen von Hosted Zones bleibt außen vor.

Damit stehen Ehrlichkeit und Grenze des Betreibers im selben Absatz. Der Ausgang existiert, Verfahren und Aktivierungszeitpunkt sind ausgewiesen. Er ist aber kein Standard: Er existiert nur für jene, die ihn vor dem Bedarf eingekauft und eingerichtet haben.

Die Lesart Dritter und ihre Grenzen.

Control Plane argumentiert, Identität, DNS, Monitoring und Wiederherstellungsoperationen behielten gemeinsame Abhängigkeiten, und schreibt: „It doesn’t cover failures in layers every region shares.“ (Control Plane, 12. Oktober 2026). CloudForge fordert, Wiederherstellungsabhängigkeiten über die direkt aufgerufenen Dienste hinaus zu kartieren, und schließt: „Recovery that needs new resources is the riskiest recovery.“ (CloudForge, 8. Oktober 2026). Beides ist Architekturinterpretation, keine interne Beobachtung des Anbieters; CloudForge weist KI-gestützte Recherche und Textarbeit aus.

Es bleiben drei Grenzen. Erstens hat diese Recherche keinen expositionsnormierten Vergleich erbracht, der zeigte, dass us-east-1 im Jahr 2026 unzuverlässiger war als andere AWS-Regionen. Zweitens ist das Publikationsjahr nicht das Störungsjahr: Analysen aus 2026 behandeln eine AWS-Störung im Oktober 2025, und der Betreiberbericht zu jenem Ereignis wurde hier nicht geöffnet, weshalb Mechanismus, Dauer und Reichweite nicht behauptet werden. Drittens ist unabhängige Publikation keine unabhängige Betriebsevidenz: Beratungsinterpretationen, Anbieteraussagen und Kundenberichte behalten ihre jeweilige Urheberschaft.

Der zugehörige Unternehmenseintrag steht unter Amazon.com, Inc..