Seit dem 15. September 2026 ist es endgültig. Amazon hat in einem Update seines Health Dashboard bestätigt, dass der Zugriff auf Ressourcen und Daten in der Cloud Region Bahrain (me-south-1), die ausschließlich dort gehostet wurden, endgültig nicht mehr wiederhergestellt werden kann.

Damit sind Daten, deren einzige Kopie in Bahrain lag endgültig verloren. Wer regionsübergreifend repliziert oder Backups in einer anderen Cloud Region oder außerhalb der Cloud gehalten hatte, verlor Zeit, keine Daten.

Die Region Bahrain (me-south-1) bestand aus drei Availability-Zonen. Im März 2026 trafen Drohnenangriffe zwei Rechenzentren in den VAE und beschädigten eine Anlage in Bahrain, woraufhin AWS die Kunden aufforderte, ihre Disaster Recovery Pläne zu aktivieren und den Datenverkehr umzuleiten. Nachdem die erste Zone beschädigt war, riet AWS zur Verlagerung der Workloads in andere Regionen, und die meisten Kunden migrierten, bevor der Schaden an einer zweiten Zone im April die Region insgesamt unbrauchbar machte.

Damit rückt die Frage nach Redundanz und Datensicherheit bei der Cloud Nutzung wieder in das Bewusstsein. Viele Unternehmen verlassen sich bei der Cloud Nutzung auf das Prinzip, dass die Daten und Ressourcen in der Cloud “sicher” sind, solange sie auf mehrere Availability-Zonen verteilt werden. Der Fall in Bahrain zeigt drastisch, dass dies nicht der Fall ist und führt deutlich vor Augen, dass Availability und Möglichkeiten zum Disaster Recovery zwei unterschiedliche Dinge sind.

Availability-Zonen sind dafür gemacht den Ausfall von Ressourcen in einem einzelnen Rechenzentrum zu überstehen und die entsprechenden Services schnell wieder anlaufen zu lassen. Availability-Zonen liegen oft dicht beieinander, um bspw. Konzepte für synchrone Replikation mit einer Latenz im einstelligen ms-Bereich zu realisieren. Dies schützt aber nicht vor großflächigen Katastrophen oder Infrastrukturausfällen und schon gar nicht wie in Bahrain vor koordinierten Angriffen auf die Rechenzentrumsinfrastruktur. Konsequenterweise sieht das Bundesamt für Sicherheit in der Informationstechnik üblicherweise einen Mindestabstand der Rechenzentren von 200 km vor, um eine Georedundanz zu gewährleisten.

Unternehmen sollten in ihrer Rechenzentrums- oder Cloud Strategie daher unbedingt ausarbeiten, wie sie die Anforderungen nach hoher Verfügbarkeit und Disaster Recovery für je nach Kritikalität der Anwendung ausgestalten wollen. Mögliche Lösungsszenarien sind das Verschieben von Workloads und Daten in andere Cloud Regionen oder Backups der Daten in weit entfernten Rechenzentren (ggf. sogar außerhalb der Infrastruktur eines Cloud Provider bzw. Hyperscalers) vorzuhalten.

Für viele Unternehmen beginnt hier ein Dilemma zwischen Resilienz auf der einen Seite und Souveränität und DSGVO Konformität auf der anderen Seite: Resilienz bedeutet: Repliziere deine Daten in eine zweite, weit entfernte Region. Die regulatorische und vertragliche Realität lautet oft: Die Daten dürfen die EU nicht verlassen, manchmal nicht einmal das Land, und im souveränen Kontext sollen sie den Zugriffsbereich US-kontrollierter Betreiber gar nicht erst berühren.

Anschaulich wird dies an der AWS European Sovereign Cloud, die aktuell aus mehreren Availability-Zonen in einer einzige geografischen Region Brandenburg besteht. Eine Erweiterung in andere lokale Zonen ist geplant, aber noch nicht ausgeführt. Daher ist echte regionsübergreifende Disaster Recovery innerhalb der souveränen AWS-Cloud nicht möglich.

Wer echte Georedundanz will, muss entweder auf eine zweite souveräne Region warten oder Kopien in eine gewöhnliche EU-Region wie Frankfurt oder Irland legen und damit einen Teil der Souveränitätsversprechen relativieren.

Ein Ausweg könnte sein, die Daten in der nicht souveränen Cloud mit einem kundeneigenen Schlüssel zu verschlüsseln und diesen außerhalb der Hyperscaler Infrastruktur zu verwalten. Auch sollte die Möglichkeit von Backups an anderen Orten geprüft werden. Damit verliert man im noch unwahrscheinlichen Szenario eines Totalausfalls einer Cloud Region wenigstens nur Zeit und nur eine begrenzte Anzahl an Daten.

Daher ist die Ausarbeitung einer umfassenden Verfügbarkeits- und Disaster Recovery Strategie für kritische Anwendungen essenziell. Drei Ebenen sind dabei mindestens zu berücksichtigen. Die erste Ebene ist die Redundanz innerhalb der Anwendung selbst, die einzelne Hardwaredefekte abfängt, bevor überhaupt Daten verloren gehen. Die zweite ist das klassische lokale Backup von Datenbanken und Filestorage, mit dem sich Anwendungs- oder Administrationsfehler kurzfristig zurückspielen lassen, bei kritischen Infrastrukturen bereits georedundant. Die dritte ist eine externe Kopie je nach Anforderung an einem deutlich entfernten Standort, bei einem anderen Provider und ggf. auf einem anderen Medium.

Diese dritte Ebene sorgt für den eigentlichen Disaster Fall vor. Hier sind Zugeständnisse beim RPO (maximaler Datenverlust) wie bei der RTO (Zeit bis zum Wiederanlauf) wahrscheinlich unvermeidlich und es stellt sich die Frage nach dem Kosten- / Nutzenverhältnis: Welcher Schaden ist aus Geschäftssicht noch akzeptabel? Kritische Anwendungen gehören deshalb von Anfang an auf den Disaster Fall hin entworfen, und das hängt nicht nur an der Infrastruktur, sondern maßgeblich an den Fähigkeiten der Anwendung selbst.

Insbesondere müssen hier auch genutzte SaaS Anwendungen (wie bspw. die Nutzung von Office Produkten als Cloud Service) betrachtet werden. Für diese Anwendungen liegen oft nur wenig Informationen über den Betrieb und die dahinterliegende Datensicherung vor und die Anwender sind auf vertragliche Zusagen – sofern vorhanden – angewiesen.

Unternehmen sollten daher regelmäßig eine Risikobewertung ihrer Anwendungen und Daten in Bezug auf den Disaster Fall vornehmen und eine daraus abgeleitete Datensicherungs- und Wiederstellungstrategie entwickeln. Dabei sollen auch bislang unwahrscheinliche Ausfallszenarien berücksichtigt werden. Diese muss regelmäßig überprüft und das Recovery der Daten getestet werden.

Die Cloud hat in Bahrain gehalten, was zugesagt war: Schutz gegen den Ausfall eines einzelnen Rechenzentrums. Sie hat nicht gehalten, was viele stillschweigend hineingelesen haben: Schutz gegen den Verlust der Region selbst. Ob ein Unternehmen am Ende nur Zeit verliert oder seine Daten, entscheidet sich nicht im Moment der Katastrophe, sondern lange vorher, in der Architektur. Die eigentliche Frage ist deshalb nicht, ob sich so etwas wiederholt, sondern ob die eigene Umgebung den dauerhaften Verlust einer ganzen Region überstehen würde. Wer bei dieser Frage zögert, kennt die Antwort bereits.