Ihr Notfallplan setzt die Rückkehr der Region voraus

Zwei Verfügbarkeitszonen, sechs Stunden auseinander

Um 12:51 UTC am 2. März 2026 stellte die von AWS als mec1-az2 bezeichnete Verfügbarkeitszone in der Region Naher Osten VAE den normalen Betrieb ein. Bis 18:46 UTC desselben Tages war auch mec1-az3 betroffen. AWS bestätigte, dass beide im Zuge des weiteren Konflikts in der Region direkt von Drohnen getroffen worden waren. Eine dritte Anlage, mes1-az2 in der eigenständigen Region Bahrain, war an jenem Montag gegen 06:56 UTC gestört worden, was AWS auf einen Drohneneinschlag in unmittelbarer Nähe mit physischen Auswirkungen auf die Infrastruktur zurückführte.

Die Treffer lösten Brände aus. Die Brände aktivierten die Sprinkleranlagen der Rechenzentren, und das Wasser beschädigte Gerät. AWS meldete, Kunden sähen hohe Fehlerraten bei Datenaufnahme und Datenabgabe bei Diensten wie S3, das mindestens eine gesunde Zone je Region braucht. Das Unternehmen schätzte, die Instandsetzung der Anlagen und ihrer Kühlsysteme werde mindestens einen Tag dauern.

Behalten Sie diese Schätzung für den Rest des Textes im Kopf. Sie wurde nach bestem Wissen abgegeben, von einem Betreiber mit besseren Informationen als jeder Kunde, und sie beschrieb die Reparatur zutreffend.

Der Satz im Hinweis, auf den es wirklich ankam

Neben den Statusmeldungen sagte AWS den Kunden etwas Folgenreicheres. Der Anbieter riet ihnen, ihre Daten zu sichern und ihre Lasten möglicherweise in andere AWS-Regionen zu verlagern, weil der anhaltende Konflikt in der Region das Betriebsumfeld unvorhersehbar mache. Cloud-Anbieter fordern zahlende Kunden nicht leichtfertig auf, eine Region zu verlassen, die sie selbst verkaufen.

Dieser Hinweis ist das nützlichste Artefakt der ganzen Episode, denn er ist die einzige Anweisung, die den tatsächlichen Fehlermodus anspricht. Sprinklerschaden ist eine Reparatur. Ein unvorhersehbares Betriebsumfeld ist keine Reparatur, sondern eine Eigenschaft des Standorts, und keine Technik innerhalb des Gebäudes ändert daran etwas. AWS sagte den Kunden damit im Kern, dass die richtige Antwort auf diese Ereignisklasse der Ausstieg ist und nicht Geduld.

Der unangenehme Teil: Die meisten Notfallhandbücher haben eine Seite fürs Warten und keine fürs Gehen.

Mindestens ein Tag, gemessen am Kalender

Am 30. April besagte der eigene Dienststatus von AWS, die Region Naher Osten VAE habe infolge des Konflikts im Nahen Osten Schäden erlitten und könne Kundenanwendungen derzeit nicht zuverlässig tragen. Beachten Sie, was sich in diesem Satz geändert hat. Im März hatte die Region eine Störung und eine Schätzung. Ende April hatte sie einen Zustand und überhaupt keine Schätzung mehr.

Am 28. Juli veröffentlichte Cloudflare seine Quartalsübersicht zu Störungsereignissen im Internet, gestützt auf die Netzdaten von Radar. Darin steht, der HTTP-Verkehr nach me-central-1 sei niedrig geblieben, und die anhaltende Minderung wird als nachgelagerte Signatur physischer Schäden an der zugrunde liegenden Rechenzentrumsinfrastruktur beschrieben. Das ist eine unabhängige Messung statt einer Herstelleraussage, und sie weist rund fünf Monate nach den Treffern in dieselbe Richtung.

Die Rechnung für Ihre nächste Fortführungsprüfung: Die veröffentlichte Schätzung lautete mindestens ein Tag, und die beobachtbare Antwort wird weiterhin in Monaten gemessen.

Regionale Ausfallsicherheit zielt auf den falschen Fehler

Eine Architektur über mehrere Verfügbarkeitszonen ist eine wirklich gute Antwort auf den Fehler, für den sie entworfen wurde. Zonen sind so getrennt, dass ein Brand, eine Überschwemmung, ein Stromereignis oder ein Netzfehler in einer nicht die anderen mitnimmt. Diese Entwurfsannahme hält hervorragend, solange die Gefahr auf ein Gebäude beschränkt und zwischen Gebäuden unabhängig ist. Sie hält nicht mehr, wenn die Gefahr regional und korreliert ist, denn dann wird der Abstand zwischen Zonen in Kilometern gemessen und die schädigende Einwirkung nicht.

Zwei der drei Zonen in den Emiraten wurden am selben Tag getroffen. Eine Anlage in einer anderen Region, in einem anderen Land, war in derselben Woche betroffen. Zonenunabhängigkeit ist eine physische Aussage über eine bestimmte Liste von Gefahren, und bewaffneter Konflikt steht nicht auf dieser Liste. Das gehört klar gesagt, weil es hinterher offensichtlich klingt und vorher fast nie in einer Entwurfsprüfung auftaucht.

Für europäische Unternehmen besteht die Pflicht bereits: Finanzunternehmen schulden ihrer Aufsicht nach DORA einen dokumentierten Ausstiegs- und Fortführungsplan für kritische IKT-Dienstleister, und dieser Plan soll den Fall überstehen, dass eine Anbieterregion nicht verfügbar wird und nicht bloß langsam.

Vier Änderungen an Ihrem Handbuch in dieser Woche

Erstens: Schreiben Sie Ihre tatsächliche Wiederanlaufzeit für den Verlust einer ganzen Region auf, nicht einer Zone, und seien Sie ehrlich, ob Sie sie je getestet haben. Lautet die ehrliche Antwort, dass Regionsverlust außerhalb des Betrachtungsrahmens liegt, dann ist das eine Entscheidung, und sie gehört mit benanntem Verantwortlichen festgehalten statt weggelassen. Zweitens: Trennen Sie Reparaturszenarien von Ausstiegsszenarien. Ein Reparaturszenario wartet. Ein Ausstiegsszenario bewegt sich und braucht Daten, Identitätskonfiguration und Netzwege bereits anderswo bereitgestellt.

Drittens: Legen Sie vorab fest, welcher Beleg einen Umzug auslöst. Der nützliche Auslöser war hier nicht die Störung am 2. März, sondern der Hinweis, Kunden sollten eine Verlagerung erwägen. Anbieter sagen das selten, und wenn sie es tun, gehört es als Signal behandelt und nicht als Hintergrund. Viertens: Prüfen Sie, wo Ihre Sicherungen physisch liegen. Eine Sicherung innerhalb der Region, die Sie verlassen wollen, ist keine Sicherung, und der Moment, in dem Sie sie brauchen, ist der Moment, in dem die Region das Problem ist.

Weiterlesen: OpenAI zahlte in dem zurück, was ausfiel  |  Ein vierter Cloud-Riese wird plausibler