> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2025/w43-lessons-learned-from-the-aws-incident.md).

# W43-Lehren aus dem AWS-Ausfall

Vergangene Woche erlitt AWS einen schweren Ausfall über fünfzehn Stunden. Weltweit waren die Dienste von mehr als 1000 Unternehmen unterbrochen, und es entstanden Schäden in Milliardenhöhe. Eine wichtige Lehre: Selbst der ausgefeilteste technische Entwurf kann an einer einzigen zentralen Abhängigkeit scheitern.

Der Vorfall traf die wichtigste AWS-Region us-east-1. Ursache war ein Race-Condition-Fehler in der automatisierten DNS-Verwaltung von DynamoDB. Er löschte versehentlich die IP-Einträge des regionalen Endpunkts und verhinderte die Namensauflösung. us-east-1 ist kein gewöhnliches Rechenzentrum, sondern das zentrale Nervensystem der weltweiten AWS-Infrastruktur. Fast alle gemeinsamen Steuerungsebenen anderer Regionen hängen davon ab, darunter EC2-Scheduling, NLB und Lambda. So entstand eine Kaskade von Ausfällen.

Ironischerweise zeigte die AWS-Statusseite 75 Minuten nach Beginn noch immer normalen Betrieb. CloudWatch selbst hing ebenfalls von DynamoDB ab. Die Überwachung wurde mit blind.

Auch die Wiederherstellung war schwierig. DNS-Einträge ließen sich schnell reparieren, doch DynamoDB ist ein zentraler Steuerungsknoten. EC2-Scheduler mussten Leases für Zehntausende Server neu aufbauen, Netzwerkmanager Rückstaus bereinigen und verspätete Zustände verteilen. Load Balancer stuften Instanzen wiederholt fälschlich als ungesund ein und entfernten sie. Schließlich musste AWS automatische Gesundheitsprüfungen und Failover abschalten. Erst menschliche Eingriffe stoppten weitere Kaskaden.

Nach dem Blick auf den fremden Vorfall sollten wir unsere eigenen Dienste prüfen. Verdeckte systemische Einzelabhängigkeiten liegen womöglich gerade in Basisdiensten, die bei Geschäftsiterationen wenig Aufmerksamkeit erhalten, etwa Einstiegs- und Verifikationsdienste. Der Informationseinstieg hat einfache Geschäftslogik, aber eine enorme Reichweite und kontrolliert 80 % des Traffics. Sein Entwurf sollte minimalen Abhängigkeiten und maximaler Entropie folgen und äußerst klar und einfach bleiben.

Solche kleinen Komponenten reizen ehrgeizige Ingenieure, weil sie deutliche technische Herausforderungen enthalten: mehrere Versionen für unterschiedliche Stacks, lange Releasezyklen und Abhängigkeit von Hostseiten der Geschäftsbereiche. Rückblickend sollten wir prüfen, ob unsere Richtung dieses Jahr richtig war. Für dynamische Updates, kürzere Releasezyklen und mehr Flexibilität investierten wir viel Engineering, führten zusätzliche Abhängigkeiten und komplexere Architektur ein und verlangsamten zugleich die Wirksamkeit von Rollbacks. Auf diesem Weg würden nach der Dynamisierung vermutlich dynamische Komponenten für verschiedene Container folgen, um die Implementierungsvarianten zu bündeln und hohe Wiederverwendung zu erreichen. Sobald aber die intensive Iterationsphase des Einstiegs vorbei ist, beginnt das Feature wie technische Schuld auszusehen.

Ich sehe selbstkritisch, dass ich mich dieses Jahr noch zu sehr auf das Training technischer Fähigkeiten konzentriert und Gelegenheiten für kunstvolle Übungen geschaffen habe. Die Qualität technischer Entscheidungen rückte nicht früh genug in den Mittelpunkt. Es fehlten klare Rahmen, Fakten und logische Ableitungen. Was wir aus meiner Sicht richtig machten, war die Einführung demokratischer gemeinsamer Entscheidungen.

Fast jeder Ingenieur durchläuft eine Phase, in der Redundanz abgelehnt, alles abstrahiert und Komplexität zum Maß technischer Qualität erhoben wird. Wir sollten den Mut haben, dieses Zwischenstadium zu verlassen und nach gründlicher Abwägung Klarheit und Einfachheit zu suchen. Wie in der Unix-Philosophie: den Geschmack für wirklich gute Arbeit entwickeln.