Zusammenfassung des Ausfalls des Amazon-DynamoDB-Dienstes in der Region US East (Nord-Virginia, us-east-1)

• Am 19.–20. Oktober 2025 kam es in der AWS-Region N. Virginia (us-east-1) bei Amazon DynamoDB und mehreren weiteren Kerndiensten zu einem lang andauernden Ausfall
• Der Ausfall begann, als durch eine latente Race Condition im automatischen DNS-Verwaltungssystem von DynamoDB fälschlich ein leerer DNS-Record erzeugt wurde
• In der Folge kam es kaskadenartig zu Fehlschlägen bei der Erstellung von EC2-Instanzen, Verbindungsfehlern bei Network Load Balancer (NLB) sowie API-Latenzen und -Fehlern bei zahlreichen Diensten wie Lambda, ECS und Redshift
• AWS identifizierte die Ursache als Konflikt durch anomale gleichzeitige Updates zwischen DynamoDB DNS Enactors und stellte den Betrieb nach manueller Wiederherstellung am 20. Oktober gegen 14:20 Uhr vollständig wieder her
• Der Vorfall zeigte die Komplexität der wechselseitigen Abhängigkeiten zwischen internen AWS-Automatisierungssystemen und kündigt strukturelle Verbesserungen zur Stärkung der Resilienz von DNS, EC2 und NLB an

---

Überblick über den Vorfall

• Der Ausfall begann am 19. Oktober 2025 um 23:48 Uhr (PDT) und endete am 20. Oktober um 14:20 Uhr (PDT)
  • Es gab drei wesentliche Phasen mit größeren Auswirkungen:
    1. 19. Oktober 23:48 Uhr bis 20. Oktober 02:40 Uhr: starker Anstieg der Fehlerquote der DynamoDB-API
    2. 20. Oktober 05:30 Uhr bis 14:09 Uhr: Zunahme von NLB-Verbindungsfehlern
    3. 20. Oktober 02:25 Uhr bis 10:36 Uhr: Fehlschläge bei der Erstellung neuer EC2-Instanzen und Probleme bei der Netzwerkverbindung
• Der Vorfall begann mit einem Fehler im DNS-Verwaltungssystem von DynamoDB und breitete sich auf zahlreiche Dienste wie EC2, NLB, Lambda und Redshift aus

Ursache und Auswirkungen des DynamoDB-Ausfalls

• Ein latenter Fehler im automatischen DNS-Verwaltungssystem von DynamoDB wurde ausgelöst, wodurch der DNS-Record für dynamodb.us-east-1.amazonaws.com fälschlich in einen leeren Zustand aktualisiert wurde
  • Das System ist in zwei Komponenten aufgeteilt:
    • DNS Planner: überwacht den Status des Load Balancers und erstellt neue DNS-Pläne
    • DNS Enactor: wendet Änderungen in Route53 an
• Zwischen den in drei Availability Zones (AZs) unabhängig bereitgestellten DNS Enactors trat eine Race Condition auf
  • Der erste Enactor wendete in verzögertem Zustand einen veralteten Plan an
  • Nachdem der zweite Enactor den neuesten Plan angewendet hatte, löschte er den alten Plan, wodurch alle IP-Adressen entfernt wurden und das System in einen inkonsistenten Zustand überging
  • Da die automatische Wiederherstellung fehlschlug, war ein manueller Eingriff erforderlich
• Unmittelbar nach Beginn des Ausfalls um 23:48 Uhr scheiterten Verbindungen für alle Dienste und Kunden-Traffic, die von DynamoDB abhingen
  • Kunden mit Global Tables konnten Anfragen an Replikate in anderen Regionen senden, jedoch trat Replikationsverzögerung auf
• Um 00:38 Uhr bestätigten AWS-Ingenieure den DNS-Zustand als Ursache des Problems
  • Um 01:15 Uhr stellte eine temporäre Wiederherstellungsmaßnahme die Verbindung einiger interner Dienste wieder her
  • Um 02:25 Uhr waren die DNS-Informationen vollständig wiederhergestellt, um 02:40 Uhr normalisierten sich alle Verbindungen

Auswirkungen auf Amazon EC2 und Ablauf der Wiederherstellung

• Zwischen dem 19. Oktober 23:48 Uhr und dem 20. Oktober 13:50 Uhr kam es zu erhöhten EC2-API-Fehlerraten, Fehlschlägen bei der Instanzerstellung und steigenden Latenzen
  • Bereits laufende Instanzen waren nicht betroffen
• Für die Verwaltung von EC2-Instanzen werden zwei Subsysteme verwendet: DropletWorkflow Manager (DWFM) und Network Manager
  • DWFM verwaltet den Zustand physischer Server („droplets“) und führt periodische Statusprüfungen durch
  • Der Network Manager propagiert die Netzwerkkonfiguration von Instanzen
• Durch den DynamoDB-Ausfall schlugen die Statusprüfungen von DWFM fehl, wodurch Droplet-Leases abliefen
  • Nach der Wiederherstellung von DynamoDB um 02:25 Uhr versuchte DWFM die Wiederverbindung, jedoch kam es aufgrund der großen Zahl an Droplets zu einem Congestive Collapse
  • Um 04:14 Uhr starteten Ingenieure ausgewählte DWFM-Hosts gezielt neu, um die Queues zu bereinigen und die Wiederherstellung voranzubringen
  • Um 05:28 Uhr waren alle Droplet-Leases wiederhergestellt und die Erstellung neuer Instanzen wurde fortgesetzt
• Anschließend kam es während der Abarbeitung des Rückstaus bei der verzögerten Netzwerkstatus-Propagation durch den Network Manager zu Verzögerungen bei der Netzwerkverbindung
  • Um 10:36 Uhr normalisierte sich die Netzwerk-Propagationszeit
  • Um 11:23 Uhr begann die Lockerung des Throttling, um 13:50 Uhr war EC2 vollständig wiederhergestellt

Auswirkungen auf Network Load Balancer (NLB)

• Zwischen dem 20. Oktober 05:30 Uhr und 14:09 Uhr verzeichneten einige Kunden vermehrte NLB-Verbindungsfehler
  • NLB ist als Multi-Tenant-Architektur aufgebaut und leitet Traffic an Backend-EC2-Instanzen weiter
• Ursache waren fehlgeschlagene Health Checks infolge verzögerter Propagation des Netzwerkstatus
  • Da die Netzwerkkonfiguration neu hinzugefügter EC2-Instanzen nicht abgeschlossen war, schlugen Health Checks fehl
  • Die instabil schwankenden Ergebnisse führten dazu, dass NLB-Knoten aus dem DNS entfernt und später wieder aufgenommen wurden
• Um 06:52 Uhr erkannte das Monitoring-System das Problem, woraufhin Ingenieure mit der Reaktion begannen
  • Durch die erhöhte Last auf das Health-Check-Subsystem wurde ein automatisches AZ-DNS-Failover ausgelöst
  • Um 09:36 Uhr wurden durch Deaktivierung des automatischen Failovers alle gesunden Knoten wiederhergestellt
  • Um 14:09 Uhr wurde nach der EC2-Wiederherstellung das automatische Failover erneut aktiviert

Auswirkungen auf weitere AWS-Dienste

• AWS Lambda:
  • Zwischen dem 19. Oktober 23:51 Uhr und dem 20. Oktober 14:15 Uhr traten API-Fehler und Latenzen auf
  • Durch den DynamoDB-Ausfall schlugen Erstellung und Aktualisierung von Funktionen fehl, und die Verarbeitung von SQS-/Kinesis-Ereignissen verzögerte sich
  • Um 07:04 Uhr führte das Fehlschlagen von NLB-Health-Checks zu einer Verkleinerung interner Systeme und zur Begrenzung asynchroner Aufrufe
  • Um 14:15 Uhr waren alle Backlogs abgearbeitet und der Normalzustand wiederhergestellt
• ECS, EKS, Fargate:
  • Zwischen dem 19. Oktober 23:45 Uhr und dem 20. Oktober 14:20 Uhr traten Fehlschläge beim Starten von Containern sowie Verzögerungen bei der Cluster-Skalierung auf
• Amazon Connect:
  • Zwischen dem 19. Oktober 23:56 Uhr und dem 20. Oktober 13:20 Uhr traten Fehler bei Anrufen, Chats und Case-Verarbeitung auf
  • Nach der Wiederherstellung von DynamoDB funktionierten die meisten Features wieder normal, jedoch traten ab 07:04 Uhr durch die Auswirkungen auf NLB und Lambda erneut Fehler auf
  • Um 13:20 Uhr war der Dienst vollständig wiederhergestellt
• AWS STS:
  • Zwischen dem 19. Oktober 23:51 Uhr und dem 20. Oktober 09:59 Uhr traten Fehler und Latenzen bei der Authentifizierungs-API auf
  • Nach der Wiederherstellung von DynamoDB normalisierte sich der Dienst kurzzeitig, bevor durch die NLB-Probleme erneut Fehler auftraten
• IAM-Anmeldung und Identity Center:
  • Zwischen dem 19. Oktober 23:51 Uhr und dem 20. Oktober 01:25 Uhr stieg die Zahl der Authentifizierungsfehler
  • Nach der Wiederherstellung von DynamoDB normalisierte sich der Dienst
• Amazon Redshift:
  • Zwischen dem 19. Oktober 23:47 Uhr und dem 20. Oktober 02:21 Uhr schlugen Abfragen und Cluster-Änderungen fehl
  • Nach der Wiederherstellung von DynamoDB waren einige Cluster aufgrund der EC2-Störung weiterhin beeinträchtigt
  • Um 04:05 Uhr am 21. Oktober war der Dienst vollständig wiederhergestellt
  • Aufgrund der Abhängigkeit von der IAM-API kam es auch in Global Regions vorübergehend zu Query-Fehlern
• Weitere Dienste:
  • Auch Managed Workflows for Apache Airflow, Outposts, AWS Support Center und weitere Dienste waren betroffen

Nachbereitung und Verbesserungspläne

• Die gesamte Automatisierung von DynamoDB DNS Planner und Enactor wurde deaktiviert; vor einer Reaktivierung sollen die Race Condition behoben und zusätzliche Schutzmechanismen ergänzt werden
• NLB: Einführung eines Rate-Control-Mechanismus, der die Kapazität begrenzt, die ein einzelner NLB bei fehlgeschlagenen Health Checks entfernen kann
• EC2:
  • Aufbau einer neuen Test-Suite, die auch Wiederherstellungs-Workflows für DWFM umfasst
  • Verbesserung des Smart Throttling im Daten-Propagationssystem, einschließlich einer an der Größe der Warteschlange orientierten Begrenzung von Anfragen
• AWS prüft zusätzlich über eine Analyse der gegenseitigen Abhängigkeiten aller Dienste hinweg weitere Maßnahmen zur Verkürzung der Wiederherstellungszeit und zur Vermeidung ähnlicher Vorfälle

Fazit und Entschuldigung

• AWS entschuldigte sich offiziell für die Auswirkungen dieses Vorfalls auf Kunden
• Das Unternehmen erklärte, seine Dienste hätten bislang eine hohe Verfügbarkeit aufrechterhalten, räumte jedoch ein, dass dieser Ausfall erhebliche Auswirkungen auf die Geschäfte der Kunden hatte
• AWS versprach, die Resilienz der Automatisierungssysteme sowie die Verfahren zur Störungsbehebung anhand der Lehren aus diesem Vorfall zu stärken

[shakespeares]

Man sagt, das sei die Nachwirkung davon, dass sie die Seniors entlassen haben … stimmt das?

[GN⁺]

Hacker-News-Kommentare

• Ich bin bei diesem Thema immer derjenige, der dasselbe wiederholt. Wenn du Richard Cooks Text noch nicht gelesen hast, dann halte bei diesem Postmortem kurz an und lies zuerst How Complex Systems Fail. Das ist einer der besten technischen Texte über das Scheitern komplexer Systeme. Cook lehnt schon das Konzept einer „root cause“ ab, und ich denke, dass er auch in diesem Fall recht hat

  • Cooks Text ist gut, fühlt sich aber im Grunde wie eine Auflistung intuitiver Behauptungen an. Um ihn wirklich tief zu verstehen, müsste man wohl die gesamte Literatur dazu lesen. Im MIT-Systemkurs 6.033 liest man zu ähnlichen Themen auch die Arbeit von 1962 und einen anderen klassischen Aufsatz. Ich denke, solche Probleme erreichen letztlich die Komplexität eines „Wicked Problem“
  • Besonders eindrucksvoll an Cooks Text fand ich die Stelle, dass Versuche, ein System nach einem Vorfall „sicherer“ zu machen, die Sicherheit sogar verringern können. Maßnahmen zur Vermeidung menschlicher Fehler erhöhen die Kopplung und Komplexität des Systems, schaffen mehr potenzielle Fehlerstellen und machen Erkennung und Eindämmung schwieriger – das hat bei mir besonders Resonanz ausgelöst
  • Eine andere Perspektive bietet die Theorie der „Normal Accidents“. Je stärker Komponenten gekoppelt sind, je komplexer ihre Wechselwirkungen und je gravierender die Folgen von Ausfällen, desto gefährlicher ist ein System inhärent. Siehe Normal Accidents Wiki
  • Ich habe nicht beide Dokumente vollständig gelesen, stimme aber der Behauptung nicht zu, dass man allein wegen der Komplexität eines Systems keine root cause eines Ausfalls benennen könne. Im Sport ist ein Tor auch das Ergebnis vieler Faktoren, und trotzdem gibt es am Ende einen „Torschützen“. Ein breiter Blick ist gut, aber das Benennen der Kernursache ist ebenfalls praktisch
  • Ich bin ein Vertragsarbeiter im On-Call-Dienst. Die meisten Unternehmen nehmen On-Call nicht ernst. Es gibt zu wenig Dokumentation, und man bekommt keine Zeit, um den komplexen Code anderer Leute zu lesen. Ich würde gern einmal eine Kultur wie bei AWS erleben, in der On-Call als Teil von Lernen und Verantwortung verstanden wird

• Das Internet verwandelt sich immer mehr in ein zentralisiertes Mononetz. Das Internet, das im Kalten Krieg als verteiltes Netzwerk entstand, ist heute so aufgebaut, dass ein einziger Fehler bei einem Deployment Banken, Handel und Reisen weltweit lahmlegen kann. Die Cloud-Metapher ist längst über ihre Grenzen hinaus strapaziert.
  Für Startups oder F&E ist sie weiterhin nützlich, aber Unternehmen in der Wachstumsphase oder Behörden sollten eigene Server, eine eigene Cloud und eigene Kerndienste haben. An Technologie und Personal mangelt es nicht

• Beeindruckend am AWS-Postmortem fand ich die präzise Visualisierung der Zeitleiste. Wie im legendären GDC-Vortrag „I Shot You First“ war es nützlich, den Zeitverlauf mit schrägen Pfeilen darzustellen und zu fragen: „Wo genau ist die Verzögerung entstanden?“
  Noch mehr überrascht hat mich allerdings, dass es für den EC2-Node-Lease-Management-Service kein Runbook für die Wiederherstellung gab. Bei einem AWS-Kerndienst hätte ich erwartet, dass nahezu jede Ausnahmesituation vorbereitet ist

  • So etwas sollte man nicht als etwas Beängstigendes sehen, sondern als inhärentes Muster komplexer Systeme. Potenzielle Fehler existieren fraktal, und es ist unmöglich, für jede denkbare Konstellation ein Runbook zu haben

• Der Kern dieses Vorfalls wirkt wie eine Variante des Cache-Invalidation-Problems in DNS-Systemen. Zwei DNS-Enactors haben Pläne zu unterschiedlichen Zeitpunkten angewendet, wodurch eine Race Condition entstand und ein veralteter Plan den neueren überschrieb

  • Das ist nur eine Erklärung für die Öffentlichkeit; intern folgen nach der Behebung des Vorfalls Bewertung der Wiederholungswahrscheinlichkeit und Erstellung von Gegenmaßnahmen/Runbooks. Danach geht das Lernen und Teilen auf Organisationsebene weiter
  • Ich halte diese Race Condition selbst für die root cause. Ohne genau diesen Bug hätte es den Vorfall nicht gegeben
  • Ich frage mich, warum DNS Planner und Enactor getrennt wurden. Wäre es ein einzelner Dienst gewesen, wäre dieser Konkurrenzzustand vielleicht deutlicher sichtbar gewesen. Möglich, dass das Ergebnis eines übermäßigen Einsatzes von Microservices ist, der die Komplexität erhöht hat
  • Ich hatte einmal ein ähnliches Problem; dort waren JVM-GC-Verzögerungen und defekte Hardware die Ursache. So etwas könnte auch hier eine Rolle gespielt haben
  • AWS hat allerdings nicht klar benannt, welche Präventionsmaßnahmen greifen, falls solche Verzögerungen erneut auftreten

• Der Enactor hätte vor dem Anwenden neuer Werte einen Versionsvergleich des aktuellen Records (CAS) durchführen müssen. Das ist eine grundlegende Sicherheitsmaßnahme, auch wenn sie weniger effizient ist. DynamoDB selbst hätte das vermutlich übernehmen können

• Ich war überrascht zu lesen, dass DynamoDB pro Region Hunderttausende DNS-Records verwaltet. Dass dynamodb.us-east-1.amazonaws.com zu Hunderttausenden IPs aufgelöst werden könnte, klingt nach einer Größenordnung jenseits der Grenzen von Route53. Vermutlich wird mit niedrigen TTLs gearbeitet und jeweils nur ein Teil aktualisiert

  • Tatsächlich funktioniert AWS-DNS so. Route53 arbeitet auf Ebene von Resource Record Sets (RRSets) und liefert über Health Checks oder latenzbasierte Auswahl die passende Menge zurück
  • CDNs funktionieren ähnlich. Sie sammeln Systemmetriken und berechnen pro Netzwerk den optimalen PoP. Ein gutes Beispiel ist bunny.net SmartEdge
  • Ich habe es selbst mit S3 getestet und innerhalb weniger Sekunden Hunderte unterschiedliche IPs bekommen. Diese Vielfalt gibt es also sogar innerhalb einer einzelnen Region

• Bugs wird es immer geben. Formale Verifikation ist schwierig, und Fehler mit geringer Eintrittswahrscheinlichkeit schlagen manchmal erst Jahre später zu.
  Deshalb muss man Systeme so entwerfen, als würden sie zwangsläufig scheitern, und Strukturen schaffen, die den Schaden begrenzen. Zellbasierte Architekturen, schrittweise Rollouts und isolierte Zonen sind Beispiele dafür.
  AWS versucht ebenfalls einen zellbasierten Ansatz, aber besonders in us-east-1 bestehen weiterhin Legacy-Abhängigkeiten über Systemgrenzen hinweg. Langfristig sollten Regionen vollständig unabhängig konstruiert werden.
  Solche Arbeiten kommen ohne Unterstützung auf hoher Führungsebene kaum voran, sind aus Aktionärssicht aber eine Schlüsselinvestition, um das Risiko für den Fortbestand des Unternehmens zu senken

• Es war überraschend, dass der Bericht die PT-Zeitzone statt UTC verwendet hat

  • Es gibt schon Witze à la „epoch fail?“, aber da die meisten Kunden in den USA sitzen, ist PT womöglich intuitiver
  • Vielleicht sollte damit auch die Schwierigkeit einer Reaktion in der Nacht betont werden

• Ich war überrascht, dass es keine Muster wie Versionsverwaltung pro Endpoint oder 2PC, Single-Writer-Lease gab. Trotzdem schätze ich sehr, dass AWS das so transparent offengelegt hat

  • Tatsächlich führt die DNS-Änderungs-API CAS aus, aber mehrere asynchrone Writer konkurrierten ohne logische Reihenfolge miteinander. Man hätte die Reihenfolge über ein Zone-Serial oder einen Sentinel-Record serialisieren müssen

• Ich denke, die unmittelbare Ursache dieses Vorfalls war eine latente Race Condition im DNS-Management-System von DynamoDB. Ein veralteter Plan überschrieb den neuesten Plan, wodurch die DNS-Records des regionalen Endpoints leer wurden

  • Beim Begriff „root cause“ ist jedoch Vorsicht geboten. Hier handelte es sich um einen metastabilen Kollaps, und das eigentliche Kernproblem war das Fehlen eines Runbooks.
    Referenz: How Complex Systems Fail