Als die Cloud zusammenbrach: Wie ein einziger AWS-Ausfall halb das Internet lahmlegte

Gegen Mitternacht Pazifikzeit am 20. Oktober begann sich das Internet seltsam zu verhalten. Amazon lud nicht. Mercado Livre, der brasilianische E-Commerce-Riese, spielte verrückt. Duolingo stürzte mitten in einer Lektion ab. Fortnite-Spieler wurden mitten im Match rausgeworfen. Slack-Nachrichten hörten auf, versendet zu werden. PagerDuty pagte nicht.

Was als „Hmm, vielleicht ist es mein WLAN"-Moment begann, eskalierte schnell zu etwas viel Größerem. Ein ausgewachsener AWS-Ausfall, schon wieder. Und wie ein digitaler Dominoeffekt begannen Apps, Spiele, Tools und Websites weltweit auszuflackern.

Alle Zeichen deuteten auf einen bekannten Verdächtigen: us-east-1.

Eine Region, um sie alle zu beherrschen

Amazon Web Services (AWS) ist das unsichtbare Rückgrat eines Großteils des Internets. Die Region us-east-1, in Nord-Virginia gelegen, ist nicht nur einer der ältesten und größten Data Hubs, sie ist auch das Nervenzentrum vieler globaler Services. Wenn sie stolpert, geht ein schockierend großer Teil des Internets mit ihr zu Boden.

Genau das ist passiert.

Laut AWS' eigenem Status-Dashboard begann das Problem mit „erhöhten Fehlerraten und Latenzen", die eine breite Palette von Services betrafen, CloudFront, EC2, DynamoDB, Kinesis, SageMaker und mehr. Es folgte eine Kaskade von Problemen, die App-Zugriff, Transaktionen und sogar interne Services wie Amazon.com und Audible betrafen.

Anders gesagt: Die Cloud ist kaputtgegangen. Und wenn AWS strauchelt, reißt es einen beträchtlichen Teil der digitalen Welt mit sich.

„Wer ist noch im Bereitschaftsdienst? Los geht's"

Der Ausfall traf die Tech-Welt wie ein Güterzug. DevOps-Engineers hasteten. Bereitschaftsdienste liefen an. Monitoring-Systeme wie PagerDuty litten ironischerweise ebenfalls unter dem Ausfall und ließen manche Teams im Dunkeln zurück. Ein Nutzer scherzte: „Zum Glück nutzt AWS kein PagerDuty", während ein anderer grimmig anmerkte: „500 Sev-2-Tickets jetzt. Wird immer noch mehr!"

Slack lief heiß, fror aber dann auch für manche Nutzer ein. Jira? Down. Autodesk-Services? Aus. Bankportale in Brasilien und Australien? Fehlerhaft. OnlyFans, die McDonald's-Monopoly-App, Clash Royale, und sogar Tidal, alles, was auf AWS aufbaut, zeigte irgendeine Form von Aussetzer. Jemand kommentierte: „Ich wollte nur Fortnite spielen und hatte 30 Kills. RIP."

Es war eine surreale, branchenübergreifende Störung, die den Vorhang darüber lüftete, wie zentralisiert das moderne Internet wirklich ist.

Der Single Point of Failure, über den niemand sprechen will

Wenn der Ausfall eines offengelegt hat, dann das: Wir haben eine digitale Welt geschaffen, die sich stark, wirklich stark, auf ein paar große Cloud-Anbieter stützt. Und manchmal nur auf eine einzige Cloud-Region.

us-east-1 ist berüchtigt geworden. Dort landen viele Standard-Deployments. Sie hostet Control Planes für Services, die sich über mehrere Regionen erstrecken. Wenn sie also stockt, können Redundanzpläne, die auf dem Papier solide aussehen, in der Realität versagen. „IAM-Probleme betreffen alle Regionen", merkte ein Nutzer an und hob hervor, wie zentrale Identitäts- und Zugriffsdienste, die oft dort gehostet werden, sich durch angeblich isolierte Systeme ziehen können.

Ein Kommentar brachte es perfekt auf den Punkt: „Das passiert, wenn man das Internet zentralisiert."

War es ein Cyberangriff?

Da Fortnite, Apex Legends und Epic Games alle betroffen waren, zog die Gaming-Community schnell die Augenbrauen hoch. War das ein Cyberangriff? AWS sagte das nicht, zumindest nicht in ihren ersten Mitteilungen. Man hielt sich an vage Formulierungen wie „untersucht erhöhte Fehlerraten".

Trotzdem läuft die Gerüchteküche auf Hochtouren, wenn ein globales Web-Rückgrat wackelt. Leute verglichen es mit dem berüchtigten CrowdStrike-Update-Debakel, andere spekulierten über ein misslungenes Deployment oder einen internen Fehler. Ein Scherz machte die Runde: „Hi, ich habe gerade bei AWS angefangen und einen Bug im DynamoDB-Cluster gesehen. Ich hab ihn gefixt und in Prod gepusht, bevor ich meine Kinder zur Schule gebracht habe. Bin gleich zurück!"

Die menschliche Seite des Ausfalls

Trotz des tech-lastigen Kontexts kamen die aufschlussreichsten Momente von echten Menschen, die mit echten Konsequenzen zu tun hatten:

• Ein Bundesangestellter postete trocken, dass seine AWS-basierten Unternehmensressourcen im Eimer seien, aber hey, er ist ja beurlaubt, also, Schulterzucken.
• Ein anderer Nutzer in Polen versuchte, sich bei Autodesk Fusion einzuloggen, um etwas 3D-Modellierung zu machen, bekam aber nur Fehler zu Gesicht: „Bing Bong, kann mich nicht einloggen."
• Eine Studentin aus Phoenix verpasste zwei Abgabefristen, weil ihre gewohnten Tools offline waren.

Andere nutzten den Moment für guten alten Unfug. „Gerade gewinnt niemand Preise in der McDonald's-App", stellte jemand fest. Ein anderer schnappte sich eine 50-Dollar-DoorDash-Geschenkkarte, sobald die Server teilweise wieder liefen.

Es war zu gleichen Teilen Chaos, Komödie und Krisenmanagement.

Also … was jetzt?

AWS behob das Problem schließlich innerhalb weniger Stunden. Für viele Nutzer bedeutete das, dass in den frühen Morgenstunden langsam alles wieder zum Leben erwachte. Aber die Fragen bleiben.

Warum bauen wir Systeme immer noch um eine einzige Cloud-Region herum? Warum haben nicht mehr Unternehmen Multi-Cloud- oder zumindest Multi-Region-Failover-Strategien übernommen?

Die harte Wahrheit ist: Es ist kompliziert. Heiße Standbys über Regionen hinweg zu betreiben, ist nicht billig. Traffic um Ausfälle herumzuleiten, erfordert Infrastruktur, die sich nur wenige Unternehmen rechtfertigen können, wenn die Cloud „nur" alle paar Jahre einmal ausfällt. Wie ein Kommentar anmerkte: „Klingt großartig für die 34 Minuten im Jahr, in denen es dich trifft … nicht so sehr für die anderen 364 Tage, an denen du über Budget bist."

Die Illusion der Unbesiegbarkeit

AWS verkauft sich selbst über Uptime. 99,99999 % Verfügbarkeit. Mehrere Redundanzebenen. Und doch sehen wir immer wieder, wie zerbrechlich der Stack ist, wenn ein Zahnrad aus dem Tritt gerät.

Ein sarkastischer Kommentar traf die Stimmung perfekt: „Ja, sie verkaufen es uns, als wäre es unbesiegbar, während jede andere Cloud Kaugummi und Klebeband ist. Aber ich kann nicht mal meine Ring-Kamera stummschalten."

Das tiefere Problem? Es ist nicht nur AWS. Es ist unser kollektives Übervertrauen in Cloud-Resilienz, und unsere Neigung, zu viele Eier in einen virtuellen Korb zu legen.

Erkenntnisse, falls jemand zuhört

1. Diversifizieren Sie Ihre Infrastruktur, wenn Sie können. Im Ernst.
2. Gehen Sie nicht davon aus, dass Standardeinstellungen (wie das Deployment in us-east-1) sicher sind, nur weil sie beliebt sind.
3. Bauen Sie menschenbewusste DR-Strategien auf. Wissen Sie, was ausfällt, und wer informiert werden muss.
4. Wenn Sie im Bereitschaftsdienst sind, decken Sie sich mit Snacks ein.

Der Ausfall war ein Weckruf, nicht weil er katastrophal war, sondern weil er so gewöhnlich war. Er passierte nachts, während eines routinemäßigen Deployment-Fensters, und wurde innerhalb weniger Stunden behoben. Aber in diesem kleinen Fenster ließ er Millionen von Nutzern im Dunkeln zurück, von denen viele nicht einmal wussten, dass AWS hinter ihren Apps steckte, bis alles zusammenbrach.

Also ja. Wenn die Cloud zusammenbricht, spüren wir alle den Sturm.