AWS kann Kundendaten im Nahen Osten dauerhaft nicht wiederherstellen

Amazon Web Services hat Mitte September 2026 mitgeteilt, dass der Zugriff auf einen Teil der Kundenressourcen und Kundendaten im Nahen Osten dauerhaft nicht wiederhergestellt werden kann. Betroffen sind Daten, die ausschließlich in der Availability Zone mec1-az2 der Region Middle East (UAE), intern me-central-1, lagen, sowie Ressourcen, die ausschließlich in der Region Bahrain gespeichert waren. Auslöser waren nach Angaben von AWS Drohnenangriffe auf Rechenzentrumsinfrastruktur im März 2026.

Wichtig für die eigene Lagebeurteilung: Das ist kein pauschaler Datenverlust für alle AWS-Kunden in der Region. Wer eine zweite Kopie in einer anderen Region oder bei einem anderen Anbieter hatte, konnte daraus wiederanlaufen. Akut handeln muss heute niemand, der nicht selbst Workloads in diesen Zonen betrieben hat. Handeln sollte trotzdem jeder, der Produktivdaten nur an einer Stelle hält, denn genau diese Konstellation ist hier zum Totalverlust geworden. Der Fall trennt sauber zwischen Hochverfügbarkeit und Backup, und diese Unterscheidung ist für kleine und mittlere Unternehmen der eigentliche Mehrwert der Meldung.

Was ist passiert?

Anfang März 2026 bestätigte AWS auf der eigenen Statusseite, dass in den Vereinigten Arabischen Emiraten zwei Einrichtungen direkt von Drohnen getroffen wurden. In Bahrain schlug eine Drohne in unmittelbarer Nähe eines Rechenzentrums ein und beschädigte die Infrastruktur. AWS beschrieb strukturelle Schäden, unterbrochene Stromversorgung und in einigen Fällen zusätzliche Wasserschäden durch ausgelöste Löschanlagen. Die Einordnung der Angriffe in das Konfliktgeschehen im Nahen Osten stammt aus der Berichterstattung und den AWS-Statusmeldungen, nicht aus eigener Prüfung dieser Redaktion.

Betroffen war eine breite Dienstpalette, darunter EC2, S3, DynamoDB, Lambda, CloudWatch und RDS. Zeitweise waren in me-central-1 zwei der drei Availability Zones erheblich beeinträchtigt. AWS versuchte parallel, die physische Infrastruktur instand zu setzen und Dienste softwareseitig auf noch verfügbare Komponenten umzuleiten.

Genau hier liegt der architektonische Kern. AWS beschreibt S3 als regionalen Dienst, der den vollständigen Verlust einer einzelnen Availability Zone verkraften soll. Als eine zweite Zone erheblich beeinträchtigt wurde, stiegen auch dort die Fehlerraten beim Datenzugriff deutlich an. Die Auslegungsgrenze der Architektur war überschritten, und zwar genau so, wie AWS sie dokumentiert: Redundanz über mehrere Zonen einer Region deckt den Ausfall einer Zone ab, nicht den gleichzeitigen Verlust mehrerer Zonen.

Mitte September 2026 zog AWS Bilanz. Für Ressourcen und Daten, die ausschließlich in mec1-az2 lagen, lässt sich der Zugriff nicht wiederherstellen. An den übrigen Zonen der Region wird weiter gearbeitet und beschädigte Infrastruktur ersetzt. In Bahrain war die Lage schwerwiegender: Dort erstreckten sich die Schäden laut AWS über mehrere Availability Zones und überschritten das Maß, für das regionale und Multi-AZ-Dienste ausgelegt sind. AWS erklärt, alle Möglichkeiten zur Wiederherstellung derjenigen Ressourcen und Daten ausgeschöpft zu haben, die vor dem Ausfall nicht in eine andere Region migriert worden waren.

Für wen ist das relevant?

Unmittelbar relevant ist der Vorfall für Unternehmen mit Workloads in me-central-1 oder in der Region Bahrain. Diese Gruppe ist im deutschsprachigen Mittelstand klein. Die eigentliche Relevanz liegt eine Ebene darüber und betrifft sehr viel mehr Betriebe.

• Relevant für alle, die Produktivdaten in einer einzigen Cloud-Region oder in einem einzigen Cloud-Dienst halten, ohne unabhängige zweite Kopie.
• Relevant für alle, die annehmen, Daten in Microsoft 365, Google Workspace, einem S3-Bucket oder auf einer Cloud-VM seien automatisch gesichert. Diese Annahme ist in der Regel falsch. Der Anbieter sichert die Verfügbarkeit seiner Plattform, nicht den Inhalt Ihres Mandanten gegen Löschung oder Verschlüsselung.
• Relevant für alle, die als Backup eine Replikation, eine Synchronisation oder einen Papierkorb einsetzen. Replikation kopiert auch den Fehler mit, ein Papierkorb hat eine Aufbewahrungsfrist und ist administrativ löschbar.
• Nicht unmittelbar relevant für Unternehmen, die bereits eine regions- oder anbieterübergreifende, möglichst unveränderliche Sicherung betreiben und deren Rückspielen regelmäßig testen. Für diese Gruppe ist der Fall eine Bestätigung, kein Handlungsauftrag.

Wie kritisch ist das?

Für betroffene Kunden ohne zweite Kopie ist die Tragweite maximal: Daten, auf die der Anbieter den Zugriff dauerhaft nicht wiederherstellen kann, sind aus Sicht des Unternehmens verloren. Es gibt keine Eskalationsstufe darüber und keinen Support-Fall, der das noch dreht. Für die große Mehrheit der Leser ist die Meldung dagegen nicht operativ dringend, sondern strukturell wichtig.

AWS ist dabei nicht vorzuwerfen, eine zugesagte Sicherheit nicht eingehalten zu haben. Entscheidend ist, welche Art von Sicherheit überhaupt zugesagt war. Eine Anwendung über mehrere Availability Zones zu verteilen erhöht die Verfügbarkeit, das ist Hochverfügbarkeit. Georedundanz verteilt zusätzlich über geografisch getrennte Standorte und schützt gegen regionale Ereignisse. Ein Backup verfolgt ein anderes Ziel: einen möglichst unabhängigen Datenbestand bereitzustellen, auf den zurückgegriffen werden kann, wenn der Primärbestand zerstört, verschlüsselt oder versehentlich gelöscht wurde.

Der Drohnenangriff ist der extreme Beleg für ein sehr alltägliches Versagen dieser Annahme. Die Ursachen, die kleine und mittlere Unternehmen tatsächlich treffen, sind banaler und deutlich wahrscheinlicher: Ransomware, die über die Synchronisation in die Cloud-Kopie durchschlägt. Ein versehentlich gelöschtes Postfach oder ein gelöschter Bucket. Eine fehlerhafte Synchronisation, die den leeren Zustand nach oben repliziert. Ein gekündigtes oder gesperrtes Konto, mit dem der Zugriff auf den gesamten Datenbestand endet. In all diesen Fällen hilft Redundanz innerhalb einer Region genauso wenig wie in Dubai.

Was sollten Admins jetzt tun?

• Bestandsaufnahme zuerst. Listen Sie auf, welche Daten und Systeme ausschließlich in einer Region oder ausschließlich in einem Dienst liegen. Ohne diese Liste ist jede weitere Maßnahme Raten. Konkret: Mandanten von Microsoft 365 und Google Workspace, Objektspeicher-Buckets, Cloud-VMs, verwaltete Datenbanken, SaaS-Fachanwendungen.
• Prüfen, ob die vorhandene Absicherung wirklich ein Backup ist. Leitfrage: Existiert die Kopie noch, wenn der Primärbestand gelöscht wird, und ist sie aus dem Primärsystem heraus nicht löschbar? Wenn nein, handelt es sich um Replikation oder um einen Papierkorb, nicht um ein Backup.
• Mindestens eine Kopie außerhalb der Primärregion anlegen, möglichst außerhalb des Primäranbieters. Das ist der Kern der 3-2-1-Regel: drei Kopien, zwei verschiedene Medien oder Plattformen, eine davon außer Haus.
• Unveränderliche Sicherungen und getrennte Zugangsdaten für das Backupziel. Das Backupziel darf nicht mit denselben Konten erreichbar sein wie die Produktion, sonst nimmt ein kompromittiertes Administratorkonto die Sicherung gleich mit.
• Wiederherstellung tatsächlich testen und die Dauer messen. Ein erfolgreicher Sicherungslauf ist kein Nachweis. Nachweis ist ein zurückgespielter Datenbestand, geöffnet und fachlich geprüft, mit notierter Dauer.
• Vertragliche Zuständigkeit klären. Geteilte Verantwortung bedeutet: Der Anbieter verantwortet die Infrastruktur, das Unternehmen verantwortet seine Daten und deren Sicherung. Lesen Sie nach, wofür Ihr Anbieter tatsächlich haftet und welche Wiederherstellungszusagen er gibt.
• Wiederanlaufziele definieren. Legen Sie je Anwendung fest, wie viel Datenverlust tolerierbar ist und wie lange ein Ausfall dauern darf. Erst daraus ergibt sich, ob tägliche Sicherungen genügen oder ob es häufiger sein muss.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist die Lehre aus dem Vorfall unspektakulär und genau deshalb wertvoll. Cloud-Plattformen sind in aller Regel verfügbarer und besser betrieben als ein Serverraum im eigenen Haus. Verfügbarkeit ist aber nicht Unzerstörbarkeit. Die Zusagen eines Anbieters beziehen sich auf Ausfallszenarien, für die seine Architektur ausgelegt ist. Alles darüber hinaus, ob Krieg, Großbrand, ein fehlerhafter Massenlöschvorgang oder ein kompromittiertes Administratorkonto, fällt in die eigene Zuständigkeit.

Praktisch heißt das: Die Frage im nächsten IT-Termin lautet nicht mehr, ob die Cloud sicher ist, sondern wo die zweite Kopie liegt, wer sie löschen könnte und wann sie zuletzt erfolgreich zurückgespielt wurde. Wer darauf drei belastbare Antworten hat, ist gegen den geschilderten Fall ebenso gerüstet wie gegen den viel wahrscheinlicheren Ransomware-Vorfall am Dienstagvormittag.

Zur Quellenlage: Die Darstellung stützt sich auf die AWS-Statusmeldungen zur Region me-central-1, wie sie von Fachmedien wiedergegeben wurden, sowie auf die AWS-Dokumentation zu Regionen, Availability Zones und S3-Datenhaltbarkeit. Der ursprünglich ausgewertete Bericht von Deskmodder vom 20. September 2026 war zum Zeitpunkt der Recherche nicht abrufbar, die Domain verweigerte die Verbindung. Wörtliche AWS-Formulierungen, Kundenzahlen, Schadenssummen oder Angaben zu konkret betroffenen Kunden werden hier bewusst nicht wiedergegeben, weil sie in dieser Recherche nicht unabhängig belegbar waren.

Passende Anleitungen auf S-EDV

• 3-2-1-Backup-Strategie praktisch umsetzen zeigt Schritt für Schritt, wie die geforderte zweite und dritte Kopie außerhalb des Primärsystems entsteht.
• Unveränderliche Backups gegen Ransomware mit restic erklärt, wie ein Backupziel aufgesetzt wird, das sich aus dem Produktivsystem heraus nicht löschen lässt.
• Restore-Test-Routine etablieren beschreibt, wie aus einem erfolgreichen Sicherungslauf ein belegter Wiederherstellungsnachweis wird.

Quellen

• it-daily: AWS bestätigt Drohnenangriffe auf Rechenzentren, 3. März 2026
• NeoTeo: AWS kann Zugriff auf exklusiv gespeicherte Daten in Bahrain nicht wiederherstellen, 17. September 2026
• AWS Health Dashboard, Dienststatus und Ereignisprotokoll
• AWS-Dokumentation: Regionen und Availability Zones
• AWS-Dokumentation: Datenhaltbarkeit in Amazon S3