AWS-Ausfall im Nahen Osten: Rechenzentrumsvorfall legt Cloud-Dienste in UAE und Bahrain lahm

Brandgeschehen als Auslöser

Der Ursprung des Vorfalls liegt in der Verfügbarkeitszone mec1-az2 innerhalb der Region ME-CENTRAL-1. Gegen 4:30 Uhr PST trafen externe Objekte das Rechenzentrumsgebäude, was unmittelbar Funkenflug und in der Folge einen Brand auslöste. Die zuständigen Feuerwehrkräfte unterbrachen daraufhin – zur Sicherung der Einsatzkräfte und zur Brandbekämpfung – sowohl die Hauptstromzufuhr als auch die Notstromversorgung der gesamten Anlage vollständig.

Diese erzwungene Abschaltung hatte sofortige Konsequenzen für den laufenden Betrieb: Amazon EC2-Instanzen, EBS-Volumes und aktive Datenbankprozesse, die an die betroffene Zone gebunden waren, fielen schlagartig aus. AWS bestätigte in einem frühen Statusupdate um 6:09 Uhr PST den Zusammenhang zwischen dem lokalen Stromausfall und den gemeldeten Verbindungsproblemen.

Ausmaß und Verlauf der Störung

Der Ausfall weitete sich rasch auf das gesamte Dienstportfolio in der Region aus. In ME-CENTRAL-1 waren nach AWS-Angaben mehr als 38 Cloud-Dienste beeinträchtigt, darunter AWS Lambda, Amazon Elastic Kubernetes Service (EKS), Amazon Virtual Private Cloud (VPC) sowie die Datenbankdienste RDS und DynamoDB. Besonders spürbar waren die Einschränkungen bei den EC2-Netzwerk-APIs: Befehle wie AllocateAddress, AssociateAddress, DescribeRouteTable und DescribeNetworkInterfaces schlugen für zahlreiche Nutzer fehl oder lieferten fehlerhafte Ergebnisse.

Im Laufe des Vormittags und Nachmittags gelang es AWS schrittweise, für 32 Dienste – darunter Amazon S3 und CloudWatch – die Funktionsfähigkeit wiederherzustellen. Die Kernnetzwerk-APIs blieben jedoch länger ausgefallen und stellten das Ingenieursteam vor besondere Herausforderungen, da viele abhängige Dienste auf deren Verfügbarkeit angewiesen sind.

Ein zweiter Störungsherd trat am Abend desselben Tages in der Region ME-SOUTH-1 (Bahrain) auf. Dort wurden erhöhte Fehlerraten bei API-Verbindungen gemeldet, die RDS sowie 46 weitere Dienste – darunter AWS CloudFormation und AWS WAF – beeinträchtigten. Die Ursache dieses zweiten Ereignisses lag offenbar in Konnektivitätsproblemen, die mittelbar mit dem Hauptvorfall in der UAE-Region zusammenhingen.

Besonders schwerwiegend war ein spätes Update vom 1. März um 22:46 Uhr PST: AWS bestätigte darin, dass ein weiteres lokales Stromversorgungsproblem inzwischen auch die dritte Verfügbarkeitszone mec1-az3 erfasst hatte. Damit waren zu diesem Zeitpunkt faktisch alle drei Verfügbarkeitszonen der Region ME-CENTRAL-1 in Mitleidenschaft gezogen. Der Start neuer EC2-Instanzen in der gesamten Region war vorübergehend nicht möglich, während bestehende Instanzen in der noch teilweise funktionierenden Zone mec1-az1 laut AWS unberührt blieben.

Wiederherstellung in mehreren Phasen

AWS reagierte auf den Vorfall mit einer mehrstufigen Strategie. Unmittelbar nach Bekanntwerden des Problems wurde der Datenverkehr aus der betroffenen Zone mec1-az2 umgeleitet, um die Auswirkungen auf verbundene Dienste zu begrenzen. Parallel arbeiteten Ingenieure an der Wiederherstellung einzelner API-Funktionen.

Ein erster Zwischenerfolg zeichnete sich gegen 14:28 Uhr PST ab, als positive Signale bei der Wiederherstellung von EC2-Describes und der AllocateAddress-API gemeldet wurden. Die AssociateAddress-API bereitete hingegen weiterhin Schwierigkeiten – Nutzer konnten Elastic-IP-Adressen nicht von Ressourcen in der betroffenen Zone lösen, was nachgelagerte Netzwerkkonfigurationen blockierte.

Um 16:26 Uhr PST vermeldete AWS deutliche Fortschritte bei AssociateAddress und kündigte eine gezielte Konfigurationsänderung an, die das Trennen von Elastic-IPs von ausgefallenen Ressourcen ermöglichen sollte. Diese Maßnahme wurde um 18:01 Uhr PST als abgeschlossen bestätigt. Ab diesem Zeitpunkt konnten Kunden neue Netzwerkadressen in nicht betroffenen Zonen erstellen und zuweisen sowie Elastic-IPs zwischen Zonen verschieben.

Für die vollständige Wiederherstellung der Stromversorgung in der ursprünglich betroffenen Zone mec1-az2 konnte AWS über den gesamten Berichtszeitraum hinweg keinen festen Zeitplan nennen, da die Genehmigung der zuständigen Behörden zum Wiedereinschalten der Anlage noch ausstand.

Empfehlungen für betroffene Nutzer

Während der gesamten Dauer des Vorfalls gab AWS in regelmäßigen Abständen Handlungsempfehlungen heraus. Kunden wurden aufgefordert, fehlgeschlagene API-Anfragen zu wiederholen, wo immer dies möglich war. Für zeitkritische Wiederherstellungsszenarien empfahl AWS, ausgefallene Ressourcen aus bestehenden EBS-Snapshots und Backups in nicht betroffenen Verfügbarkeitszonen oder alternativen AWS-Regionen neu aufzusetzen. Zudem sollten bei Netzwerkabfragen, insbesondere bei DescribeRouteTable und DescribeNetworkInterfaces, stets Instanz-IDs explizit übergeben werden, um zonenübergreifende Abfragefehler zu vermeiden.

Einordnung und Konsequenzen

Der Vorfall macht auf strukturelle Risiken in der Cloud-Nutzung aufmerksam, die auch bei einem etablierten Anbieter wie AWS eintreten können. Für Kunden, die ihre Workloads ausschließlich in einer einzelnen Verfügbarkeitszone betrieben, führte der Ausfall zu stundenlangen Produktionsunterbrechungen ohne kurzfristige Ausweichmöglichkeit. Kunden mit zonenredundanter Architektur nach dem Multi-AZ-Prinzip blieben hingegen weitgehend unberührt – ein Umstand, den AWS in seinen Statusmeldungen ausdrücklich hervorhob.

Der Vorfall unterstreicht, dass physische Infrastrukturrisiken – Feuer, Stromausfall, externe Einwirkungen – trotz aller technologischen Redundanzmaßnahmen reale Auswirkungen auf Cloud-Dienste haben können. Für Betreiber geschäftskritischer Systeme verdeutlicht das Ereignis, wie wichtig eine konsequente Redundanzplanung, regelmäßige Backup-Tests und dokumentierte Notfallwiederherstellungsverfahren sind – unabhängig davon, bei welchem Anbieter die Infrastruktur betrieben wird.

Auch interessant:

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon

Hamsterrad Rebell – Cyber Talk