Wenn us‑east‑1 niest: Ein Feldführer zum Ausfall am 19.–20. Okt. AWS us‑east‑1

Name

Akira Sakamoto

Updated on 22.10.2025

Ereignisdatum: 19.–20. Okt. 2025 (Pacific Time)
Primärer Auslöser: Fehler in der DNS‑Automatisierung für den regionalen DynamoDB‑Endpoint
Blast‑Radius: DynamoDB → EC2‑Starts → Network Manager → NLB → (Lambda, STS, IAM‑Anmeldung, Redshift, ECS/EKS/Fargate, Connect) in us‑east‑1

Kurzfassung (für vielbeschäftigte Personen)

• Was es ausgelöst hat (11:48 PM 19. Okt.): Eine Race‑Condition in DynamoDBs automatischer DNS‑Verwaltung setzte den regionalen Endpoint dynamodb.us-east-1.amazonaws.com auf einen leeren Eintrag. Alles, was eine neue Verbindung zu DynamoDB in us‑east‑1 eröffnen wollte, scheiterte an der DNS‑Auflösung.
• Primäre DynamoDB‑Wiederherstellung (2:25–2:40 AM 20. Okt.): AWS stellte die korrekten DNS‑Einträge wieder her; Kunden erholten sich, als zwischengespeicherte DNS‑Einträge abliefen.
• Warum es nicht dort blieb: EC2s interne Steuerungsebene abhängt von DynamoDB für Host‑(„Droplet“)‑Leases. Diese Leases liefen während des DNS‑Fensters ab, was zu einer Stau‑Kollaps im Droplet Workflow Manager (DWFM) und zu einem Rückstau im Network Manager führte. Neue EC2‑Starts schlugen fehl oder kamen ohne vollständigen Netzwerkstatus hoch.
• Turbulenzen bei Load Balancern (5:30 AM–2:09 PM): Network Load Balancer (NLB)‑Health‑Checks flapperten wegen verzögerter Netzwerkpropagation, was intermittent Kapazitätsentnahmen und Verbindungsfehler verursachte.
• Rückkehr zum stabilen Zustand: Die meisten Dienste stabilisierten sich am frühen Nachmittag des 20. Okt.; Redshift‑Nachzügler (aufgrund von EC2‑Ersatz) waren bis 4:05 AM 21. Okt. noch aktiv.

Das „was passiert ist“ in einer diagrammähnlichen Timeline (PDT)

Zwei Minuten zu den Kernkonzepten (für neuere Leser)

DNS (Domain Name System)
Denken Sie an DNS wie ans Telefonbuch des Internets. Sie fragen nach einem Namen; es gibt zurück, wen Sie anrufen sollen (IP‑Adressen). Bei Hyperscale verwenden Anbieter DNS‑Einträge und Health‑Checks, um Traffic über riesige Flotten und Availability Zones zu steuern. DNS ist schnell und allgegenwärtig, aber kein transaktionales Datenbank‑System; Konsistenz und Änderungsreihenfolge sind schwierige Probleme, die speziell adressiert werden müssen.

DynamoDB
AW S's vollständig verwaltete Key‑Value/NoSQL‑Datenbank. Sehr geringe Latenz, elastisch und überall im Einsatz — auch von AWS selbst für Steuer‑ und Metadaten. Global Tables replizieren zwischen Regionen. Wenn Ihre App oder eine AWS‑Subsystem‑Komponente Steuerzustand nicht lesen/schreiben kann, staut sich schnell Arbeit auf.

EC2 & die Steuerungsebene
EC2 betreibt Instanzen auf physischen Hosts („droplets“). Interne Dienste verwalten Leases für diese Hosts und propagieren Netzwerkzustand (Routen, Security Groups usw.). Einen neuen Instance‑Start anzustoßen ist einfach — es sei denn, die interne Koordination ist ungesund oder überlastet.

NLB (Network Load Balancer)
Ein Layer‑4‑Load‑Balancer. Er führt Health‑Checks aus und kann über AZs routen. Wenn Health‑Checks flappern oder DNS‑basiertes Failover zu aggressiv ist, kann temporär zu viel Kapazität entfernt werden — genau dann, wenn man sie am dringendsten braucht.

Was tatsächlich versagte: Die DynamoDB‑DNS‑Automatisierung

AWS teilt die DynamoDB‑DNS‑Verwaltung in zwei Rollen:

• DNS Planner: berechnet die gewünschten Record‑Sets (welche Load Balancer, mit welchen Gewichten) für jeden Endpoint (regional, FIPS, IPv6, konto­spezifisch).
• DNS Enactor: drei redundante Worker in verschiedenen AZs, die diese Pläne auf Route 53 anwenden, jeweils mit transaktionalen Updates.

Unter ungewöhnlicher Konkurrenzarbeit lief ein Enactor langsam, während ein anderer mit neueren Plänen vorpreschte und dann ältere Generationen aufgeräumt hat. Der langsame Enactor hat dann einen veralteten „älteren“ Plan überschrieben, und unmittelbar bevor der schnelle Enactor die älteren Pläne löschte, wurde dadurch der regionale Endpoint komplett von allen IPs bereinigt — das System blieb in einem Zustand, der weitere automatische Updates blockierte. Menschen griffen ein, um zu reparieren.

Warum das wichtig war: Der regionale Endpoint verschwand. Alles, was eine neue DNS‑Auflösung zu DynamoDB in us‑east‑1 brauchte, scheiterte sofort. Bestehende Verbindungen funktionierten in der Regel weiter.

Warum es kaskadierte: enge Kopplungen und der Pfeil der Zeit

1. Control‑Plane‑Kopplung (EC2 ⇄ DynamoDB).
   EC2s Droplet Workflow Manager (DWFM) hält Leases auf physischen Hosts. Diese Prüfungen hängen an DynamoDB. Während des DNS‑Ereignisses liefen Leases aus, wodurch Droplets für neue Platzierungen ungeeignet wurden. Als DynamoDB zurückkam, musste DWFM Leases über eine riesige Flotte neu etablieren, traf auf Queue‑Timeouts und verstopfte.

2. Verzögerte Netzwerkpropagation.
   Selbst wenn Instanzen wieder gestartet wurden, hatte der Network Manager einen Rückstau bei der Veröffentlichung ihres Netzwerkstatus. Instanzen kamen ohne vollständige Konnektivität hoch, bis die Propagations‑Jobs aufholten (≈10:36 AM).

3. Health‑Check‑Feedback‑Schleifen (NLB).
   Neue Kapazität mit unvollständigem Netzwerkstatus wirkte unhealthy, weshalb der NLB Knoten oder AZs zurückzog, was die Kapazität temporär verkleinerte und Verbindungsfehler verschlimmerte. Operateure pausierten das automatische Health‑Check‑Failover, um die Oszillation zu stoppen, und aktivierten es erst wieder, nachdem EC2 stabil war.

4. Downstream‑Echoeffekte.
   Lambda drosselte bestimmte Pfade, um synchrone Aufrufe zu schützen; STS/IAM‑Anmeldungen schwächelten und erholten sich; Container‑Steuerbenen (ECS/EKS/Fargate) und Connect spürten die kombinierten EC2/NLB‑Effekte; Redshift hatte zusätzlich: IAM‑gestützte Query‑Auth fiel kurzzeitig global aus, und einige Cluster warteten auf EC2‑Host‑Ersatz, was bis in 21. Okt. nachwirkte.

Wenn Sie an das „Swiss‑cheese‑Modell“ denken — viele dünne Schutzschichten, die sich genau so ausrichten — dann liegen Sie richtig.

Eine komplexe‑Systeme‑Linse (warum „root cause“ allein nicht reicht)

Mehrere Praktiker auf HN zitierten Richard Cooks How Complex Systems Fail und Perrows Normal Accidents. Dieser Rahmen passt verblüffend gut:

• Keine einzelne Ursache. Die DNS‑Race‑Condition zündete den Streich, aber der lange Schweif entstand durch EC2s metastabilen Wiederherstellungsmodus und NLBs Health‑Check‑Oszillation — jeweils lokal sinnvolle Designs, die unter Stress schlecht miteinander interagierten.
• Systeme laufen meist degradiert. Planner/Enactor‑Retries, Lease‑Abläufe, Rückstände in Queues — normale Reibung, die das System toleriert, reihten sich unglücklich aneinander.
• Menschen schaffen Sicherheit. Automation stockte; Operatoren improvisierten Reparaturen (manuelle DNS‑Wiederherstellung, DWFM‑Drosselung/Neustarts, Deaktivieren des NLB‑Auto‑Failovers), um das Gefüge wiederzuvernähen.

Takeaway: Den Bug beheben ist nötig — aber suchen Sie auch nach metastabilen Wiederherstellungsfallen und Feedback‑Schleifen, die kleine Fehler aufschaukeln.

Was AWS sagt, dass sie ändern

• DynamoDB‑DNS‑Automatisierung: global deaktiviert, während der Race‑Bug gefixt wird; zusätzliche Schutzmaßnahmen, um das Anwenden oder Löschen falscher Pläne zu verhindern.
• NLB: Einführung einer Geschwindigkeitsbegrenzung, sodass Health‑Check‑Failover nicht zu schnell zu viel Kapazität entnehmen kann.
• EC2: neue Recovery‑Testsuites für DWFM; bessere queue‑bewusste Drosselung über Daten‑Propagationssysteme hinweg.

Das sind die richtigen Klassen von Maßnahmen: schlechte Writes verhindern, Selbstheilung drosseln und Recovery‑Pfade unter Last prüfen.

Was Sie tun können (Checkliste für den Montagmorgen)

Auch wenn Sie AWS nicht ändern können, können Sie das Risiko in Ihrem eigenen Stack abmildern.

1. Bevorzugen Sie regionale Endpoints und entfernen Sie versteckte us‑east‑1‑Abhängigkeiten.
   Wo Dienste regionale Steuer‑APIs anbieten (z. B. STS), verwenden Sie diese. Zentralisieren Sie Auth oder Metadaten nicht aus Gewohnheit in us‑east‑1.

2. Entwerfen Sie für Multi‑Region‑Datenzugriff — besonders für kritischen Steuerzustand.
   DynamoDB Global Tables ermöglichen, Lese/Schreib‑Failover in eine zweite Region. Ihr Code muss Replikationsverzögerung tolerieren und später zusammenführen.

3. Fail closed bei Health‑Check‑Oszillation.
   Schützen Sie automatisches Failover mit Dämpfung: mehrere aufeinanderfolgende Fehlschläge, Hysterese und Caps für pro‑Minute Kapazitätsentnahme. Erwägen Sie einen manuellen Override‑Circuit‑Breaker, um Flapping zu stoppen.

4. Machen Sie Abhängigkeitsgraphen explizit.
   Dokumentieren Sie, welche Dienste unbedingt verfügbar sein müssen, um Starts/Skalierung zu ermöglichen (Auth, Queues, Config Stores). Üben Sie „Was, wenn X für 2 Stunden langsam/ausfällt?“

5. Üben Sie metastabile Wiederherstellungen.
   Chaos‑Day für die Steuer‑Ebene, nicht nur für die Daten‑Ebene:

   • Leases auf einem Flotten‑Slice ablaufen lassen simulieren.
   • Ihren Netzwerk‑Konfig‑Propagator fluten.
   • Abläufe für Back‑Pressure und Drossel‑Aufhebung proben.

6. Cachen mit Absicht.
   DNS‑Caches verdeckten den Wiederherstellungs‑Verzug (Clients profitierten von TTL‑Ablauf). Für SDKs, die neue Verbindungen aggressiv öffnen, ziehen Sie Connection Pooling und Exponential Backoff mit Jitter in Betracht, um synchronisierte Retries zu vermeiden.

7. Bauen Sie „Safe‑Mode“‑Runbooks.

   • Reduzierte Parallelität oder Ratenlimits bei Fehler‑Spikes.
   • Bevorzugen Sie das Abarbeiten von Backlogs, bevor Auto‑Scaler wieder aktiviert werden.
   • Verwenden Sie Feature Flags, um teure Hintergrundjobs während Control‑Plane‑Incidents abzuschalten.

8. Schützen Sie eigene „Planner/Enactor“‑Muster.
   Wenn Sie gewünschten Zustand generieren und woanders anwenden, fügen Sie hinzu:

   • Versionierte Pläne mit Compare‑and‑Swap‑Semantik.
   • Aufräum‑Logik, die nicht den letzten Known‑Good‑Plan löschen kann.
   • Eine Single‑Writer‑Lease pro Endpoint oder einen kleinen Sequencer (Vektor‑Uhr / monotoner Zähler).

War das eine „Fehlverwendung von DNS“?

Nicht genau. Bei Hyperscale ist DNS ein Tool für Service‑Discovery und Traffic‑Steuerung, weil jeder Client, jede Bibliothek und jeder VPC‑Resolver es versteht. Das Problem war nicht die Nutzung von DNS; das Problem war, gleichzeitige Schreiber und ein Aufräumer ohne robuste Ordnungs‑Garantien zuzulassen und Health‑Check‑gesteuertes DNS während eines Netzwerk‑Propagationsrückstands zu schnell Kapazität entfernen zu lassen. Das sind technische Entscheidungen, die sich beheben lassen.

Glossar (60‑Sekunden‑Auffrischer)

• Route 53: AWSs DNS‑ und Health‑Check‑Service. Unterstützt gewichtete/latency/health‑basierte Routen und transaktionale Record‑Änderungen.
• TTL (time to live): Wie lange ein Resolver eine DNS‑Antwort cachen darf. Kurze TTLs beschleunigen Failover und erhöhen die Query‑Rate.
• DWFM (Droplet Workflow Manager): EC2‑Subsystem, das Leases auf physischen Hosts verwaltet.
• Network Manager: Propagiert VPC/Netzwerk‑Konfiguration an Instanzen und Netzwerk‑Appliances.
• Global Tables (DynamoDB): Multi‑Region‑Replikation für Tabellen, mit eventualer Konsistenz und Konfliktlösung.

Abschließende Gedanken

Dieser Ausfall war nicht „einfach nur DNS“. Es war DNS + Control‑Plane‑Recovery + Health‑Check‑Dynamiken + menschliches Eingreifen — eine Erinnerung daran, dass Verfügbarkeit eine System‑Eigenschaft ist, nicht ein Komponenten‑Feature. Ermutigend ist, dass die Gegenmaßnahmen konkret sind: Plan‑Anwendung serialisieren, Kapazitätsentnahme dosieren, Recovery‑Pfade unter Last prüfen. Kopieren Sie diese Muster in Ihren eigenen Stack, und das nächste Mal, wenn us‑east‑1 niest, brauchen Ihre Anwendungen weniger Taschentücher.