Zusammenfassung

  • Eine fehlerhafte Verkehrsverlagerung trennte EBS-Speicherknoten in einer Availability Zone von ihren Replikaten. Als die Verbindung zurückkehrte, lösten gleichzeitige Replikatsuchen eine Wiederherstellungswelle aus, die freie Kapazität erschöpfte.
  • Die belastbare Lehre liegt nicht in pauschaler Schuldzuweisung. Entscheidend sind begrenzte Wiederherstellungslasten, Reservekapazität, Isolation, Lastabwurf und der Nachweis, dass angekündigte Korrekturen tatsächlich greifen.

Ein präzise begrenztes Ereignis

Am 21. April 2011 um 00:47 Uhr PDT begann nach Darstellung von AWS eine Kapazitätsänderung am primären Netzwerk von Amazon Elastic Block Store. Der Datenverkehr wurde dabei nicht wie vorgesehen geführt, sondern auf ein Replikationsnetz mit geringerer Kapazität verlagert. Viele Speicherknoten in einer betroffenen Availability Zone der Region US East verloren dadurch wirksame Verbindungen sowohl über den primären als auch über den sekundären Pfad.

Diese Eingrenzung ist wesentlich. Die Quellen tragen nicht die Aussage, ganz AWS sei ausgefallen. Der zentrale Speicherfehler lag in einer Availability Zone. Außerhalb dieser Zone kam es zeitweise zu EBS-API-Fehlern und erhöhter Latenz in der Region, weil ein regionaler Kontrollmechanismus überlastet wurde. Das ist ein weitreichender Effekt, aber kein Beleg für einen einheitlichen regionalen Volumenausfall und schon gar nicht für einen globalen Ausfall.

Ebenso wenig lässt sich eine einzige Dauer auf alle Betroffenen übertragen. Stabilisierung, Wiederherstellung der regionalen API, Wiederanlauf der API in der betroffenen Zone, Wiederherstellung einzelner Volumes, Abbau von Rückständen und verbleibende manuelle Arbeiten waren verschiedene Etappen. Die Erholung dauerte in Teilen mehrere Tage.

Die Architektur hinter der Störung

EBS arbeitete 2011 laut AWS mit replizierten Speicherclustern innerhalb einer Availability Zone. Ein regionaler Control Plane koordinierte Vorgänge. Für den normalen Betrieb gab es ein breit ausgelegtes primäres Netzwerk; daneben bestand ein weniger leistungsfähiges Netzwerk für Replikationsaufgaben.

Die Trennung dieser Aufgaben war grundsätzlich ein Schutzgedanke: Daten sollten nicht nur auf einem Knoten liegen, und ein zweiter Pfad sollte Replikation ermöglichen. Doch Schutz entsteht nicht allein dadurch, dass Kopien und alternative Pfade vorhanden sind. Er hängt davon ab, welche Last der Wiederherstellungsweg aufnehmen kann, wie viele Komponenten ihn gleichzeitig beanspruchen dürfen und ob ein Fehler in einem Cluster vom übrigen System ferngehalten wird.

Die Architekturangaben beschreiben ausdrücklich den öffentlich dokumentierten Stand von 2011. Sie sind keine Darstellung der heutigen AWS-Architektur oder aktueller Kundenoptionen. Genau diese zeitliche Grenze verhindert, dass aus einem historischen Postmortem vermeintliche Gegenwartsfakten werden.

Auslöser, Grundursache und Verstärkung

Der unmittelbare Auslöser war die fehlerhafte Verkehrsverlagerung während der Netzwerkänderung. Sie erklärt, warum Knoten isoliert wurden. Sie erklärt aber noch nicht, warum die Rückkehr der Verbindung eine so lange Störung nach sich zog.

Nachdem die Konnektivität wiederhergestellt war, suchten viele Knoten gleichzeitig nach neuen Replikaten. Ein Vorgang, der im Normalfall Datenhaltbarkeit wiederherstellen sollte, begann in großer Zahl parallel. Die Suche verbrauchte die verfügbare freie Kapazität. Unzureichendes Backoff begrenzte die Wiederholungen nicht aggressiv genug. Eine seltene Race Condition verstärkte das Verhalten zusätzlich. So entstand ein Re-Mirroring-Sturm: Die Wiederherstellung konkurrierte mit der Wiederherstellung um dieselben knappen Ressourcen.

Eine faire Ursachenanalyse trennt deshalb drei Ebenen. Der Trigger war die falsche Netzwerkumschaltung. Eine beitragende Bedingung war der Kapazitätsunterschied zwischen dem normalen Pfad und dem Replikationspfad. Verstärker waren die gleichzeitigen Replikatsuchen, unzureichendes Backoff und die Race Condition. Die tiefer liegende Kontrollfrage lautet, warum ein erwartbarer Schutzvorgang keinen ausreichend begrenzten Lastkorridor hatte.

Diese Trennung vermeidet eine häufige Verkürzung: Wer nur die auslösende Änderung betrachtet, übersieht die Systembedingungen, die aus einer begrenzten Fehlhandlung eine mehrtägige Wiederherstellung machten. Wer dagegen den Trigger zur alleinigen Grundursache erklärt, lernt wenig über Kapazitätsplanung, Rückkopplung und Isolation.

Wie der Control Plane die Störung verbreiterte

Die Speicherknoten waren nicht das einzige Problem. Lang laufende Anfragen zum Erstellen neuer Volumes belegten laut AWS Threads in einem regionalen Control-Plane-Pool. Als dieser Pool erschöpft war, stiegen Fehler und Latenzen der EBS-API auch jenseits der direkt betroffenen Availability Zone.

Hier zeigt sich ein zweiter Verstärkungsweg. Der Datenpfad eines Clusters war lokal beeinträchtigt, doch die Steuerung verwendete regionale Ressourcen. Wenn fehlgeschlagene oder blockierte Vorgänge dort lange Kapazität binden, kann eine lokale Degradation eine größere Bedienoberfläche treffen. AWS isolierte den beeinträchtigten Cluster und drosselte Last, um diesen Druck zu senken.

Für Verantwortliche ist das ein wichtiger Unterschied: Eine Availability-Zone-Grenze allein garantiert keine vollständige Fehlerkapselung, wenn Control-Plane-Pools, Warteschlangen oder Abhängigkeiten einen größeren Umfang besitzen. Die angemessene Prüfung fragt daher nicht nur, wo Nutzdaten liegen, sondern auch, welche Verwaltungsressourcen geteilt werden und wie sie sich unter lang laufenden Fehlerfällen verhalten.

Stabilisierung und gestufte Erholung

AWS berichtete, dass bei Stabilisierung des Clusters ungefähr 13 Prozent der Volumes in der betroffenen Availability Zone festhingen. Diese Zahl darf weder auf die gesamte Region noch auf alle AWS-Volumes oder Kunden übertragen werden. Sie bezeichnet einen bestimmten Zustand zu einem bestimmten Zeitpunkt und hat als Nenner die Volumes der betroffenen Zone.

Die Erholung erforderte mehr als das Wiederherstellen einer Netzwerkverbindung. Freie Kapazität musste geschaffen beziehungsweise ergänzt werden. Replikate wurden stufenweise wieder aufgebaut, Rückstände abgearbeitet und einzelne Fälle manuell behandelt. Gerade dieser Verlauf macht Wiederherstellungskapazität zu einer Kontrollgröße: Ein System kann seine normale Last tragen und dennoch scheitern, wenn viele Schutzvorgänge gleichzeitig starten.

Für die betriebliche Steuerung folgt daraus, dass Reserve nicht pauschal als Prozentzahl verstanden werden sollte. Sie muss gegen konkrete Szenarien getestet werden: Wie viele Knoten können gleichzeitig ihre Replikate verlieren? Wie schnell entsteht neue Replikationslast? Welche Anfragen werden priorisiert oder abgewiesen? Wann wird ein Cluster isoliert? Und gibt es kleine, kontrollierte Wiederanlaufgruppen statt eines ungebremsten Massenstarts?

Konsistenz und die Grenze der bekannten Schäden

AWS gab schließlich an, 0,07 Prozent der Volumes in der betroffenen Availability Zone nicht in einen konsistenten Zustand zurückführen zu können. Auch diese Zahl hat den Nenner der Volumes in genau dieser Zone. Sie ist nicht mit den ungefähr 13 Prozent festhängender Volumes gleichzusetzen: Beide Werte beschreiben verschiedene Ergebnisse und Zeitpunkte.

Aus den herangezogenen Quellen gehen weder verlorene Byte- oder Datensatzmengen noch eine vollständige Zahl betroffener Kunden hervor. Auch ein Gesamtschaden in Geld lässt sich nicht seriös beziffern. Die Aussage, Daten seien für einen begrenzten Anteil von Volumes nicht konsistent wiederherstellbar gewesen, ist belastbar, wenn sie AWS zugeschrieben und eng begrenzt wird. Größere Behauptungen über Datenverlust wären es nicht.

Servicegutschriften beantworten diese Schadensfrage ebenfalls nicht vollständig. Eine Gutschrift kann eine vertraglich vorgesehene Reaktion sein; sie beweist nicht, dass alle Folgekosten oder Kundenschäden kompensiert wurden. Umgekehrt liefert die Quellenlage keine Grundlage für eine rechtliche Haftungs- oder Pflichtverletzungsfeststellung.

RDS und die Grenze von Multi-AZ

Amazon Relational Database Service nutzte EBS für Datenbank- und Logspeicherung. Dadurch wurde die Speicherstörung zu einer Abhängigkeit für Datenbankkunden. AWS berichtete zudem von einem zuvor nicht aufgetretenen Zustand, der bei einem Teil der Multi-AZ-Instanzen einen automatischen Failover verhinderte und manuelles Eingreifen nötig machte.

Das ist kein Beleg dafür, Multi-AZ sei wertlos. Es ist vielmehr ein Hinweis darauf, Architekturversprechen anhand konkreter Fehlerpfade zu prüfen. Redundanz kann viele Einzelkomponentenfehler abfangen, ohne jede Control-Plane-, Speicher- oder Anwendungsauswirkung auszuschließen. Entscheidend ist, ob Failover unter genau den Bedingungen getestet wird, die bei gleichzeitiger Speicherdegradation und Steuerungsdruck entstehen.

Ebenso wäre es falsch, aus dem Ereignis eine allgemeine Behauptung über heutige RDS- oder Multi-AZ-Eigenschaften abzuleiten. Die Aussage bleibt historisch: 2011 trat bei einer Teilmenge ein Zustand auf, für den automatischer Failover nicht ausreichte.

Abhängigkeiten wurden außerhalb von AWS sichtbar

Heroku dokumentierte unmittelbar eine weitreichende Störung von Anwendungen auf seiner Plattform. Zeitgenössische Berichte nannten außerdem öffentliche Dienste wie Reddit, Foursquare und Quora. Diese Beispiele belegen die Reichweite von Cloud-Abhängigkeiten: Ein Infrastrukturereignis kann Plattformen treffen, deren eigene Kunden die zugrunde liegende Speicherarchitektur nicht sehen.

Die Namen sind jedoch keine vollständige Opferliste. Sie beweisen auch nicht, dass alle Dienste denselben technischen Fehlerpfad, dieselbe Dauer oder dieselbe Datenfolge erlebten. Heroku liefert als betroffener Plattformbetreiber eine andere Evidenzrolle als AWS: Es kann die eigene Dienstkontinuität beschreiben, nicht aber die internen Ursachen von EBS. Zeitgenössische Medien können sichtbare Auswirkungen und damalige Statusmeldungen einordnen, ersetzen aber kein Betreiber-Postmortem für interne Mechanismen.

Gerade diese Rollentrennung stärkt die Analyse. AWS ist die Primärquelle für Architektur, Ablauf und angekündigte Maßnahmen. Unabhängige Quellen prüfen die Außenwirkung, die technische Einordnung und die Spätphase der Wiederherstellung, ohne zu internen Beweisen umetikettiert zu werden.

Kommunikation ist Teil der Wiederherstellung

Bei lang laufenden Infrastrukturereignissen brauchen Kunden mehr als einen allgemeinen Status. Sie müssen wissen, welche Ressourcen betroffen sind, ob Schreibvorgänge sicher sind, welche Abhängigkeiten noch eingeschränkt sind und wann eine eigene Wiederherstellungsentscheidung sinnvoll wird. Verzögerte oder zu grobe Informationen übertragen Unsicherheit auf jedes nachgelagerte Betriebsteam.

AWS kündigte nach dem Vorfall häufigere Kommunikation an. Diese Maßnahme gehört zur Verantwortungsoberfläche, weil Information Handlungszeit schafft. Sie ist dennoch nicht gleichbedeutend mit einem unabhängigen Nachweis, dass die Verbesserung später vollständig umgesetzt oder dauerhaft wirksam war.

Ein belastbarer Abschluss würde deshalb Kommunikationsmetriken einbeziehen: Zeit bis zur ersten präzisen Eingrenzung, Ressourcengenauigkeit der Meldungen, Konsistenz zwischen Statusseite und Support sowie die Zeit bis zu einer prüfbaren Abschlussanalyse. Ein System gilt nicht allein deshalb als wiederhergestellt, weil die technische Fehlerquote sinkt; die betroffenen Betreiber müssen ihren eigenen Zustand verlässlich bestimmen können.

Was AWS nach eigener Darstellung ändern wollte

AWS nannte mehrere Korrekturen: größere Puffer für Wiederherstellungskapazität, aggressiveres Backoff, die Behebung der Race Condition, bessere Timeouts und Lastabwurf, stärkere Isolation zwischen Availability Zones, automatisierte Wiederherstellungssteuerung, verbesserte Multi-AZ-Werkzeuge und häufigere Statusinformationen.

Die Liste passt zu den beobachteten Verstärkungswegen. Mehr Kapazität adressiert den Replikationssturm; Backoff begrenzt gleichzeitige Anforderungen; Timeouts und Load Shedding schützen den Control Plane; Isolation begrenzt die Ausbreitung; automatisierte, gestufte Erholung verringert das Risiko menschlich koordinierter Massenstarts.

Doch angekündigte Maßnahmen sind Absichten, kein Vollzugsbeweis. Für jede Korrektur braucht es eine überprüfbare Abschlussbedingung: einen Test, eine Messgröße, einen Eigentümer und einen Zeitpunkt für erneute Prüfung. Ohne diese Elemente kann ein Postmortem plausibel klingen und trotzdem offenlassen, ob sich das Risikoprofil tatsächlich verändert hat.

Verantwortung ohne vorschnelle Schuldzuweisung

Die Quellen benennen keine schuldige Einzelperson. Sie belegen auch keine Fahrlässigkeit, Rechtswidrigkeit, regulatorische Verletzung oder konkrete Vertragsverletzung. Eine sachliche Verantwortungsanalyse muss deshalb von moralischer oder juristischer Schuld getrennt bleiben.

AWS kontrollierte die Netzwerkänderung, die EBS-Architektur, Kapazitätspuffer, Backoff, Isolation und die Kommunikation über den Dienstzustand. Damit lag beim Anbieter die Verantwortung, diese Kontrollflächen zu gestalten, zu testen und ihre Wirksamkeit nachzuweisen. Kunden kontrollierten dagegen ihre Anwendungsarchitektur, eigene Backups, Wiederanlaufverfahren, Abhängigkeitsinventare und die Entscheidung, welche zusätzliche geografische oder technische Diversifizierung ihrem Risiko angemessen war.

Diese Verantwortungen sind komplementär, nicht austauschbar. Ein Kunde kann keine internen EBS-Kapazitätsgrenzen reparieren. Ein Anbieter kann nicht jede Anwendungsentscheidung des Kunden treffen. Gute Rechenschaft schafft daher klare Übergabepunkte: Welche Garantien gibt der Dienst? Welche Telemetrie erhält der Kunde? Welche Fehler muss er selbst abfangen? Und wie wird er rechtzeitig informiert, wenn eine Annahme nicht mehr gilt?

Die bleibende Kontrollfrage

Der wichtigste Befund des Ereignisses ist nicht, dass Replikation versagte. Replikation reagierte — aber in einer Weise, die bei massenhaftem Gleichlauf ihre eigene Grundlage erschöpfte. Deshalb muss jede Schutzfunktion einen begrenzten Wiederherstellungsraum besitzen.

Dieser Raum umfasst mindestens vier Elemente: genügend freie Kapazität für ein definiertes Ausfallszenario, Backoff und Priorisierung gegen synchrones Verhalten, Isolation gegen die Belegung größerer Steuerungsressourcen sowie Messpunkte, die den Fortschritt bis zur konsistenten Wiederherstellung zeigen. Die Prüfung sollte nicht nur den Normalbetrieb simulieren. Sie muss den Moment abbilden, in dem viele Komponenten gleichzeitig glauben, sie müssten sich retten.

Der Vorfall von 2011 bleibt damit relevant, ohne als Aussage über die heutige Plattform missbraucht zu werden. Er liefert ein historisch belegtes Muster: Eine Wiederherstellungsfunktion ist erst dann ein belastbarer Schutz, wenn ihre Kapazität, ihr Abbruchverhalten und ihre Ausbreitungsgrenzen unter Stress bekannt sind.

Quellen