Der AWS-Ausfall vom 20. Oktober 2025
Was Unternehmen aus dem größten Cloud-Ausfall des Jahres lernen können
Race Conditions: Wenn sich Systeme selbst blockieren
Am 20. Oktober 2025 stand das Internet still – zumindest gefühlt. Von Fortnite bis Zoom, von Signal bis Amazon: Ein Ausfall bei Amazon Web Services (AWS) legte große Teile des Internets lahm. Nach stundenlangen Störungen laufen seit Dienstag wieder alle Dienste. Aber was genau ist passiert? Und was können wir daraus lernen?
Sven Köhler, Sales Account Executive für das AWS-Geschäft bei eggs unimedia, und Simon Bönisch, Product Owner und Hauptverantwortlicher für die technische Seite des AWS Geschäftsfelds, haben den Vorfall in einem Videocall analysiert und eingeordnet. Das Gespräch zwischen dem Vertriebsexperten und dem technischen Lead bietet einen seltenen Einblick in die Komplexität moderner Cloud-Infrastrukturen – und zeigt, warum selbst die besten Systeme nicht vor Ausfällen gefeit sind.
Das vollständige Gespräch als Video
Die Analyse in Textform
Sven: Simon, plötzlich ging nichts mehr – von Fortnite bis Zoom. Ein Ausfall bei AWS legte große Teile des Internets lahm. Nach stundenlangen Störungen am Montag laufen alle Dienste am Dienstag wieder, titelt das Handelsblatt. Was ist passiert? War es, wie viele schreiben, wirklich ein Security-Vorfall? Wurde AWS gehackt?
Simon: Nein, es war kein Angriff. Das Gerücht ging zwar relativ schnell rum, aber es gibt inzwischen ein Postmortem von AWS, in dem sie detailliert erklären, was passiert ist. Es handelte sich um eine Race Condition im DNS-System – genauer gesagt in einem automatisierten System. Zwei Prozesse haben gleichzeitig versucht, Änderungen vorzunehmen, und dabei sind die internen DNS-Einträge verloren gegangen. Die Tabelle war plötzlich leer. DNS ist das Adresssystem in der Netzwerktechnik, und ohne diese Adressen wussten die Server und Anwendungen nicht mehr, wie sie miteinander kommunizieren sollten.
Sven: Race Condition – was ist das nochmal genau? Und kann das öfter passieren?
Simon: Eine Race Condition entsteht, wenn zwei Prozesse gleichzeitig Dinge in verschiedenen Regionen tun und sich gegenseitig in die Quere kommen. Das ist eigentlich ein Ausfallsicherheitsthema. In diesem Fall hatte das zur Folge, dass das Adressbuch plötzlich leer war. AWS hat die Automatik sofort deaktiviert und baut jetzt zusätzliche Sicherungen ein, damit so etwas nicht mehr vorkommen kann. Solche Fehler sind extrem schwer zu finden und zu debuggen, weil sie nur unter ganz bestimmten Bedingungen auftreten.
Sven: Welche Services waren betroffen?
Simon: Der primär betroffene Service war DynamoDB, ein Datenbank-Service bei AWS, der auch intern von AWS selbst verwendet wird. Das war das eigentliche Problem – eine Kaskade. Nachdem DynamoDB ausgefallen war, waren auch EC2 und Lambda betroffen. Das sind sehr zentrale Services für virtualisierte Server und die Ausführung von serverlosem Code. Der eigentliche Ausfall bei DynamoDB dauerte nur etwa eineinhalb Stunden, bis sie das DNS-Problem im Griff hatten. Aber dann brauchte es noch Zeit, bis alle abhängigen Services wieder liefen.
Sven: Also diese Kettenreaktion hat es dann am Ende so lange dauern lassen?
Simon: Genau. EC2 und Lambda verwenden intern auch eine Datenbank, und das war in diesem Fall DynamoDB. Als die weg war, liefen Warteschlangen voll und Caches über. Dann muss man meistens manuell eingreifen. Du hast vielleicht gelesen, dass zum Beispiel Messenger wie Signal ausgefallen waren. Die User versuchen dann ständig, sich einzuloggen, was zu einer Request-Flut führt. Da braucht es manuelle Intervention, um die Requests zu blocken und das System langsam wieder hochzufahren.
Sven: Warum hat DynamoDB einen so kritischen Stellenwert, dass beim Ausfall alles den Bach runtergeht?
Simon: DynamoDB wird von Management-Services verwendet. EC2 muss intern ein paar Sachen in der Datenbank speichern, genauso Lambda und das API Gateway. Verschiedene AWS-Services nutzen es, und die werden wiederum von anderen Services verwendet. Die Systemkomplexität ist in diesen riesigen Cloud-Systemen einfach extrem hoch. Wenn ein Teil ausfällt und alle voneinander abhängen, kaskadiert das durch das ganze System. Das ist auch bei kleineren Anwendungen so – wir kennen das aus der eigenen Entwicklung. Aber je größer und komplexer das System ist, desto schwieriger können solche Probleme werden.
Sven: Kann passieren, sollte aber wahrscheinlich nicht, oder? Die Häme gegenüber AWS ist ziemlich groß. Wie sieht es denn bei anderen Cloud-Anbietern aus? Kann da auch was passieren?
Simon: Kann passieren, sollte nicht – das stimmt. Aber es lässt sich bei so super komplexen Systemen eigentlich kaum vermeiden, dass mal so etwas vorkommt. In diesem Fall war es nicht einmal ein menschlicher Fehler, sondern diese Race Condition – zwei Systeme, die parallel arbeiten und dann miteinander konkurrieren. Das sind Fehler, die extrem schwer zu finden sind.
Wichtig ist, dass die jeweiligen Anbieter saubere Prozesse in der Hinterhand haben, um darauf zu reagieren. Und da ist AWS durch die lange Erfahrung und dieses Riesensystem, das sie seit vielen Jahren betreiben, eigentlich relativ führend. Sie haben sehr schnell reagiert, sauber kommuniziert, das Ganze transparent gestaltet und innerhalb von einigen Stunden wieder im Griff gehabt. Wenn man sich die technischen Details anschaut, ist das durchaus beeindruckend.
Gerade für uns als Partner sind solche Ausfälle auch interessant. Es gibt dann diese Post-Event-Summaries von AWS, in denen sie sehr detailliert erklären, was passiert ist. Das ist immer lehrreich, wenn man Einblick in die Architektur bekommt und sieht, wie so ein riesiges System betrieben wird.
Sven: Was können wir persönlich daraus lernen? Gibt es Dinge, die wir jetzt anders machen sollten?
Simon: Was man daraus lernen kann, ist, dass Architekturgrundlagen wie Hochverfügbarkeit und Multi-Region-Deployment sehr gute Gründe haben. Es kann immer mal wieder etwas passieren. In diesem Fall war hauptsächlich die Region US-East-1 betroffen. Wenn man eine Webanwendung ausschließlich in dieser Region betrieben hätte, wäre das Problem noch größer gewesen. Natürlich hat es auch global kaskadiert, weil US-East-1 eine sehr zentrale Region für die internen Amazon-Services ist. Das zeigt wieder, dass Themen wie Resilienz in der Anwendungsplanung und im Betrieb berücksichtigt werden sollten.
Sven: Gibt es auch Kritikpunkte gegenüber AWS?
Simon: Die allgemeine Kritik ist natürlich die starke Abhängigkeit von solchen Systemen in der modernen Welt. Das ist ein Problem. Persönlich glaube ich aber nicht, dass man dem durch europäische Cloud-Anbieter entgeht. Die werden früher oder später die gleichen Probleme haben, weil auch sie irgendwann sehr komplexe Systeme betreiben.
Man kann beim Design der Produkte darauf achten. Ich habe gelesen, es war kurios: Luxusmatratzen, die automatisch die Temperatur regeln, sind ausgefallen, weil sie eine dauerhafte Internetverbindung brauchten. Teilweise blieben sie bei 40 Grad stehen. Oder Betten, die hochgefahren sind, um Schnarchen zu verhindern – und dann ist die Cloud ausgefallen, und das Bett ließ sich nicht mehr zurückfahren. Auf so etwas sollte man beim Produktdesign achten. Aber ansonsten glaube ich, dass man um solche Ausfälle nicht herumkommt.
Sven: Jetzt weiß ich, warum ich so unruhig geschlafen habe in der Nacht! Vielen Dank für die Einordnung, Simon.
Fazit: Resilienz statt Perfektion
Der AWS-Ausfall vom 20. Oktober 2025 zeigt: Auch die besten Systeme sind nicht unfehlbar. Eine Race Condition, ein seltener technischer Fehler, hat ausgereicht, um weltweit Dienste lahmzulegen. Die wichtigste Erkenntnis: Es geht nicht darum, Ausfälle komplett zu vermeiden, sondern darum, sie zu begrenzen und schnell darauf zu reagieren. Multi-Region-Architekturen, Abhängigkeiten diversifizieren und eine disziplinierte Incident-Readiness sind der Weg nach vorne.
Für uns bei eggs unimedia ist klar: Mit unserer langjährigen AWS-Expertise und unserer Projekterfahrung sind wir bestens aufgestellt, um Kunden durch solche Situationen zu begleiten und resiliente Cloud-Architekturen zu entwickeln.
