Die Cloud ist kein Backup: Der AWS-GAU im Nahen Osten zeigt, warum eine Kopie nicht reicht

Die Cloud gilt für viele Nutzer und Unternehmen längst als sicherer Ort für wichtige Daten. Doch was passiert, wenn selbst die Infrastruktur eines der größten Cloud-Anbieter der Welt physisch zerstört wird? Genau das zeigt derzeit Amazon Web Services (AWS). Nach Drohnenangriffen auf AWS-Infrastruktur in den Vereinigten Arabischen Emiraten und Bahrain steht Monate später fest: Auf einen Teil der ausschließlich dort gespeicherten Ressourcen und Daten kann AWS nicht mehr zugreifen. Der außergewöhnliche Fall zeigt ziemlich drastisch, warum Cloud-Speicher, Hochverfügbarkeit und ein echtes Backup nicht dasselbe sind.

Wenn selbst mehrere Rechenzentren nicht mehr reichen

AWS betreibt seine Infrastruktur nicht einfach in einzelnen riesigen Rechenzentren. Die Cloud ist in Regionen und sogenannte Availability Zones, kurz AZ, unterteilt. Eine Region besteht aus mehreren physisch voneinander getrennten Zonen. Fällt eine davon aus, können entsprechend aufgebaute Dienste über andere Teile der Infrastruktur weiterarbeiten. Doch auch diese Redundanz hat Grenzen. Im März 2026 wurden in der AWS-Region Middle East (UAE), intern me-central-1, zwei Einrichtungen direkt von iranischen Drohnen getroffen. AWS meldete strukturelle Schäden, Ausfälle bei der Stromversorgung und teilweise zusätzliche Wasserschäden infolge der Brandbekämpfung. Zahlreiche Dienste waren betroffen, darunter EC2, S3, DynamoDB, Lambda, CloudWatch und RDS. Zeitweise waren zwei der drei Availability Zones der Region erheblich beeinträchtigt.

AWS versuchte daraufhin parallel, die physische Infrastruktur wiederherzustellen und Dienste über softwareseitige Maßnahmen auf noch verfügbare Komponenten umzuleiten. Bei Amazon S3 lässt sich gut erkennen, wo die Grenzen dieser Architektur lagen. AWS beschreibt S3 als regionalen Dienst, der den vollständigen Verlust einer einzelnen Availability Zone verkraften soll. Nachdem jedoch eine zweite Zone erheblich beeinträchtigt wurde, stiegen auch dort die Fehlerraten für den Zugriff auf Daten deutlich an.

AWS kann Teile der Daten nicht mehr wiederherstellen

Was zunächst nach einem langwierigen Infrastrukturausfall aussah, hat inzwischen einen wesentlich endgültigeren Charakter bekommen. AWS arbeitete über Monate an der Wiederherstellung und unterstützte Kunden dabei, ihre Workloads in andere Regionen zu verlagern. Mitte September folgt schließlich die ernüchternde Bilanz. Für Ressourcen und Daten, die ausschließlich in der Availability Zone mec1-az2 in den Vereinigten Arabischen Emiraten lagen, kann AWS den Zugriff nicht wiederherstellen. Bei anderen Teilen der Region laufen die Arbeiten weiter. Noch schwerer traf es Bahrain. Dort erstreckten sich die Schäden laut AWS über mehrere Availability Zones und überschritten das Maß, für das die regionalen und Multi-AZ-Dienste ausgelegt sind.

AWS erklärt inzwischen, alle Möglichkeiten zur Wiederherstellung von Ressourcen und Daten ausgeschöpft zu haben, die vor dem Ausfall nicht in eine andere Region migriert worden waren. Das bedeutet nicht automatisch, dass jeder betroffene AWS-Kunde seine Daten endgültig verloren hat. Wer über zusätzliche Backups oder Kopien in anderen Regionen verfügte, kann seine Systeme daraus wiederherstellen. Wer seine einzige verfügbare Kopie dagegen ausschließlich innerhalb der betroffenen Infrastruktur gespeichert hatte, steht vor einem wesentlich größeren Problem.

Hochverfügbarkeit ist kein Backup

AWS lässt sich dabei nicht einfach vorwerfen, die versprochene Sicherheit seiner Cloud nicht eingehalten zu haben. Entscheidend ist vielmehr, welche Art von Sicherheit überhaupt gemeint ist. Eine Anwendung über mehrere Availability Zones zu verteilen, erhöht zunächst ihre Verfügbarkeit. Fällt ein Rechenzentrum oder eine Zone aus, können andere Teile der Infrastruktur übernehmen. Das ist Hochverfügbarkeit. Ein Backup verfolgt dagegen ein anderes Ziel. Es soll einen möglichst unabhängigen Datenbestand bereitstellen, auf den zurückgegriffen werden kann, wenn die produktiven Daten nicht mehr verfügbar, beschädigt oder gelöscht sind. Und dann gibt es noch Disaster Recovery. Dabei geht es darum, nach einem größeren Ausfall nicht nur einzelne Dateien, sondern Anwendungen, Datenbanken und komplette Dienste wieder in Betrieb nehmen zu können. Dazu können Backups ebenso gehören wie Replikationen in andere Regionen, vorbereitete Ersatzsysteme und definierte Wiederanlaufpläne. Multi-AZ, Cross-Region und Backup sind deshalb keine unterschiedlichen Namen für dasselbe Konzept.

Synchronisation ist noch lange kein Backup

Dasselbe Missverständnis begegnet einem im privaten Umfeld lediglich in kleinerem Maßstab. Wer seine Dokumente mit einem Cloud-Dienst synchronisiert, hat damit zunächst eine zusätzliche Verfügbarkeit geschaffen. Dieselben Dateien können auf Notebook, Desktop und Smartphone auftauchen und Änderungen werden zwischen den Geräten übertragen. Synchronisation beantwortet vereinfacht die Frage: Wie halte ich denselben Datenbestand an mehreren Stellen aktuell? Ein Backup beantwortet dagegen die Frage: Wie bekomme ich einen früheren und möglichst unabhängigen Datenbestand zurück, wenn mit meinen aktuellen Daten etwas schiefgeht? Cloud-Anbieter bieten dafür durchaus zusätzliche Schutzmechanismen. Papierkörbe, Dateiversionierung und Wiederherstellungsfunktionen können verhindern, dass ein versehentliches Löschen oder eine unerwünschte Änderung unmittelbar zum endgültigen Datenverlust führt.

Ein unabhängiges Backup ersetzen sie trotzdem nicht grundsätzlich. Denn eine Synchronisation kann auch unerwünschte Änderungen synchronisieren. Wird eine Datei gelöscht, ein kompletter Ordner verändert oder erhält ein Angreifer Zugriff auf den Account, betrifft das unter Umständen gerade das System, auf das man sich als vermeintliche Sicherung verlassen hat. Das Problem ist daher nicht die Cloud. Das Problem entsteht dann, wenn die Cloud gleichzeitig Produktivspeicher, Synchronisationsdienst und einzige vermeintliche Datensicherung ist.

Auch das NAS zu Hause ist keine Wunderwaffe

Die Gegenreaktion sollte allerdings ebenfalls nicht lauten, sämtliche Daten aus der Cloud abzuziehen und auf ein NAS zu Hause zu werfen. Damit würde man häufig nur einen Single Point of Failure gegen einen anderen austauschen. Ein NAS ist nicht automatisch ein Backup. Ein RAID ebenfalls nicht. RAID kann je nach Konfiguration den Ausfall einer oder mehrerer Festplatten abfangen. Gegen versehentlich gelöschte Dateien, Schadsoftware, einen kompromittierten Administratorzugang, einen Defekt des gesamten Systems, Überspannung, Feuer, Wasser oder Diebstahl hilft die Redundanz innerhalb desselben Geräts jedoch nur eingeschränkt oder überhaupt nicht. Auch Snapshots ändern daran nur einen Teil. Sie können dabei helfen, einen früheren Zustand nach einer versehentlichen Änderung wiederherzustellen. Liegen Snapshot und Originaldaten allerdings auf derselben Infrastruktur und diese fällt vollständig aus, verschwindet im schlimmsten Fall beides gemeinsam.

Cloud und lokaler Speicher können sich ergänzen

Es muss deshalb gar nicht auf die Entscheidung Cloud oder lokaler Speicher hinauslaufen. Gerade die Kombination unterschiedlicher Systeme kann die Sicherheit erhöhen. Der produktive Datenbestand kann beispielsweise auf einem PC oder NAS liegen, zusätzlich automatisiert auf ein zweites Speichersystem gesichert und eine weitere Kopie verschlüsselt an einem anderen Standort oder bei einem Cloud-Anbieter aufbewahrt werden. Genauso kann ein Cloud-Speicher der primäre Arbeitsort sein und regelmäßig auf ein davon unabhängiges System gesichert werden. Entscheidend ist weniger, welches Produkt dafür verwendet wird. Wichtiger ist die Frage, welche Ereignisse mehrere Kopien gleichzeitig betreffen können. Eine gute Backupstrategie versucht deshalb nicht nur, möglichst viele Kopien zu erzeugen, sondern unterschiedliche Fehlerdomänen zu schaffen.

Die alte 3-2-1-Regel ist plötzlich wieder ziemlich aktuell

Eine der bekanntesten Empfehlungen dafür ist die 3-2-1-Regel. Sie sieht drei Kopien wichtiger Daten vor: die produktive Kopie und zwei Sicherungen. Diese sollen auf zwei unterschiedlichen Speichermedien beziehungsweise Systemen liegen, wobei mindestens eine Kopie räumlich getrennt aufbewahrt wird. Für besonders wichtige Daten lässt sich das Prinzip noch erweitern. Bei 3-2-1-1-0 kommt eine zusätzliche offline beziehungsweise unveränderbar gespeicherte Kopie hinzu. Die Null steht dafür, dass die Sicherungen überprüft wurden und bei den vorgesehenen Wiederherstellungstests keine Fehler auftreten. Gerade der letzte Punkt wird gerne vergessen.

Ein Backup ist schließlich nur so gut wie der Restore. Eine Festplatte im Schrank, deren Inhalt seit Jahren niemand kontrolliert hat, kann ebenso ein böses Erwachen verursachen wie ein Backup-Job, der zwar jede Nacht startet, aber seit Monaten mit einem Fehler endet. Für Privatanwender muss daraus kein kleines Rechenzentrum im Keller entstehen. Wer seine wichtigen Daten auf dem Rechner oder NAS besitzt, zusätzlich auf ein externes Laufwerk sichert und eine weitere Kopie räumlich getrennt oder bei einem Cloud-Anbieter aufbewahrt, hat bereits mehrere voneinander unabhängige Sicherungen.

Unternehmen müssen noch einen Schritt weitergehen

Bei Unternehmen wird aus derselben Überlegung schnell ein deutlich komplexeres Konzept. Dort können getrennte Backup-Accounts, unveränderbare Sicherungen, geografisch getrennte Standorte und definierte Disaster-Recovery-Pläne hinzukommen. Ebenso wichtig ist die Frage, wie lange eine Wiederherstellung dauern darf und wie viele Daten im schlimmsten Fall verloren gehen dürfen. In der IT werden dafür häufig Recovery Time Objective (RTO) und Recovery Point Objective (RPO) verwendet. Das RTO beschreibt vereinfacht, wie lange ein Dienst nach einem Ausfall maximal nicht verfügbar sein darf. Das RPO legt fest, auf welchen Datenstand im schlimmsten Fall zurückgegangen werden kann. Auch AWS bietet seinen Kunden entsprechende Möglichkeiten. Backups können über mehrere Availability Zones redundant gespeichert und zusätzlich in andere AWS-Regionen kopiert werden. Genau diese geografische Trennung wird relevant, wenn nicht mehr nur eine Festplatte, ein Server oder ein einzelnes Rechenzentrum ausfällt.