Ein Software-Entwickler verliert sein Amazon-Web-Services-Konto (AWS-Konto) inklusive zehn Jahre persönlicher Daten völlig überraschend. Jetzt erklärt er, dass alle Backup-Strukturen versagt hätten und AWS auf Nachfragen wohl nur ausweichend reagiere.
Was genau ist passiert? Am 23. Juli 2025 soll das 10 Jahre alte AWS‑Konto von Entwickler Abdelkader Boudih (aka „Seuros“) ohne Vorwarnung mit sämtlichen Daten gelöscht worden sein – inklusive Programmierbücher, Tutorials und unveröffentlichter Codeschnipsel (via Tom’s Hardware und eigene Blog-Notiz). Er beschreibt diesen Vorgang als „complete digital annihilation“ – eine vollständige digitale Hinrichtung/Vernichtung ohne Wiederherstellungschance.
Was ist AWS überhaupt genau? AWS (Amazon Web Services) ist eine Cloud-Plattform von Amazon, über die Unternehmen und Entwickler IT-Ressourcen wie Speicherplatz, Rechenleistung oder Datenbanken flexibel remote nutzen können.
Statt eigene Server zu betreiben, mieten sie diese Dienste je nach Bedarf – vergleichbar mit Strom aus der Steckdose, nur eben für digitale Infrastruktur.
Warum kam es zu der Löschung? Seuros zufolge war er jahrelang treuer AWS‑Kunde mit aktivem bezahltem Konto. Trotzdem soll er plötzlich Anfragen zur Verifizierung erhalten haben – diese hätten erst nach der Löschung begonnen und wirkten daher wie ein Ablenkungsmanöver, so der Entwickler rückblickend (via Hacker News).
Ein mutmaßlicher AWS‑Insider berichtet wohl von einem fehlerhaften internen Test der MENA‑Region (Middle East / North Africa), bei dem eine falsch gesetzte „–dry“-Flag eine Löschaktion gegen weniger aktive Konten auslöste – ohne Genehmigung und ohne Schutzmöglichkeit (via Hacker News).
Zum Verständnis: Ein „–dry“-Durchlauf ist i. d. R. eine Sicherheitsmaßnahme. Sie erlaubt Entwicklerinnen und Entwicklern sowie Admins, Änderungen zunächst gefahrlos zu simulieren, bevor sie real ausgeführt werden – eine Art Trockenübung eben.
Der 20-tägige Support-Horror
Wie reagiert der Support? Seuros beschreibt in seinem Blog-Eintrag den gesamten Hergang aus seiner Sicht. Infolge der mutmaßlichen Verifikationsschikane, durchliefe der Entwickler einen echten Support-Marathon, den er selbst als Horror bezeichnet. Hier seine persönliche Auflistung in gekürzter Form (zu sehen auf Blog-Eintrag, übersetzt aus dem Englischen):
- 10. Juli: AWS sendet eine Verifizierungsanfrage. Frist von 5 Tagen (einschließlich Wochenende).
- 14. Juli: Formular abgelaufen. Ich kontaktiere den Support. Einfache Frage: „Was benötigen Sie von mir?“
- 16.–20. Juli: Vier Tage lang keine Antwort. Dann: „Wir leiten die Anfrage an das zuständige Team weiter.“
- 20. Juli: Endlich kommt ein neues Formular.
- 21. Juli: Ich reiche meinen Ausweis und eine Stromrechnung (klares PDF) ein. Antwortzeit: 10 Stunden.
- 22. Juli: AWS: „Dokument unlesbar.“ Das gleiche PDF, das meine Bank ohne Probleme akzeptiert.
- 23. Juli: Konto gekündigt. Mein Geburtstagsgeschenk von AWS.
- 24. Juli: Ich stelle die einzige Frage, die zählt: „Existieren meine Daten noch?“
- 28. Juli: Nach 4 Tagen mit vorgefertigten Antworten verliere ich die Geduld.
- 29. Juli: Ich vergleiche ihre Ausflüchte mit rhetorischen Ablenkungen aus der Politik.
- 29. Juli: Sie geben endlich die Wahrheit zu.
- 30. Juli: In der letzten Nachricht bittet der Support um eine Bewertung des Services.
Statt direkter Hilfe soll Boudih über 20 Tage hinweg nur standardisierte, ausweichende Antworten und keine klare Auskunft, ob seine Daten überhaupt noch existieren, erhalten haben. Mittlerweile stehe fest, dass alle Daten unweigerlich gelöscht sind.
Was kann daraus gelernt werden? Seuros zieht aus seinem Daten-GAU klare Lehren, die für jeden Cloud-Nutzer relevant seien: Man solle sich niemals allein auf einen Anbieter verlassen – auch dann nicht, wenn man Daten über mehrere Regionen hinweg repliziert. Denn sobald der Anbieter selbst zur Schwachstelle wird, würden auch die besten technischen Maßnahmen nichts nützen.
Denn etablierte „Best Practices“ verlieren ihre Wirkung, sobald der Dienstleister eigenmächtig und ohne jede Vorwarnung handele. Deshalb rät Seuros, alle Schritte, E-Mails und Zeitpunkte akribisch zu dokumentieren, um im Ernstfall zumindest nachvollziehen zu können, was passiert sei.
Auch der Kunden-Support sei häufig nur ein „Theater“, das wenig echte Hilfe biete. Sein dringlichster Appell: Alle Nutzer sollten eine funktionierende Exit-Strategie haben, die sich innerhalb weniger Stunden umsetzen ließe – nicht erst nach Tagen oder Wochen (via Blog-Eintrag).
Seuros Fall ist tragisch – doch manchmal nutzen Menschen auch gezielt Fehler großer Anbieter aus. Wie im Fall eines Spielers, der Amazon austrickste und sich Technik im Wert von 1.000 € erschlich: Ein Spieler nutzt Service von Amazon dreist aus, ergaunert sich 2 AMD-CPUs und 2 SSDs im Wert von rund 1.000 Euro
Bitte lies unsere Kommentar-Regeln, bevor Du einen Kommentar verfasst.
“alleine auf einen Anbieter verlassen” = Kein Backup => Kein Mitleid
Backup ist immer eine gute Idee. “Kein Mitleid” würde ich an der Stelle aber auslassen. Wer hatte als Sysadmin nicht schon mal diesen Moment wo nach ‘nem ‘rm -rf’ im vermeintlichen zu löschenden Ordner der Befehl einfach viel zu lange gedauert hat? Wieso braucht der für 5 kleine Files so lange *schluck*? Da kannst du dann auch nicht einfach zu den betroffenen Usern gehen und ihnen vorwerfen, selber Schuld, sie hätten mehr Backups machen sollen wenn trotz Backup (mindestens) der Stand vom heutigen Tag futsch ist. In dem Fall hat es dem Bericht nach Amazon vergeigt. Dann müssen sie auch die Hand heben. Da tun sich die großen aber scheinbar immer irgendwie schwer. Das man ein Backup machen muss lernt man auf die ein oder andere Weise früher oder später. Die haben als Cloud-Maintainer aber auch eine gewisse Verantwortung für die Daten die ich ihnen anvertraue. Wenn mir eine Festplatte kaputt geht ärgere ich mich auch erst mal darüber (mit oder ohne Backup). Wenn es Fremdverschulden ist natürlich um so mehr.
Alles nur bei einem Cloud-Anbieter zu haben, Backup-Versprechen hin oder her, macht diesen zum Single-Point-of-Failure.
Amazon, Google, Apple, Microsoft – es gibt doch bei allen Großen immer wieder solche Fälle, in denen keiner helfen kann oder will.
Der Fall sollte uns allen eine Lehre sein – wenn man sich wirklich auf etwas verlassen will, muss man es selbst machen, vor allem Backups!