Jeder Recovery-Plan trägt eine zweite Annahme, leiser als die erste. Die erste ist, dass ein Teil der Infrastruktur das Ereignis überlebt; Teil 1 und 2 dieser Serie testeten diese. Die zweite ist, dass du, wenn das Ereignis kommt, den Fix noch ausrollen kannst: Die API antwortet, die Console lädt, deine Pipeline kann eine Rolle annehmen, die Auto Scaling Group kann einen Ersatz starten. Am 13. Juni 2023 degradierte ein latenter Defekt in dem Subsystem, das die Compute-Kapazität von Lambda verwaltet, Funktionsaufrufe in us-east-1, und für einen Teil der nächsten vier Stunden lieferte die AWS Management Console in dieser Region Fehlerseiten aus, während STS erhöhte Fehlerraten warf. Nichts in der Infrastruktur der meisten Kunden ging an diesem Tag kaputt. Was kaputtging, war die Schicht, mit der sie es gefixt hätten. Wenn die Control Plane innerhalb des Blast Radius liegt, liegt der Remediation-Pfad innerhalb der Failure Domain.

Dies ist Teil 3 von Nothing Fails Alone. Teil 1 nahm den us-east-1 Incident im Mai und zeigte die Zonengrenze standhalten, während eine Kundenarchitektur darin ausfiel. Teil 2 nahm das me-central-1 Ereignis im März und zeigte, wogegen die Grenze ausgelegt ist, Einrichtungsfehler, und wogegen nicht, eine Ursache, die zwei Zonen erreicht. Beide Teile endeten nahe derselben Einschränkung, die AWS mitten in beiden Incidents veröffentlichte: "longer than usual provisioning times". Teil 1 versprach, dass es in diesem Teil darum gehen würde, was dein Recovery-Plan mit dem Recovery-Plan aller anderen teilt. Hier ist die Antwort: Er teilt die Control Plane. Dein Failover ruft dieselben regionalen APIs auf wie jedes andere Failover in der Region, betrieben vom Provider, degradiert durch dieselben Ereignisse, die dazu führen, dass du es brauchst, und diese Abhängigkeit verdient dieselbe Prüfung, die du deinen Replikas gibst.

Juni 2023: der Fix brauchte das, was ausfiel

Der Mechanismus ist öffentlich dokumentiert, seit AWS seine Post-Event-Summary für den 13. Juni 2023 veröffentlichte. Es lohnt sich, sie genau zu lesen, denn sie ist der sauberste dokumentierte Fall einer Control Plane, die ausfällt, während die Infrastruktur darunter weiterläuft. Um 10:01 AM PDT begann die Lambda-Frontend-Flotte in us-east-1, für gewöhnlichen Tagesverkehr zu skalieren. Um 11:49 AM überschritt sie, in den Worten von AWS, "a capacity threshold that had previously never been reached within a single cell", was "triggered a latent software defect". Execution Environments wurden allokiert, aber nie genutzt, das Subsystem, das "responsible for managing the underlying compute capacity" ist, konnte keine funktionierenden Ersätze bereitstellen, und Lambda-Aufrufe in der Region begannen fehlzuschlagen.

Dann tat der Abhängigkeitsgraph seine Arbeit. Die Summary listet Amazon STS, die AWS Management Console, Amazon EKS, Amazon Connect und Amazon EventBridge als degradiert "as a result of the degraded Lambda function invocations". STS gab erhöhte Fehlerraten von 11:49 AM bis 2:10 PM PDT zurück "with three distinct periods of impact". Die Console in us-east-1 lieferte von 11:48 AM bis 2:02 PM entweder eine Seite "AWS Management Console is currently unavailable" oder einen "504 Time-out". Auch das föderierte Sign-in degradierte: "Existing IAM sessions were not impacted, but new sign-in federation via SAML was degraded." Die vollständige Wiederherstellung kam um 3:37 PM PDT, drei Stunden und achtundvierzig Minuten nach Beginn des Impacts.

Übertrage das auf ein gewöhnliches Runbook. Schritt eins, in der Console anmelden: degradiert. Schritt zwei, die Pipeline eine Rolle für frische Credentials annehmen lassen: STS, degradiert, dreimal getrennt. Schritt drei, die Remediation-Lambda aufrufen: das ist der Ausfall. Keine deiner Instances fiel aus. Deine Datenbank machte kein Failover. Das Ereignis berührte deine Infrastruktur überhaupt nie, und es nahm dir trotzdem die Werkzeuge weg, die dein Plan voraussetzte. Die Lektion ist strukturell, nicht historisch: Die operierende Schicht und die ausfallende Schicht waren dieselbe Schicht, und sie werden es wieder sein.

Oktober 2025: der Meltdown, neu betrachtet von der Control Plane aus

Als us-east-1 im Oktober 2025 ausfiel, behandelte diese Site es am selben Tag in Wenn die Cloud niest, erkaltet sich die Welt. Jener Post handelte von der Breite des Blast Radius, der Absurdität, dass das halbe Internet von einer Region abhängt, und er endete mit dem, was zu ändern ist. Dieser Teil ist die dort versprochene Fortsetzung, geschrieben mit dem Vorteil von AWS' offizieller Post-Event-Summary, und die Summary belohnt eine kühlere Lesart als die, die der Tag erlaubte: Schau, was mit den Werkzeugen geschah, nicht mit den Apps.

Der Auslöser war DNS: "a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record" für dynamodb.us-east-1.amazonaws.com, ein Record, den die Automatisierung "failed to repair". Der Endpoint von DynamoDB war innerhalb von Stunden wiederhergestellt. Der Schaden an der Control Plane lief viel länger. EC2, laut der Summary: "Between 11:48 PM PDT on October 19 and 1:50 PM PDT on October 20, customers experienced increased EC2 API error rates, latencies, and instance launch failures", vierzehn Stunden, in denen der Standard-Recovery-Zug jeder Multi-AZ-Architektur in der Region, Ersatzkapazität starten, selbst beeinträchtigt war. STS gab "API errors and latency" von 11:51 PM bis 9:59 AM zurück. Console-Sign-in mit einem IAM-User schlug mit "increased authentication failures" bis 1:25 AM fehl, Identity-Center-User in der Region konnten sich überhaupt nicht anmelden, und Root-Credential- und föderiertes Sign-in warfen sogar in anderen Regionen Fehler, weil der Sign-in-Pfad selbst in us-east-1 lag.

Halte die beiden Posts nebeneinander, und die Arbeitsteilung ist klar. Der Oktober-Post fragte, was es kostet, von einer Region abzuhängen. Dieser fragt die engere, fiesere Frage darin: Als die Region ihren schlechten Tag hatte, warum blieben gut gebaute Multi-AZ-Architekturen stundenlang unten? Weil ihre Wiederherstellung eine Control-Plane-Operation war. Skalieren war der Fix, und Skalieren war das, was vierzehn Stunden beeinträchtigter Instance-Starts wegnahmen. Der Plan aller konvergierte gleichzeitig auf derselben degradierten API, was genau das ist, was "dein Plan teilt die Control Plane mit dem aller anderen" in der Praxis bedeutet.

Februar 2026: Azure, dieselbe Form, anderes Logo

Wäre dies eine AWS-Eigenheit, wäre es ein AWS-Problem. Ist es nicht. Am 2. Februar 2026 protokollierte Microsoft den Incident FNJ8-VQZ, und sein Post-Incident-Review beginnt: "Between 18:03 UTC on 02 February 2026 and approximately 00:30 UTC on 03 February 2026, a platform issue caused some customers to experience degraded performance and control plane failures, for multiple Azure services across multiple regions." Eine Security-Remediation-Policy, die anonymen Zugriff auf von Microsoft verwaltete Storage Accounts deaktivieren sollte, wurde durch "a data synchronization problem in the targeting logic" auf Accounts angewendet, die "intentionally configured to allow anonymous read access for platform functionality" waren: die Accounts, die VM-Extension-Pakete ausliefern. Virtuelle Maschinen trafen auf "failures when deploying or scaling", AKS traf auf "failures in node provisioning", und GitHub-Actions-Jobs "queued and timed out while waiting to acquire a hosted runner".

Beachte, was nicht geschah: Laufende VMs liefen weiter. Die Data Plane war in Ordnung. Was starb, war die Fähigkeit, zu erstellen, zu skalieren oder zu ändern, über mehrere Regionen auf einmal, weil die Control Plane auf eine Weise geteilt ist, wie es die Data Plane nicht ist. Das ist die Eigenschaft, die es zu verallgemeinern lohnt. Eine Control Plane ist ein logisches System, das die Zonen, manchmal die Regionen, überspannt, die ihre Data Plane sorgfältig getrennt hält; sie ist das Stück unter maximaler Last genau dann, wenn alle sich wiederherstellen; und sie fällt auf Weisen aus, die Multi-Region-Diagramme nicht zeigen, weil das Diagramm deine Ressourcen zeichnet, nicht die Maschinerie, die sie verändert. Zwei Provider, vier Monate auseinander, dieselbe Form.

Statische Stabilität, richtig definiert

Die Verteidigung hat einen Namen: statische Stabilität. Ein statisch stabiles System erfüllt seine Anforderungen weiter, wenn eine Abhängigkeit ausfällt, ohne irgendetwas ändern zu müssen, weil das, worum es die Abhängigkeit gebeten hätte, bereits vorhanden ist. Die Definition verdient das Wort "statisch": Wiederherstellung, die keine Mutation erfordert, kann nicht von der Schicht blockiert werden, die Mutationen durchführt. Konkret bedeutet das eine kleine Familie vorberechneter Entscheidungen:

  • Vorbereitgestellter Puffer. Jede Zone betreibt genug Kapazität, dass die überlebenden Zonen die volle Last ohne Start tragen. Zonenverlust wird zu einer Load-Balancer-Entscheidung, einer Data-Plane-Operation, statt zu einem Auto-Scaling-Ereignis, einer Control-Plane-Operation.
  • Vorab erstellt, nicht beim Failover erstellt. Die DNS-Records des Standby, die Target-Group-Zuordnungen und die Standby-Instances existieren vor dem Incident. Failover kippt Health Checks und Gewichte; es führt kein Terraform aus.
  • Vorgebackene Images. Ein AMI, das bis zum Ausliefern bootet, ohne Package-Mirror, Config-Services oder Secrets-Endpoints zu erreichen, hält einen Start nützlich, selbst wenn alles um den Start herum degradiert ist.
  • Break-Glass-Pfade, die die ausgefallene Schicht meiden. Die Oktober-Summary ist unverblümt beim Sign-in: IAM-User, Identity Center und Föderation degradierten allesamt gemeinsam. Ein Notfall-Zugriffspfad ist nur real, wenn er nicht die Region und die Identity Plane durchquert, die du zu retten versuchst, und nur real, wenn er geübt wird; ein ungetestetes Break-Glass-Credential ist ein Wunsch.

Der gemeinsame Faden ist, Arbeit von während-des-Incidents auf vor-dem-Incident zu verschieben, vom Zeitplan der Control Plane auf deinen. Du kannst die Control Plane des Providers nicht zuverlässig machen. Du kannst dafür sorgen, sie in der ersten Stunde nicht zu brauchen.

Das Lab: miss den Unterschied, behaupte ihn nicht

Das Lab für diesen Teil, 03-static-stability, bricht wissentlich eine Serienregel: Es ist nicht read-only. Terraform baut eine VPC, einen zum Internet gerichteten ALB und sechs t3.micro-Instances, und es kostet Geld, bis du es zerstörst, also gehört es in einen Sandbox-Account und noch am selben Tag in den Müll. Was es für diesen Preis kauft, ist eine Messung der exakten Lücke, die dieser Post beschreibt, auf deinem Account, statt meiner Behauptung darüber. AWS' eigene Fault-Injection-Dokumentation nennt die Prämisse unumwunden: für das AZ-Power-Interruption-Szenario "EC2 API calls made by the Auto Scaling control plane to recover lost capacity in the AZ will fail". Das Lab baut beide Antworten auf diesen Satz hinter einem Load Balancer. Pfad A ist das Standard-Design: eine Auto Scaling Group mit einer Instance pro Zone und einer Scaling Policy, sodass der Verlust einer Zone bedeutet, dass die ASG ec2:RunInstances aufrufen muss, um sich zu erholen. Pfad B ist das statisch stabile Design: derselbe Workload vorab mit doppelter Kapazität bereitgestellt, zwei Instances pro Zone, sodass jede Zone allein bereits die volle Last trägt.

Das Mess-Skript verdient eine Anmerkung, denn sein erster Entwurf war auf lehrreiche Weise falsch. Einfach das Subnetz der ausgefallenen Zone aus einer ASG zu entfernen, ist kein Zonenverlust: Es löst Rebalancing aus, und Rebalancing startet Ersätze, bevor irgendetwas beendet wird, sodass die gesunde Kapazität nie absinkt und es nichts zu messen gibt. Echter Zonenverlust killt die Instances. Also entfernt measure.py das Subnetz und beendet dann die im Dienst befindlichen Instances dieser Zone via TerminateInstanceInAutoScalingGroup mit ShouldDecrementDesiredCapacity=False, sodass jede Gruppe echte Kapazität verliert, die sie anderswo wiederherstellen muss. Für Pfad A misst es dann das Intervall vom Fehler bis zur vollen gesunden Anzahl am Load Balancer, ein Intervall, das reine Control Plane ist: Launch-Aufruf, Boot, Health Checks. Für Pfad B beobachtet es die gesunde Anzahl durch ein Settle-Fenster und erfasst das Minimum, das von vier auf zwei fällt; zwei ist genau die Anforderung nach dem Ausfall, sodass die Pass-Bedingung gegen ein echtes Absinken getestet wird, statt trivial zu halten. Dies ist die Form der Tabelle, die das Skript druckt, kein Ergebnis, das ich erzielt habe; ich habe dies für diesen Post nicht gegen einen Live-Account laufen lassen, und die Zahlen, die ein Leser bekommt, sind seine:

PATH                    | TIME TO RECOVER               | API CALLS REQUIRED                | SURVIVES CONTROL PLANE LOSS
path-a (control plane)  | measured on your run          | yes: ec2:RunInstances via the ASG | no
path-b (static)         | 0s, capacity already in place | none                              | yes

Welche Zahl Pfad A auch für dich druckt, lies sie als Best Case: Sie wurde gegen eine gesunde, kooperative Control Plane an einem ruhigen Tag gemessen. Die Control Plane im Oktober war keins von beidem. Lab 04 existiert, um diese Lücke zu schließen, indem es die Insufficient-Capacity-Fehler injiziert, die die Zahl von Pfad A in das verwandeln, was sie in dieser Nacht gewesen wäre.

Die ehrlichen Kosten, und wo es sich nicht mehr lohnt

Pfad B betreibt die doppelte Steady-State-Kapazität, um denselben Traffic zu bedienen. Das ist keine Fußnote, es ist der Deal: Statische Stabilität kauft Versicherung mit ungenutztem Compute, jede Stunde, gegen ein Ereignis, das in Stunden pro Jahr gemessen wird. Bei zwei Zonen beträgt die Prämie 100 Prozent; bei drei Zonen, jede so dimensioniert, dass sie eine verlorene absorbiert, fällt sie auf 50; bei mehr Zonen oder einer overprovisioning-bewussten Dimensionierung weniger. Bezahle sie für den Serving-Pfad, dessen Downtime in Umsatz oder Sicherheit gemessen wird, für kleine Flotten, wo Verdoppelung in absoluten Zahlen billig ist, und für alles, dessen Wiederherstellung sonst davon abhinge, dass die Control Plane mitten im Incident funktioniert.

Hör auf, sie dort zu bezahlen, wo die Mathematik nicht mehr aufgeht. Batch- und asynchrone Arbeit sollte einen Zonenverlust durchqueuen, nicht dagegen vorbereitstellen. Dev und Staging brauchen sie nicht. Sehr große Flotten zahlen echtes Geld für Puffer, und dort ist der ehrliche Zug, den Tier aufzuteilen: statische Stabilität für den kritischen Anteil, Control-Plane-Recovery akzeptiert, mit offenen Augen, für den Rest. Und wisse, was die Technik nicht abdeckt. Sie hätte Coinbase in Teil 1 nicht gerettet, denn ihr Ausfall lag in ihrer eigenen Data Plane, ein Quorum, das sich ein Gebäude teilte. Sie beantwortet nicht den Regionsverlust aus Teil 2, denn Puffer innerhalb einer dem Untergang geweihten Region ist dem Untergang geweihter Puffer. Sie schützt die ersten Stunden, auf die Wette, dass die Control Plane zurückkommt, bevor deine Reservekapazität aufhört zu genügen. Diese Wette hielt im Juni 2023 und im Oktober 2025. Ob deine Version davon hält, ist etwas, das du testest, und dorthin geht diese Serie als Nächstes.

Lies das als Nächstes

Für Consulting zu AWS, Cloud-Architektur, Resilience Reviews und Plattform-Arbeit, starte auf ercanermis.com.

Referenzen