Quand le cloud s'arrête: Relecture de la panne majeure d'AWS du 20 octobre 2025

Es war ein Montag, der vielen IT-Verantwortlichen noch lange in Erinnerung bleiben wird. Am 20. Oktober 2025 erlebte Amazon Web Services einen massiven Ausfall in der wichtigsten Region Nord-Virginia (US-EAST-1), der nicht nur zahlreiche Unternehmensanwendungen lahmlegte, sondern auch für absurde Auswirkungen sorgte: Selbst Besitzer vernetzter Matratzen bekamen die Folgen zu spüren. Nun hat Amazon einen detaillierten Post-Mortem-Bericht veröffentlicht, der zeigt, wie eine winzige Race-Condition in einer Kettenreaktion ein riesiges Cloud-System zum Stillstand bringen konnte.

Der Dominoeffekt: Drei Phasen des Chaos

Der Ausfall begann am Sonntagabend um 23:48 Uhr pazifischer Zeit (8:48 Uhr unserer Zeit am Montag) und zog sich in verschiedenen Ausprägungen bis zum Nachmittag hin. Amazon unterscheidet dabei drei Hauptphasen, die sich teilweise überlappten und gegenseitig verstärkten.

In der ersten Phase, die von 8:48 Uhr bis 11:40 Uhr dauerte, lieferte Amazons NoSQL-Datenbank DynamoDB massiv erhöhte Fehlerraten bei API-Zugriffen. Das allein wäre schon dramatisch genug gewesen, denn DynamoDB ist eine zentrale Komponente für unzählige AWS-Dienste. Aber es sollte noch schlimmer kommen.

Die zweite Phase entwickelte sich zwischen 14:30 Uhr und 23:09 Uhr: Der Network Load Balancer (NLB) begann, erhöhte Verbindungsfehler zu produzieren. Das lag an fehlgeschlagenen Health-Checks in der NLB-Flotte, die dazu führten, dass funktionierende Server aus dem Verkehr gezogen wurden, während defekte im System blieben.

Die dritte und für viele Nutzer vielleicht spürbarste Phase betraf das Starten neuer EC2-Instanzen. Von 11:25 Uhr bis 19:36 Uhr klappte das einfach nicht. Selbst als ab 19:37 Uhr wieder Instanzen anliefen, kämpften sie bis 22:50 Uhr mit Verbindungsproblemen.

Die Wurzel allen Übels: Eine heimtückische Race-Condition

Was war nun passiert? Amazon nennt es einen „latenten Defekt“ im automatischen DNS-Management-System von DynamoDB. Das klingt zunächst harmlos, hatte aber fatale Folgen. Um zu verstehen, was schiefgelaufen ist, muss man ein bisschen in die Architektur eintauchen.

Dienste wie DynamoDB verwalten Hunderttausende von DNS-Einträgen, um ihre riesige, heterogene Flotte von Load Balancern in jeder Region zu betreiben. Das DNS-System ermöglicht nahtlose Skalierbarkeit, Fehlerisolierung, niedrige Latenzen und lokale Zugriffe. Automatisierung ist dabei unverzichtbar, um zusätzliche Kapazitäten hinzuzufügen, Hardwarefehler zu behandeln und Traffic effizient zu verteilen.

Amazons DNS-Management-System für DynamoDB ist aus Verfügbarkeitsgründen in zwei unabhängige Komponenten aufgeteilt. Der „DNS Planner“ überwacht Gesundheit und Kapazität der Load Balancer und erstellt periodisch neue DNS-Pläne für jeden Endpunkt des Dienstes. Diese Pläne bestehen aus einer Sammlung von Load Balancern mit entsprechenden Gewichtungen. Der „DNS Enactor“ hingegen hat minimale Abhängigkeiten und setzt diese DNS-Pläne um, indem er die nötigen Änderungen in Amazon Route53 vornimmt. Für Resilienz läuft der DNS Enactor redundant und völlig unabhängig in drei verschiedenen Availability Zones.

Jede dieser unabhängigen Instanzen des DNS Enactors sucht nach neuen Plänen und versucht, Route53 durch Ersetzen des aktuellen Plans mit einem neuen Plan über eine Route53-Transaktion zu aktualisieren. Das stellt sicher, dass jeder Endpunkt mit einem konsistenten Plan aktualisiert wird, selbst wenn mehrere DNS Enactors gleichzeitig versuchen, Updates durchzuführen.

Und hier liegt das Problem: Die Race-Condition entstand durch eine unwahrscheinliche Interaktion zwischen zwei DNS Enactors. Normalerweise nimmt ein DNS Enactor den neuesten Plan und arbeitet die Service-Endpunkte durch, um diesen Plan anzuwenden. Bevor er einen neuen Plan anwendet, prüft er einmalig, ob sein Plan neuer ist als der zuvor angewendete Plan. Während er die Liste der Endpunkte durchgeht, kann es zu Verzögerungen kommen, wenn ein anderer DNS Enactor gerade denselben Endpunkt aktualisiert. In solchen Fällen versucht der DNS Enactor jeden Endpunkt erneut, bis der Plan erfolgreich auf alle Endpunkte angewendet wurde.

Kurz vor dem Ausfall erlebte ein DNS Enactor ungewöhnlich hohe Verzögerungen und musste seine Updates an mehreren DNS-Endpunkten wiederholt versuchen. Während er sich langsam durch die Endpunkte arbeitete, passierten gleichzeitig mehrere andere Dinge: Der DNS Planner lief weiter und produzierte viele neuere Generationen von Plänen. Ein anderer DNS Enactor begann dann, einen dieser neueren Pläne anzuwenden und kam rasch durch alle Endpunkte durch.

Das Timing dieser Ereignisse löste die latente Race-Condition aus. Als der zweite Enactor (der den neuesten Plan anwendete) seine Endpunkt-Updates abschloss, startete er den Plan-Aufräumprozess, der Pläne identifiziert, die deutlich älter sind als der gerade angewendete, und löscht sie. Genau zu diesem Zeitpunkt wendete der erste Enactor (der ungewöhnlich verzögert war) seinen viel älteren Plan auf den regionalen DynamoDB-Endpunkt an und überschrieb damit den neueren Plan. Die Prüfung zu Beginn des Plan-Anwendungsprozesses war aufgrund der ungewöhnlich hohen Verzögerungen inzwischen veraltet und verhinderte nicht, dass der ältere Plan den neueren überschrieb.

Der Aufräumprozess des zweiten Enactors löschte dann diesen älteren Plan, weil er viele Generationen älter war als der Plan, den er gerade angewendet hatte. Als dieser Plan gelöscht wurde, wurden alle IP-Adressen für den regionalen Endpunkt sofort entfernt. Zusätzlich wurde das System durch das Löschen des aktiven Plans in einen inkonsistenten Zustand versetzt, der verhinderte, dass nachfolgende Plan-Updates von irgendwelchen DNS Enactors angewendet werden konnten. Diese Situation erforderte letztendlich manuelle Eingriffe durch Operatoren.

Das Ergebnis? Der DNS-Eintrag für „dynamodb.us-east-1.amazonaws.com“ war plötzlich leer. Alle Systeme, die sich mit DynamoDB in Nord-Virginia verbinden wollten, liefen sofort gegen DNS-Fehler. Das betraf sowohl Kundentraffic als auch Traffic von internen AWS-Diensten, die auf DynamoDB angewiesen sind.

Die Folgen: Wenn die Infrastruktur kippt

Um 9:38 Uhr identifizierten die Techniker den Fehler im DNS-Management. Erste temporäre Gegenmaßnahmen griffen um 10:15 Uhr und ermöglichten einigen internen Diensten, sich wieder mit DynamoDB zu verbinden. Das war wichtig, um kritische interne Tools freizuschalten, die für die weitere Wiederherstellung nötig waren. Gegen 11:25 Uhr waren alle DNS-Informationen wiederhergestellt.

Doch damit war die Krise noch lange nicht vorbei. Die EC2-Instanzen wollten immer noch nicht starten. Der Grund lag im sogenannten DropletWorkflow Manager (DWFM), der für das Management aller zugrunde liegenden physischen Server verantwortlich ist, die EC2 für das Hosting von EC2-Instanzen nutzt. Amazon nennt diese Server intern „Droplets“.

Jeder DWFM verwaltet eine Reihe von Droplets innerhalb jeder Availability Zone und unterhält ein Lease für jedes Droplet, das aktuell unter seiner Verwaltung steht. Dieses Lease ermöglicht es dem DWFM, den Droplet-Status zu verfolgen und sicherzustellen, dass alle Aktionen von der EC2-API oder innerhalb der EC2-Instanz selbst, wie Shutdown- oder Reboot-Operationen, die vom Betriebssystem der EC2-Instanz ausgehen, zu den korrekten Statusänderungen in den breiteren EC2-Systemen führen. Als Teil dieser Lease-Verwaltung muss jeder DWFM-Host alle paar Minuten bei jedem Droplet, das er verwaltet, einchecken und einen Status-Check durchführen.

Dieser Prozess hängt aber von DynamoDB ab. Als DynamoDB nicht erreichbar war, begannen diese Status-Checks zu scheitern. Das betraf zwar keine laufenden EC2-Instanzen, bedeutete aber, dass das Droplet ein neues Lease mit einem DWFM etablieren musste, bevor weitere Instanz-Statusänderungen für die EC2-Instanzen, die es hostet, passieren konnten. Zwischen 23:48 Uhr und 2:24 Uhr begannen die Leases zwischen DWFM und Droplets in der EC2-Flotte langsam zu verfallen.

Als DynamoDB um 2:25 Uhr pazifischer Zeit (11:25 Uhr unserer Zeit) wieder verfügbar war, begann DWFM, Leases mit Droplets in der gesamten EC2-Flotte wiederherzustellen. Da jedes Droplet ohne aktives Lease nicht als Kandidat für neue EC2-Starts betrachtet wird, lieferten die EC2-APIs „insufficient capacity errors“ für neue eingehende EC2-Start-Anfragen zurück.

Hier kam es zu einem perfiden Problem: Aufgrund der großen Anzahl von Droplets dauerten die Versuche, neue Droplet-Leases zu etablieren, so lange, dass die Arbeit nicht abgeschlossen werden konnte, bevor sie erneut in Time-Outs liefen. Zusätzliche Arbeit wurde in die Warteschlange gestellt, um die Etablierung des Droplet-Lease erneut zu versuchen. An diesem Punkt war DWFM in einen Zustand der kongestiven Kollaps eingetreten und konnte bei der Wiederherstellung von Droplet-Leases keine Fortschritte mehr machen.

Da es für diese Situation kein etabliertes operatives Wiederherstellungsverfahren gab, gingen die Ingenieure vorsichtig vor, um das Problem mit DWFM zu lösen, ohne weitere Probleme zu verursachen. Nach mehreren Mitigationsversuchen drosselten die Ingenieure um 4:14 Uhr pazifischer Zeit die eingehende Arbeit und begannen mit selektiven Neustarts von DWFM-Hosts. Das Neustarten der DWFM-Hosts räumte die DWFM-Warteschlangen auf, reduzierte die Verarbeitungszeiten und ermöglichte die Etablierung von Droplet-Leases. Um 5:28 Uhr hatte DWFM Leases mit allen Droplets in der Region Nord-Virginia etabliert, und neue Starts begannen wieder zu gelingen, obwohl viele Anfragen aufgrund der eingeführten Request-Drosselung noch „request limit exceeded“ Fehler sahen.

Der Network Manager: Wenn die Vernetzung hinterherhinkt

Doch auch damit waren die Probleme noch nicht vorbei. Wenn eine neue EC2-Instanz gestartet wird, propagiert ein System namens Network Manager die Netzwerkkonfiguration, die der Instanz erlaubt, mit anderen Instanzen innerhalb derselben Virtual Private Cloud (VPC), anderen VPC-Netzwerkgeräten und dem Internet zu kommunizieren.

Um 5:28 Uhr pazifischer Zeit (14:28 Uhr unserer Zeit), kurz nach der Wiederherstellung von DWFM, begann der Network Manager, aktualisierte Netzwerkkonfigurationen an neu gestartete Instanzen und Instanzen zu propagieren, die während des Ereignisses beendet worden waren. Da diese Netzwerk-Propagationsereignisse durch das Problem mit DWFM verzögert worden waren, musste ein erheblicher Rückstau von Netzwerkstatus-Propagationen vom Network Manager in der Region Nord-Virginia verarbeitet werden.

Infolgedessen begann der Network Manager um 6:21 Uhr, erhöhte Latenzen bei den Netzwerk-Propagationszeiten zu erleben, während er daran arbeitete, den Rückstau der Netzwerkstatusänderungen zu verarbeiten. Während neue EC2-Instanzen erfolgreich gestartet werden konnten, hatten sie aufgrund der Verzögerungen bei der Netzwerkstatus-Propagation nicht die notwendige Netzwerkanbindung. Die Ingenieure arbeiteten daran, die Last auf dem Network Manager zu reduzieren, um die Propagationszeiten der Netzwerkkonfiguration anzugehen, und ergriffen Maßnahmen, um die Wiederherstellung zu beschleunigen. Um 10:36 Uhr waren die Propagationszeiten der Netzwerkkonfiguration auf normale Werte zurückgekehrt, und neue EC2-Instanz-Starts funktionierten wieder normal.

Network Load Balancer: Das Gesundheitssystem wird krank

Die Verzögerungen bei den Netzwerkstatus-Propagationen für neu gestartete EC2-Instanzen verursachten auch Auswirkungen auf den Network Load Balancer (NLB) Service und AWS-Dienste, die NLB nutzen. Zwischen 5:30 Uhr und 2:09 Uhr pazifischer Zeit am 20. Oktober erlebten einige Kunden erhöhte Verbindungsfehler bei ihren NLBs in der Region Nord-Virginia.

NLB ist auf einer hochskalierbaren, mandantenfähigen Architektur aufgebaut, die Load-Balancing-Endpunkte bereitstellt und Traffic zu Backend-Zielen routet, die typischerweise EC2-Instanzen sind. Die Architektur nutzt auch ein separates Health-Check-Subsystem, das regelmäßig Health-Checks gegen alle Knoten innerhalb der NLB-Architektur ausführt und alle Knoten aus dem Service entfernt, die als ungesund betrachtet werden.

Während des Ereignisses begann das NLB-Health-Checking-Subsystem, erhöhte Health-Check-Fehler zu erleben. Dies wurde dadurch verursacht, dass das Health-Checking-Subsystem neue EC2-Instanzen in Betrieb nahm, während der Netzwerkstatus für diese Instanzen noch nicht vollständig propagiert war. Das bedeutete, dass in einigen Fällen Health-Checks fehlschlugen, obwohl der zugrunde liegende NLB-Knoten und die Backend-Ziele gesund waren. Dies führte dazu, dass Health-Checks zwischen fehlgeschlagen und gesund wechselten. Das verursachte, dass NLB-Knoten und Backend-Ziele aus dem DNS entfernt wurden, nur um beim nächsten erfolgreichen Health-Check wieder in Betrieb genommen zu werden.

Die alternierenden Health-Check-Ergebnisse erhöhten die Last auf dem Health-Check-Subsystem und verursachten dessen Degradierung, was zu Verzögerungen bei Health-Checks führte und automatische AZ-DNS-Failover auslöste. Bei Multi-AZ-Load-Balancern führte dies dazu, dass Kapazität aus dem Service genommen wurde. In diesem Fall erlebte eine Anwendung erhöhte Verbindungsfehler, wenn die verbleibende gesunde Kapazität unzureichend war, um die Anwendungslast zu tragen.

Um 9:36 Uhr deaktivierten die Ingenieure automatische Health-Check-Failover für NLB, wodurch alle verfügbaren gesunden NLB-Knoten und Backend-Ziele wieder in Betrieb genommen werden konnten. Dies löste die erhöhten Verbindungsfehler zu betroffenen Load Balancern. Kurz nachdem EC2 sich erholt hatte, aktivierten sie automatisches DNS-Health-Check-Failover um 2:09 Uhr pazifischer Zeit wieder.

Die Auswirkungen: Ein Rattenschwanz von Problemen

Der DynamoDB-Ausfall und die daraus resultierenden Probleme hatten weitreichende Folgen für zahlreiche andere AWS-Services. Lambda-Funktionen lieferten zwischen 23:51 Uhr am 19. Oktober und 2:15 Uhr pazifischer Zeit am 20. Oktober API-Fehler und Latenzen. Zunächst verhinderten die DynamoDB-Endpunkt-Probleme die Erstellung und Aktualisierung von Funktionen, verursachten Verarbeitungsverzögerungen für SQS/Kinesis-Ereignisquellen und Aufruffehler.

Amazon Elastic Container Service (ECS), Elastic Kubernetes Service (EKS) und Fargate erlebten zwischen 23:45 Uhr am 19. Oktober und 2:20 Uhr pazifischer Zeit am 20. Oktober Container-Start-Fehler und Cluster-Skalierungsverzögerungen.

Amazon Connect-Kunden erlebten zwischen 23:56 Uhr am 19. Oktober und 1:20 Uhr pazifischer Zeit am 20. Oktober erhöhte Fehler bei der Bearbeitung von Anrufen, Chats und Fällen. Eingehende Anrufer hörten Besetztzeichen, Fehlermeldungen oder erlebten fehlgeschlagene Verbindungen. Sowohl von Agenten initiierte als auch API-initiierte ausgehende Anrufe schlugen fehl.

Der AWS Security Token Service (STS) erlebte am 19. Oktober zwischen 23:51 Uhr und 9:59 Uhr pazifischer Zeit API-Fehler und Latenz. Kunden, die versuchten, sich mit einem IAM-Benutzer in der AWS Management Console anzumelden, erlebten zwischen 23:51 Uhr am 19. Oktober und 1:25 Uhr pazifischer Zeit am 20. Oktober erhöhte Authentifizierungsfehler aufgrund zugrunde liegender DynamoDB-Probleme.

Amazon Redshift-Kunden erlebten zwischen 23:47 Uhr am 19. Oktober und 2:21 Uhr pazifischer Zeit am 20. Oktober API-Fehler beim Erstellen und Ändern von Redshift-Clustern oder beim Ausführen von Abfragen gegen bestehende Cluster. Interessanterweise waren Redshift-Kunden in allen AWS-Regionen zwischen 23:47 Uhr am 19. Oktober und 1:20 Uhr am 20. Oktober nicht in der Lage, IAM-Benutzer-Credentials für das Ausführen von Abfragen zu verwenden, da ein Redshift-Defekt eine IAM-API in der Region Nord-Virginia verwendete, um Benutzergruppen aufzulösen.

Die Lehren: Was Amazon jetzt ändert

Amazon hat bereits mehrere Maßnahmen ergriffen und plant weitere Änderungen, um eine Wiederholung zu verhindern. Der DynamoDB DNS Planner und der DNS Enactor wurden weltweit deaktiviert. Bevor diese Automatisierung wieder aktiviert wird, wird Amazon das Race-Condition-Szenario beheben und zusätzliche Schutzmaßnahmen hinzufügen, um die Anwendung falscher DNS-Pläne zu verhindern.

Für den Network Load Balancer wird ein Geschwindigkeitskontrollmechanismus hinzugefügt, der die Kapazität begrenzt, die ein einzelner NLB entfernen kann, wenn Health-Check-Fehler einen AZ-Failover verursachen. Das soll verhindern, dass zu viel Kapazität auf einmal aus dem Verkehr gezogen wird.

Für EC2 baut Amazon eine zusätzliche Test-Suite auf, um die bestehenden Skalierungstests zu ergänzen. Diese wird den DWFM-Wiederherstellungs-Workflow durchspielen, um zukünftige Regressionen zu identifizieren. Außerdem wird der Drosselungsmechanismus in den EC2-Daten-Propagationssystemen verbessert, um eingehende Arbeit basierend auf der Größe der Warteschlange zu begrenzen und den Service während Perioden hoher Last zu schützen.

Fazit: Wenn Redundanz nicht reicht

Dieser Ausfall zeigt eindrucksvoll, wie komplex moderne Cloud-Infrastrukturen sind und wie eine scheinbar kleine Schwachstelle – eine Race-Condition, die unter normalen Umständen wahrscheinlich nie auftritt – zu einer Kaskade von Ausfällen führen kann. Trotz aller Redundanzen, trotz dreifach ausgelegter DNS Enactors in verschiedenen Availability Zones, trotz ausgefeilter Automatisierung konnte ein unglückliches Timing das gesamte System zum Einsturz bringen.

Amazon betont in seinem Abschlussbericht, dass man sich für die Auswirkungen auf die Kunden entschuldigt. Man wisse, wie kritisch die Services für Kunden, ihre Anwendungen, Endnutzer und ihre Geschäfte seien. Man werde alles tun, um aus diesem Ereignis zu lernen und es zu nutzen, um die Verfügbarkeit noch weiter zu verbessern.

Für uns als Nutzer bleibt die Erkenntnis: Die Cloud mag robust sein, aber sie ist nicht unfehlbar. Multi-Region-Strategien, Disaster-Recovery-Pläne und Fallback-Mechanismen sind keine Paranoia, sondern Notwendigkeit. Und manchmal ist es eben doch die vernetzte Matratze, die uns daran erinnert, wie abhängig wir von dieser unsichtbaren Infrastruktur geworden sind.