Zusammenfassung

  • Die Störung von Amazon S3 im Februar 2017 ist von Bedeutung, weil AWS in seiner eigenen öffentlichen Zusammenfassung einen betrieblichen Befehl beschrieb, der mehr Subsystemkapazität als beabsichtigt entfernte. Erst nach der Wiederherstellung der Index- und Platzierungssubsysteme kehrte der Objektspeicher zum Normalbetrieb zurück.
  • Bei der Rechenschaftsfrage geht es nicht darum, dass ein großer verteilter Dienst niemals ausfallen darf. Es geht darum, wer die praktische Kontrolle über betriebliche Werkzeuge, Schutzvorkehrungen für Mindestkapazitäten, Annahmen zum Neustart, die Erfassung abhängiger Dienste, die Kommunikation zum Servicestatus und die Architekturentscheidungen der Kunden hatte.
  • Die öffentliche Zusammenfassung von AWS nach dem Ereignis ist ungewöhnlich nützlich, weil sie die betroffenen S3-Subsysteme benennt und eine datierte Abfolge der Wiederherstellungsmeilensteine liefert. Dennoch legt sie nicht jedes interne Protokoll, jeden Kundenschaden, jeden dienstspezifischen Rückstau oder jeden vertraglichen Rechtsbehelf offen.
  • Kunden, die die S3-Verfügbarkeit einer einzelnen Region als universelles Fundament betrachteten, mussten eine härtere Kontinuitätslehre ziehen: Eine Ausweichlösung muss im Hinblick auf dieselbe Cloud-Abhängigkeit, dieselbe regionale Konzentration, denselben Statuskanal und dieselben nachgelagerten Dienste getestet werden, die gemeinsam ausfallen können.

Objektspeicher wurde zu einem öffentlichen Abhängigkeitsregister

Amazon S3 wird häufig als dauerhafter Objektspeicher beschrieben, doch der Vorfall vom 28. Februar 2017 machte eine umfassendere Rolle sichtbar. S3 war nicht bloß ein Ort, an dem Kunden Dateien speicherten. Der Dienst bildete ein Abhängigkeitsregister für Websites, mobile Anwendungen, Wege zur Softwarebereitstellung, Analyse-Workloads, Medienauslieferung, Datenaustausch, Kundenportale, Seiten öffentlicher Dienste, Überwachungswerkzeuge und andere AWS-Dienste. Als es in der S3-Region US-EAST-1 zu erhöhten Fehlerraten und nicht verfügbaren Operationen kam, blieben die Auswirkungen nicht auf eine einzelne Speicherschnittstelle beschränkt.

Der Vorfall breitete sich über Architekturen aus, die S3 stillschweigend als Grundvoraussetzung genutzt hatten.

Die öffentliche Zusammenfassung von AWS nach dem Ereignis unter source: aws.amazon.com ist die zentrale Beweisquelle für diesen Fall. Der Zusammenfassung zufolge führte ein autorisiertes Mitglied des S3-Teams um 9:37 Uhr vormittags pazifischer Zeit ein etabliertes Ablaufhandbuch aus, um Kapazität für ein S3-Subsystem zu entfernen, das vom S3-Abrechnungsprozess genutzt wurde. Durch die Befehlseingabe wurde mehr Kapazität entfernt als beabsichtigt.

AWS schrieb, dadurch sei erhebliche Kapazität aus zwei Subsystemen entfernt worden: dem Indexsubsystem, das Metadaten und Informationen zum Speicherort der Objekte in der Region verwaltet, und dem Platzierungssubsystem, das neuen Speicher zuweist. Diese Einordnung ist wesentlich. Der Vorfall wurde nicht als Stromausfall, Glasfaserschaden, Naturkatastrophe oder kundenseitiger Konfigurationsfehler beschrieben. Es handelte sich um ein Ereignis im Bereich der betrieblichen Kontrolle des Anbieters, durch das die Kapazität kritischer interner Subsysteme reduziert wurde.

Der öffentliche Zeitablauf macht den Ausfall anschließend zu einem Rechenschaftsnachweis. AWS zufolge musste das Indexsubsystem neu gestartet werden; dieser Neustart dauerte länger als erwartet, weil die Systeme seit vielen Jahren nicht mehr vollständig neu gestartet worden waren. Laut Zusammenfassung war um 11:54 Uhr vormittags pazifischer Zeit genügend Indexkapazität wiederhergestellt, um GET-, LIST- und DELETE-Anfragen zu unterstützen; diese Operationen waren bis 12:26 Uhr nachmittags wiederhergestellt.

Danach war das Platzierungssubsystem um 1:18 Uhr nachmittags weit genug wiederhergestellt, um mit der Verarbeitung von PUT-Anfragen zu beginnen; um 1:54 Uhr nachmittags waren die PUT-Operationen vollständig wiederhergestellt. Die Unterscheidung zwischen Lesen, Auflisten und Löschen einerseits und der Platzierung von Schreibvorgängen andererseits ist wichtig, weil Kunden „S3“ nicht als einen einzigen abstrakten Schalter erleben. Sie erleben, wie bestimmte Operationen nacheinander ausfallen, wiederhergestellt werden, verzögert reagieren, erneut versucht werden und zum Normalbetrieb zurückkehren.

Diese Abfolge zeigt auch, warum die Rechenschaft für Objektspeicher nicht auf die aggregierte Verfügbarkeit reduziert werden kann. Ein Kunde, der eine statische Website über S3 betreibt, eine Bereitstellungspipeline zum Hochladen von Artefakten nutzt, Objekte in einem Analyseauftrag auflistet und Medien für eine mobile Anwendung abruft, kann jeweils andere Symptome beobachten. Ein statisches Objekt bleibt möglicherweise über einen Cache verfügbar, während ein neuer Upload fehlschlägt. Eine Listenoperation kann vor der Platzierung neuer Objekte wiederhergestellt sein.

Ein nachgelagerter AWS-Dienst kann weiterhin beeinträchtigt sein, weil seine eigene Abhängigkeit von S3 noch nicht bereinigt ist. Eine anbieterweite Wiederherstellungsmeldung ist wertvoll, ersetzt jedoch keine Nachweise zu den Abhängigkeiten auf Kundenebene.

Der S3-Vorfall ist daher ein Fall von Cloud-Abhängigkeit und nicht nur ein Fall von Speicherverfügbarkeit. Kunden erwerben verwaltete Dienste, damit sie nicht selbst für Festplatten, Replikationscode, physische Anlagen und einen großen Teil der Last verteilter Systeme verantwortlich sind. Dieses Geschäft ist vernünftig. Die Abhängigkeit verlagert sich jedoch auf die Werkzeuge des Anbieters, die Regionsgestaltung, die Kommunikation zum Servicestatus, die Kundenarchitektur und die Supportnachweise. Die Frage nach der praktischen Kontrolle ist verteilt.

AWS kontrollierte die Schnittstelle für betriebliche Befehle, interne Schutzvorkehrungen, das Neustartverhalten der Subsysteme, die öffentliche Erklärung und die Reihenfolge der Wiederherstellung. Die Kunden kontrollierten, ob ihre eigenen Systeme eine einzelne Region voraussetzten, ob sie regionsübergreifende Replikation nutzten, ob sie kritische öffentliche Inhalte zwischenspeicherten, ob sie Schreibvorgänge in eine Warteschlange stellen konnten und ob ihre eigenen Statusseiten verfügbar blieben, wenn S3 es nicht war.

Die öffentliche Dokumentation belegt nicht jede Auswirkung auf jeden Kunden. Sie begründet keine rechtliche Feststellung zu Schäden, Fahrlässigkeit, Dienstgutschriften oder einem Versagen bei der Beschaffung. Sie zeigt jedoch, dass eine kleine betriebliche Handlung innerhalb eines Cloud-Anbieters zu einem öffentlichen Rechenschaftstest werden kann, wenn der betroffene Dienst ein verbreitetes Fundament bildet. Die richtige Lehre lautet nicht einfach „Cloud vermeiden“ oder „mehr Cloud nutzen“.

Sie ist präziser: Es muss ermittelt werden, welche Subsysteme und Regionen des Anbieters Kundenabläufe außer Kraft setzen können; Nachweise darüber, wie der Anbieter während des Vorfalls kommuniziert, müssen aufbewahrt werden; und Ausweichwege müssen so gestaltet sein, dass sie genau die Abhängigkeit überstehen, die den Ausfall verursacht hat.

Die Zusammenfassung nach dem Ereignis identifiziert die Kontrollfläche

Das wertvollste Merkmal der AWS-Zusammenfassung zum Ereignis von 2017 ist, dass sie die Kontrollfläche benennt. Auslöser war ein Befehl. Der Befehl wurde von einem autorisierten Bediener ausgeführt. Er war Bestandteil eines Ablaufhandbuchs. Mit ihm sollte eine geringe Kapazitätsmenge entfernt werden. Stattdessen entfernte er mehr Kapazität als beabsichtigt. Diese Kette ist ein Gegenstand der Governance.

Sie wirft die Fragen auf, ob das Werkzeug die gefährliche Aktion zu leicht machte, ob Schutzmechanismen eine Untergrenze für die Mindestkapazität erzwangen, ob menschliche Eingaben vor der Ausführung validiert werden konnten, ob eine schrittweise Entfernung den Wirkungsradius begrenzte und ob die Annahmen zur Wiederherstellung anhand eines vollständigen Neustarts getestet worden waren.

Die AWS-Zusammenfassung nannte zudem Themen der Fehlerbehebung. Demnach hatte S3 Schutzvorkehrungen ergänzt, damit Kapazität langsamer entfernt werden konnte und Werkzeuge verhinderten, dass die Kapazität unter ein erforderliches Mindestniveau fiel. AWS erklärte, andere betriebliche Werkzeuge zur Kapazitätsentfernung zu prüfen und Änderungen vorzunehmen, um die Wiederherstellung kritischer Subsysteme zu beschleunigen. Außerdem nehme S3 Änderungen zur weiteren Partitionierung des Indexsubsystems vor. Das sind keine nebensächlichen Details der Öffentlichkeitsarbeit.

Sie markieren den Unterschied zwischen der Aussage eines Anbieters „Es tut uns leid“ und der Benennung jener Kontrollklasse, die versagt hat.

Aus externer Sicht bleiben die Anbieternachweise dennoch unvollständig. Die Öffentlichkeit kann den genauen Befehl, die Validierung vor der Ausführung, die Genehmigungskette, den Alarmstatus, die Bedienoberfläche, die Werkzeuge zur Rückabwicklung, die Subsystemtopologie und die interne Überprüfung nicht einsehen. Die öffentliche Zusammenfassung belegt nicht, wie jede interne Reparatur getestet wurde. Sie belegt auch nicht die genaue Auswirkung auf jeden Kunden oder jeden abhängigen AWS-Dienst.

Die Zusammenfassung liefert aber genug Informationen, um den Fehler zu klassifizieren: betriebliche Werkzeuge, Subsystemkapazität, Neustartbereitschaft, Begrenzung des Wirkungsradius und Kommunikation zum Servicestatus.

Diese Klassifizierung ist der Ausgangspunkt für die Sorgfaltsprüfung eines Kunden. Ein von S3 abhängiger Kunde sollte nicht nur fragen, ob S3 dauerhaft ist. Er sollte fragen, wie sich sein eigener Workload verhält, wenn sich S3-Operationen wie GET, LIST, DELETE oder PUT unabhängig voneinander verschlechtern. Er sollte prüfen, ob der Workload Leseverfügbarkeit bei gleichzeitiger Nichtverfügbarkeit von Schreibvorgängen toleriert oder ob eine Wiederaufnahme der Schreibvorgänge vor dem Abbau des Rückstaus verkraftet wird.

Er sollte prüfen, ob die Anwendung Wiederholungsversuche sicher ausführt, ob diese die Last verstärken können, ob Objektversionen vor versehentlichem Überschreiben geschützt sind, ob Warteschlangen die Reihenfolge bewahren und ob die Benutzer über das Geschehen informiert werden. Die Kontrollfläche des Anbieters wird zur Nachweis-Checkliste des Kunden.

Die aktuellen öffentlichen Produkt- und Dokumentationsseiten zu AWS S3 liefern den heutigen Kontext für diese Checkliste. Die S3-Serviceseite unter source: aws.amazon.com beschreibt die Dienstfamilie und die Einordnung ihrer Dauerhaftigkeit. Das S3-Benutzerhandbuch unter source: docs.aws.amazon.com bietet den betrieblichen Einstiegspunkt für Buckets, Objekte, Speicherklassen, Zugriffskontrollen und Funktionen.

Die Dokumentation zur S3-Replikation unter source: docs.aws.amazon.com, zur Versionierung unter source: docs.aws.amazon.com und zu Object Lock unter source: docs.aws.amazon.com trifft keine Feststellungen darüber, welche Funktionen ein bestimmter Kunde 2017 genutzt hat. Sie ist relevant, weil sie kundenseitige Kontrollen für Resilienz, Änderungsschutz und Wiederherstellungsnachweise definiert.

Während eines Ausfalls verschwimmt leicht die Grenze zwischen der Kontrolle des Anbieters und jener des Kunden. Kunden können und sollten Vorkehrungen für regionale Ausfälle, zwischengespeicherte Lesezugriffe, Budgets für Wiederholungsversuche, Rückstaukontrolle und regionsübergreifende Kontinuität treffen, sofern der geschäftliche Nutzen dies rechtfertigt. Diese kundenseitigen Kontrollen heben jedoch die Verantwortung des Anbieters für sichere betriebliche Werkzeuge nicht auf. Anbieterbezogene Schutzvorkehrungen bei der Kapazitätsentfernung und die kundenseitige Gestaltung über mehrere Regionen hinweg sind getrennte Nachweisbereiche.

Eine ernsthafte Nachbereitung des Vorfalls sollte sie auseinanderhalten. Sie sollte weder Schwächen der Kundenarchitektur heranziehen, um die Untersuchung der Anbieterkontrollen zu umgehen, noch die Anbieterkontrollen als Entschuldigung für eine ungetestete Abhängigkeitskonzentration des Kunden verwenden.

Diese Trennung ist auch für die Beschaffung nützlich. Ein Cloud-Käufer benötigt nicht jedes interne Detail von AWS, um bessere Fragen zu stellen. Er kann fragen, ob die Anwendung über ein Abhängigkeitsinventar verfügt, ob das Unternehmen weiß, welche Funktionen in einer einzelnen Region von S3 abhängen, ob die Organisation AWS Health und Aktualisierungen zum Servicestatus abonniert hat, ob ihre öffentliche Statusseite von derselben Region abhängt, ob kritische Objekte repliziert oder zwischengespeichert werden und ob Schreibpfade Daten ohne Zustandsbeschädigung in Warteschlangen aufnehmen können. Das sind praktische Fragen.

Sie ergeben sich unmittelbar aus der Kontrollfläche, die durch die AWS-Zusammenfassung offengelegt wurde.

Die Kommunikation zum Servicestatus war Teil des Ausfalls

Der Vorfall von 2017 ist auch deshalb in Erinnerung geblieben, weil die Kommunikation zum Servicestatus selbst Teil der Rechenschaftsfrage wurde. Laut AWS-Zusammenfassung war das AWS Service Health Dashboard beeinträchtigt, weil seine Administrationskonsole S3 in der betroffenen Region nutzte; dadurch verzögerten sich Aktualisierungen zum Status einzelner Dienste. Dieses Detail ist bedeutender als eine bloße Unannehmlichkeit des Dashboards. Ein Statussystem ist eine betriebliche Kontrolle.

Hängt diese Kontrolle von demselben beeinträchtigten Dienst ab, verlieren Kunden genau in dem Moment einen zentralen Entscheidungskanal, in dem sie ihn am dringendsten benötigen.

Die aktuelle AWS-Health-Statusseite unter source: health.aws.amazon.com und der bisherige Einstiegspunkt zum AWS Service Health Dashboard unter source: status.aws.amazon.com sind daher nicht nur Informationslinks. Sie stehen für den öffentlichen Kanal, über den viele Kunden mit der Klassifizierung eines Vorfalls beginnen. Ein Kunde kann mit fehlgeschlagenen Uploads, Zeitüberschreitungen, erhöhten Fehlerraten, leeren Inhalten, blockierten Bereitstellungen oder defekten Dashboards konfrontiert sein.

Die erste Frage lautet, ob das Problem lokal oder anbieterseitig, regional oder global, authentifizierungs- oder netzwerkbedingt oder ein Fehler in einer nachgelagerten Anwendung ist. Ist der Statuskanal des Anbieters langsam, zu allgemein oder selbst beeinträchtigt, verschwenden Kunden Zeit mit der falschen Diagnose.

Die Statuskommunikation muss mehrere praktische Anforderungen erfüllen. Sie sollte den betroffenen Dienst und die Region benennen. Wenn möglich, sollte sie zwischen Operationsklassen unterscheiden. Sie sollte erkennen lassen, ob der Anbieter untersucht, Gegenmaßnahmen ergreift, überwacht oder den Vorfall als behoben betrachtet. Sie sollte abhängige Dienste beschreiben, wenn diese Abhängigkeiten wesentlich sind. Sie sollte über einen Weg verfügbar bleiben, der nicht dieselbe ausgefallene Abhängigkeit teilt. Sie sollte den Verlauf des Vorfalls zur späteren Abstimmung aufbewahren.

Kunden sollten nicht gezwungen sein, Gerüchte, Fragmente aus sozialen Medien oder Benutzerbeschwerden als primäre Belege heranzuziehen.

AWS erkannte einen Teil dieses Problems in der Zusammenfassung nach dem Ereignis an und erklärte, das Service Health Dashboard so geändert zu haben, dass es regionsübergreifend aktualisiert werden könne. Das ist eine konkrete Reparaturbehauptung. Sie belegt keine perfekte künftige Kommunikation, identifiziert aber die Fehlerklasse: Die Statusverwaltung sollte nicht durch dieselbe beeinträchtigte regionale Abhängigkeit blockiert werden. Dies ist auch eine allgemeine Lehre für Kunden.

Wenn die eigene öffentliche Statusseite, die Wissensdatenbank des Kundensupports, der Vorfall-Chat oder das Dashboard für die Geschäftsleitung vollständig von derselben Cloud-Region und demselben Dienst wie das Produkt abhängt, kann die Organisation während des Ausfalls ihre Stimme verlieren.

Das Kommunikationsproblem wirkt sich auch auf die Bewertung des Schweregrads aus. Ein Anbieter kann einen Dienst aus Sicht seiner eigenen Telemetrie als beeinträchtigt bezeichnen. Ein Kunde kann einen vollständigen Ausfall erleben, weil die betroffene Operation auf dem kritischen Pfad liegt. Ein anderer Kunde kann nur begrenzte Auswirkungen feststellen, weil er zwischengespeicherte Inhalte ausliefert oder Schreibvorgänge in eine Warteschlange stellt. Eine gute Statusaufzeichnung sollte nicht vorgeben, jeden Kundenablauf zu kennen.

Sie sollte Kunden jedoch ausreichend Informationen liefern, damit diese schnell ihre eigene Schweregradeinstufung vornehmen können. Der S3-Vorfall zeigt, warum Details auf Operationsebene wichtig sind: Lesen, Auflisten, Löschen und die Platzierung von Schreibvorgängen wurden nicht zum selben Zeitpunkt wiederhergestellt.

Für kleine und mittlere Unternehmen kann die Genauigkeit des Status darüber entscheiden, ob Kontinuitätsverfahren überhaupt angewendet werden. Ein kleiner Einzelhändler, eine Schule, eine Gesundheitseinrichtung, eine lokale Medienseite oder ein Software-Startup verfügt möglicherweise nicht über ein großes Betriebsteam. Es kann sich auf Statusseiten des Anbieters und Zustandsprüfungen verwalteter Dienste verlassen, um zu entscheiden, ob Bereitstellungen angehalten, die Inhaltsauslieferung umgeschaltet, Kunden gewarnt, ein Start verschoben oder Wiederholungsstürme gestoppt werden sollen.

Ist die öffentliche Statusaufzeichnung verspätet oder vage, werden die Diagnosekosten auf den Kunden verlagert. Diese Kostenverlagerung ist Teil der Rechenschaftsfrage, auch wenn sie niemand beabsichtigt hat.

Für Nutzer des öffentlichen Sektors kann eine andere Tragweite bestehen. Die Website einer Behörde, ein Datenfeed, ein Beschaffungsportal, ein Archiv für Notfallinformationen, ein Open-Data-Dienst oder ein Auftragnehmersystem kann auf Objektspeicher angewiesen sein. Nicht jede solche Nutzung ist kritisch. Ist ein Dienst jedoch an die Öffentlichkeit gerichtet, benötigt die Organisation einen Kommunikationsweg, der die Beeinträchtigung des Anbieters übersteht. Eine Statusmeldung des Anbieters hilft, doch die Behörde braucht weiterhin eine eigene Erklärung für die Bürger und eine Ausweichlösung.

Der AWS-Vorfall erinnert daran, dass die Kontinuität im öffentlichen Sektor die Aufnahme von Cloud-Statusmeldungen, unabhängige lokale Kommunikation sowie Nachweise darüber umfassen sollte, welche Dienste geprüft wurden und welche nicht betroffen waren.

Kundenseitige Ausweichlösungen müssen gegen gemeinsame Abhängigkeiten getestet werden

Ausweichlösungen werden häufig zu beiläufig beschrieben. Ein Kunde kann behaupten, er könne einen anderen Bucket, eine andere Region, einen anderen Anbieter, einen lokalen Cache, ein Content Delivery Network oder manuelle Abläufe nutzen. Die Rechenschaftsfrage lautet, ob diese Ausweichlösung denselben Fehler übersteht. Ein anderer Bucket in derselben betroffenen Region hilft möglicherweise nicht. Ein repliziertes Objekt ist womöglich nutzlos, wenn die Anwendung in eine Region schreibt und andernorts über keinen getesteten Lesepfad verfügt.

Ein Cache für die Inhaltsauslieferung kann bei öffentlichen Inhalten helfen, nicht aber bei neuen Uploads, privaten Daten, Listenoperationen oder dem Workflow-Status. Ein zweiter Anbieter hilft möglicherweise nicht, wenn Datensynchronisierung, Identität, Compliance-Genehmigung und Anwendungsrouting niemals getestet wurden.

Die S3-Dokumentation bietet viele kundenseitige Werkzeuge für Resilienz, doch Werkzeuge werden nur dann zu Kontrollen, wenn sie implementiert, getestet und gesteuert werden. Multi-Region Access Points unter source: docs.aws.amazon.com können bei bestimmten Architekturen dazu beitragen, Anfragen regionsübergreifend zu leiten. Die Dokumentation zu Replication Time Control unter source: docs.aws.amazon.com erläutert eine Replikationsfunktion mit zeitgebundenen Erwartungen. S3 Storage Lens unter source: docs.aws.amazon.com kann die Transparenz über Speichernutzung und -aktivität unterstützen.

Die Dokumentation zu Ereignisbenachrichtigungen unter source: docs.aws.amazon.com kann dabei helfen, Objektereignisse in Workflows einzubinden. Keines dieser Dokumente belegt, dass ein Kunde 2017 über Resilienz verfügte. Sie zeigen das Kontrollvokabular, das ein Kunde heute anwenden sollte.

Entscheidend ist die Analyse gemeinsamer Fehlerursachen. Hängt die Anwendung für Inhalte, Bereitstellungsartefakte, Protokolle und ihre eigene Statusseite von S3 ab, handelt es sich nicht um getrennte Risiken. Sie bilden einen einzigen Abhängigkeitsverbund. Nutzt die Organisation S3 zur Speicherung der für die Reaktion auf Vorfälle benötigten Dateien, kann der Ausfall die Behebung verzögern. Befindet sich eine Sicherungskopie in derselben Region und unterliegt sie denselben Zugangsdaten, ist sie möglicherweise nicht unabhängig genug.

Verlässt sich der Kunde auf einen AWS-Dienst, der seinerseits in derselben Region von S3 abhängt, stellt eine Umschaltung nur auf Anwendungsebene den Workflow möglicherweise nicht wieder her. Das Abhängigkeitsinventar muss dem tatsächlichen Pfad folgen und nicht den Anbieternamen in einer Beschaffungstabelle.

Tests sollten operationsspezifische Ausfälle einbeziehen. Können Benutzer weiterhin kritische Inhalte lesen, wenn PUT fehlschlägt? Kann das Unternehmen Schreibvorgänge für später in eine Warteschlange stellen, ohne die Reihenfolge zu verlieren oder den Status für die Duplikatverarbeitung zu beschädigen? Kann die Anwendung kontrolliert mit Leistungseinbußen weiterarbeiten, wenn LIST langsam oder nicht verfügbar ist? Können Supportmitarbeiter zwischen fehlenden Inhalten und einem fehlgeschlagenen neuen Upload unterscheiden? Kann die Website eine hilfreiche Meldung anzeigen, wenn private Inhalte nicht verfügbar sind?

Kann eine Bereitstellung angehalten werden, ohne den Produktionsstatus zu beschädigen? Lassen sich Abrechnungs-, Analyse- und Compliance-Protokolle nach dem Vorfall abgleichen? Diese Fragen sind nicht ungewöhnlich. Sie ergeben sich aus der Operationsabfolge in der AWS-Zusammenfassung.

Das Verhalten bei Wiederholungsversuchen verdient besondere Aufmerksamkeit. Clients verteilter Systeme wiederholen Anfragen häufig nach Fehlern, und solche Wiederholungsversuche können nützlich sein. Sie können aber auch die Last verstärken, die Kosten erhöhen, doppelte Arbeit erzeugen und Auswirkungen auf Benutzer verbergen. Der Artikel der AWS Builders Library zu Zeitüberschreitungen, Wiederholungsversuchen und Backoff mit Jitter unter source: aws.amazon.com ist relevant, weil er erläutert, wie die Gestaltung von Wiederholungsversuchen Überlastung und synchronisierte Wiederholungsstürme verhindern kann.

Der Artikel zur Vermeidung von Ausweichlösungen in verteilten Systemen unter source: aws.amazon.com ist ebenfalls relevant, weil er davor warnt, dass selten erprobte Ausweichpfade unzuverlässig sein können. Dies sind aktuelle technische Referenzen von AWS und keine Feststellungen zum Vorfall von 2017. Sie sind nützlich, weil sie dem Fehlermuster entsprechen, das Kunden bei ihrer Gestaltung berücksichtigen müssen.

Gleiches gilt für den Wirkungsradius. Der Artikel der AWS Builders Library zur Verringerung des Auswirkungsumfangs durch zellenbasierte Architektur unter source: aws.amazon.com und der Artikel zur statischen Stabilität mithilfe von Availability Zones unter source: aws.amazon.com stellen eine öffentliche Begrifflichkeit für die Gestaltung von Systemen bereit, in denen Fehler eingegrenzt werden. S3 selbst ist ein regionaler Dienst, und Kundenarchitekturen unterscheiden sich.

Das allgemeine Rechenschaftskonzept ist jedoch klar: Ein System, das ohne getestete Eingrenzungsgrenze von einer einzelnen gemeinsam genutzten Komponente abhängt, kann einen Anbietervorfall in einen wesentlich umfassenderen Kundenvorfall verwandeln.

Das bedeutet nicht, dass jeder Kunde teure Aktiv-Aktiv-Systeme über mehrere Regionen hinweg aufbauen sollte. Kosten, Komplexität, Datenkonsistenz, Compliance, Latenz, Fachwissen der Mitarbeiter und betriebliche Risiken sind allesamt relevant. Eine Website mit geringem Risiko kann Verzögerungen akzeptieren. Eine kritische Seite für öffentliche Dienste, ein zahlungsunterstützender Workflow oder ein Weg zur Softwareverteilung kann stärkere Kontrollen benötigen. Die Rechenschaftsakte sollte der geschäftlichen Kritikalität entsprechen.

Sie sollte jedoch nicht so tun, als sei eine von einem verwalteten Dienst in einer einzelnen Region abhängige Architektur dasselbe wie eine getestete Kontinuitätsgestaltung.

Abhängige AWS-Dienste machten den Wirkungsradius sichtbar

Die S3-Störung beeinträchtigte auch andere AWS-Dienste, die in US-EAST-1 von S3 abhingen. Laut AWS-Zusammenfassung waren einige Dienste betroffen und wurden wiederhergestellt, nachdem die S3-Operationen wiederhergestellt waren. Das ist wichtig, weil Cloud-Kunden häufig Dienste desselben Anbieters kombinieren und dabei annehmen, dass verwaltete Dienste für ihre Zwecke ausreichend unabhängig voneinander ausfallen. Manchmal ist das der Fall. Manchmal teilen sie eine Abhängigkeit, die bis zu einem Vorfall nicht erkennbar ist.

Die Rolle von S3 innerhalb des AWS-Ökosystems machte das Ereignis von 2017 zu einer Lehre über die Erfassung von Dienstabhängigkeiten.

Die allgemeinen Architektur- und Betriebsmaterialien von AWS helfen bei dieser Einordnung. Die Zuverlässigkeitssäule des AWS Well-Architected Framework unter source: docs.aws.amazon.com betont die Gestaltung von Workloads für Fehlerbehebung, Skalierung und Änderungsmanagement. Die AWS-Leitlinien zur Resilienz unter source: aws.amazon.com liefern die Begrifflichkeit des Anbieters zum Thema Resilienz.

Der Artikel der Builders Library zur Implementierung von Zustandsprüfungen unter source: aws.amazon.com ist relevant, weil solche Prüfungen nur dann nützlich sind, wenn sie die Abhängigkeiten widerspiegeln, die das tatsächliche Benutzererlebnis bestimmen. Ein Dienst kann auf einer Ebene gesund erscheinen, während genau die vom Benutzer benötigte Speicheroperation fehlschlägt.

Die Erfassung von Abhängigkeiten muss konkret sein. Ein Kunde sollte wissen, ob Anwendungsinhalte, Protokolle, Sicherungen, Bereitstellungspakete, Eingaben für maschinelles Lernen, Supportanhänge, Benutzer-Uploads, statische Websites, öffentliche Downloads und Analyseaufträge alle in einer einzigen Region auf S3 angewiesen sind. Er sollte wissen, welche von AWS verwalteten Dienste in seiner Architektur S3 nutzen oder durch die S3-Verfügbarkeit beeinträchtigt werden. Er sollte wissen, welche Abhängigkeiten über seine eigene Telemetrie sichtbar sind und welche nur über den Anbieterstatus.

Er sollte wissen, welcher Geschäftsprozess zum Stillstand kommt, wenn eine einzelne Objektspeicheroperation nicht verfügbar ist.

Diese Art der Erfassung ist oft weniger prestigeträchtig als eine Architektur über mehrere Regionen hinweg. Sie ist zudem unmittelbar nützlicher. Viele Vorfälle beginnen mit Verwirrung: Benutzer melden Fehler, Techniker sehen verstreute Fehlermeldungen, Dashboards widersprechen einander und Teams verfolgen Symptome. Eine Abhängigkeitskarte verkürzt diese Phase. Sie zeigt dem Team, dass fehlgeschlagenes Laden von Bildern, defekte Exporte, Bereitstellungsfehler und blockierte Analysen möglicherweise dieselbe Ursache haben. Außerdem verhindert sie Überreaktionen.

Zeigt die Karte, dass ein Kundensupportsystem nicht vom betroffenen S3-Pfad abhängt, kann die Organisation diesen Dienst weiterbetreiben und die Kundenkommunikation aufrechterhalten.

Auf Anbieterseite besteht eine parallele Pflicht. Ein Cloud-Anbieter sollte verstehen, welche internen Dienste von einem kritischen Dienst abhängen und in welcher Reihenfolge die Wiederherstellung erfolgen muss. Im Jahr 2017 mussten das Index- und das Platzierungssubsystem von S3 wiederhergestellt werden, bevor das normale Anfrageverhalten zurückkehrte. Andere AWS-Dienste mussten anschließend ihre eigenen Abhängigkeitsfolgen bereinigen. Öffentliche Kunden können nicht die gesamte Abfolge einsehen, daher haben der Anbieterstatus und die Zusammenfassung nach dem Ereignis zusätzliches Gewicht.

Sie ersetzen für die Öffentlichkeit die Sichtbarkeit der Infrastruktur.

Die öffentlichen Belege dürfen nicht überinterpretiert werden. Außenstehenden wird nicht mitgeteilt, welcher konkrete AWS-Dienst zu welchem Zeitpunkt welche genaue interne Abhängigkeit hatte oder welcher Kunde am stärksten betroffen war. Sie belegen jedoch die Art des Problems. Ein Cloud-Ökosystem kann gemeinsame interne Abhängigkeiten aufweisen, die für die Kundenkontinuität relevant sind. Das genügt, um gründlichere Abhängigkeitsprüfungen sowohl durch Anbieter als auch durch Käufer zu rechtfertigen.

Reparaturnachweise sollten als Kontrollbehauptungen behandelt werden

Die AWS-Zusammenfassung nach dem Ereignis enthielt Reparaturbehauptungen: langsamere Kapazitätsentfernung, Schutzvorkehrungen in Werkzeugen, die ein Unterschreiten der Mindestkapazität verhindern, Prüfungen betrieblicher Werkzeuge, Arbeiten zur schnelleren Wiederherstellung kritischer Subsysteme, eine weitere Partitionierung des Indexsubsystems und Änderungen am Service-Health-Dashboard. Diese Aussagen sollten als Kontrollbehauptungen gelesen werden. Jede davon impliziert ein überprüfbares Kontrollziel. Eine langsamere Entfernung verringert das Risiko eines plötzlichen Kapazitätseinbruchs.

Schutzvorkehrungen für Mindestkapazitäten begrenzen gefährliche Bedienereingaben. Werkzeugprüfungen suchen andernorts nach ähnlichen Gefahren. Wiederherstellungsarbeiten prüfen Annahmen zum Neustart. Partitionierung verringert den Wirkungsradius. Die Unabhängigkeit des Status-Dashboards verbessert die Kommunikation.

Die Öffentlichkeit erhält nicht die vollständigen Testnachweise für diese Kontrollen. Das ist für den internen Betrieb eines Anbieters normal. Kunden und Prüfer können die Behauptungen dennoch nutzen, um ihre eigene Prüfung zu gestalten. Erklärt ein Anbieter, dass Werkzeuge zur Kapazitätsentfernung nun Grenzwerte erzwingen, kann ein Käufer fragen, wie der Anbieter künftige betriebliche Vorfälle kommuniziert und ob eine vergleichbare Sprache zu Schutzvorkehrungen in späteren Zusammenfassungen erscheint.

Erklärt ein Anbieter, ein Subsystem sei weiter partitioniert worden, können Kunden fragen, ob der Servicestatus Regionen und Operationsklassen nun deutlich genug unterscheidet. Erklärt ein Anbieter, seine Dashboard-Werkzeuge geändert zu haben, können Kunden testen, ob ihre eigene Statusüberwachung Aktualisierungen über mehrere Kanäle empfängt.

Der Artikel der AWS Builders Library zur Automatisierung sicherer, unbeaufsichtigter Bereitstellungen unter source: aws.amazon.com ist relevant, weil er das weiter gefasste technische Vokabular von AWS zu Änderungssicherheit, Automatisierung, Beobachtungszeit, Alarmen und Rückabwicklung zeigt. Beim S3-Vorfall von 2017 handelte es sich nicht um ein gewöhnliches Problem einer kundenbezogenen Bereitstellung, er folgt jedoch derselben Governance-Logik: Gefährliche Änderungen benötigen automatisierte Sicherheitsprüfungen, eine schrittweise Wirkung, schnelle Erkennung und getestete Rückabwicklung oder Wiederherstellung.

Ein manuelles Ablaufhandbuch wird nicht allein dadurch sicher, dass es etabliert ist. Es wird sicherer, wenn Werkzeuge jene Einschränkungen durchsetzen, die Menschen andernfalls übersehen könnten.

Reparaturnachweise sollten auch kundenspezifisch sein. Ein Kunde sollte seine Prüfung nicht mit „AWS hat S3 repariert“ beenden. Er sollte fragen, welche internen Anwendungen ausfielen, welche Benutzer betroffen waren, welche Wiederholungsversuche ausgeführt wurden, welche Daten verzögert waren, welche Statusmeldungen versandt wurden, welche Abhängigkeiten neu erfasst und welche Architekturänderungen vorgenommen oder verworfen wurden. Einige Kunden können vernünftigerweise entscheiden, dass keine wesentliche Änderung gerechtfertigt ist.

Andere entscheiden sich womöglich für regionsübergreifende Replikation, zwischengespeicherte öffentliche Inhalte, unabhängiges Status-Hosting, eine Warteschlangengestaltung oder alternative betriebliche Ablaufhandbücher. Es geht nicht darum, dass jeder Vorfall maximale Redundanz erfordert. Entscheidend ist, dass die Entscheidung auf Nachweisen beruht.

Vorstände sollten bei einem vagen Abschluss besonders skeptisch sein. „Der Anbieter hat den Betrieb wiederhergestellt“ ist keine lokale Kontrolle. „Wir wissen jetzt, dass Produktbilder, Bereitstellungsartefakte und Statusseiten alle von einer S3-Region abhingen, und haben die Statusseite und kritische Inhalte auf einen unabhängigen Pfad verschoben“ ist eine Kontrolle. „Wir haben das Einreihen von Schreibvorgängen bei Nichtverfügbarkeit von S3 PUT getestet“ ist eine Kontrolle. „Wir haben AWS Health abonniert und eine lokale Korrelation für Fehler bei S3-Operationen eingerichtet“ ist eine Kontrolle.

„Wir haben das Restrisiko für unkritische Uploads akzeptiert“ ist eine Governance-Entscheidung. Der Vorfall von 2017 gibt Organisationen das Vokabular, um diese Unterscheidungen vorzunehmen.

Die Nachweisakte des Kunden sollte denselben Ausfall überstehen

Die nützlichste Reaktion eines Kunden nach einem Vorfall der S3-Klasse ist eine Nachweisakte, die den von ihr beschriebenen Vorfall überstehen kann. Das bedeutet, dass die Organisation nicht sämtliche Vorfallverfahren, Kontaktlisten, Entwürfe für Statusmeldungen, Architekturdiagramme, Wiederherstellungsskripte und aktuellen Abhängigkeitskarten ausschließlich im betroffenen Dienst oder in der betroffenen Region aufbewahren sollte. Werden die zur Koordinierung der Reaktion erforderlichen Nachweise in demselben ausfallenden Objektspeicherpfad gespeichert, nimmt der Vorfall sowohl den Dienst als auch die Karte außer Betrieb.

Eine ausgereifte Kontinuitätsgestaltung hält einen kleinen Satz von Vorfallnachweisen auf einem separaten Pfad mit bekannten Zugriffsregeln bereit.

Diese Akte sollte mit Abhängigkeitsbezeichnungen beginnen, die auch Nichtfachleute verstehen. „S3“ ist zu allgemein. Eine bessere Aufzeichnung trennt öffentliche statische Inhalte, Kunden-Uploads, private Anhänge, Bereitstellungsartefakte, Anwendungsprotokolle, Sicherungsexporte, Analyseeingaben, Datensätze für maschinelles Lernen, Compliance-Archive und die eigene Statuskommunikation der Organisation. Für jede Abhängigkeit sollten Region, Operationstyp, geschäftlicher Verantwortlicher, vertretbare Verzögerung, Ausweichroute und der nach der Wiederherstellung benötigte Nachweis angegeben werden.

Dadurch wird die Nachbereitung des Vorfalls betrieblich statt symbolisch.

Die Akte sollte auch den zeitlichen Ablauf bewahren. Während eines Ausfalls erinnern sich Teams häufig an die erste Beschwerde, den ersten Alarm, die erste Anbietermeldung, die erste Behelfslösung und den Zeitpunkt, zu dem keine Benutzerbeschwerden mehr eingingen. Diese Erinnerungen sind nützlich, aber schwach. Eine belastbarere Aufzeichnung bewahrt Zeitstempel aus Anwendungsprotokollen, Statusseiten des Anbieters, gegebenenfalls AWS-Health-Ereignissen, Supporttickets, Vorfall-Chats, Kundenmitteilungen und Prüfungen nach der Wiederherstellung. Die Zeitstempel müssen nicht perfekt sein, um wertvoll zu sein.

Sie müssen ausreichen, um zu zeigen, ob die lokale Erkennung verspätet war, ob die Anbieterkommunikation verspätet war, ob die Aktivierung der Ausweichlösung verzögert wurde und ob die Wiederherstellung verifiziert statt nur angenommen wurde.

Die Akte sollte Datenintegrität und Dienstkontinuität voneinander unterscheiden. Der S3-Vorfall von 2017 war eine Dienststörung und kein öffentlich dokumentierter Datendiebstahl. Das bedeutet nicht, dass für jeden Kunden dasselbe Risiko bestand. Einige Kunden mussten wissen, ob verzögerte Schreibvorgänge erneut versucht wurden, ob doppelte Anfragen wiederholte Objekte erzeugten, ob veraltete Objekte ausgeliefert wurden, ob Protokolle fehlten, ob Bereitstellungsartefakte nur teilweise hochgeladen wurden oder ob benutzerbezogene Transaktionen abgeglichen werden mussten.

Ein Dienst kann wiederhergestellt sein, während beim Kunden noch Bereinigungsarbeiten ausstehen. Werden diese Aspekte als ein einziges Ereignis behandelt, bleibt genau die Arbeit verborgen, die Benutzer tatsächlich schützt.

Schließlich sollte die Akte abgelehnte Kontrollen festhalten. Nicht jede Organisation wird sich für eine Aktiv-Aktiv-Gestaltung über mehrere Regionen hinweg entscheiden. Manche werden zu dem Schluss kommen, dass bei einem Workflow mit geringer Kritikalität Kosten und Komplexität den Nutzen übersteigen. Dies ist eine legitime Governance-Entscheidung, sofern sie ausdrücklich getroffen wird. Schwach ist dagegen eine stillschweigende Akzeptanz: keine Abhängigkeitskarte, kein Test, kein Verantwortlicher, keine Ausweichlösung und keine Aufzeichnung darüber, warum das Risiko akzeptiert wurde.

Die S3-Störung von 2017 bleibt nützlich, weil sie Organisationen ein konkretes Fehlermuster liefert, an dem sie solche Entscheidungen ausrichten können.

Die Nachweisakte sollte zudem einen Schritt zum Abgleich der Wiederherstellung enthalten. Nachdem S3 zum Normalbetrieb zurückgekehrt ist, muss ein Kunde weiterhin belegen, dass sich seine in Warteschlangen eingereihten Schreibvorgänge, verzögerten Lesezugriffe, fehlgeschlagenen Uploads, unvollständigen Berichte, statischen Inhalte und benutzerbezogenen Workflows in einem korrekten Zustand befinden. Die Wiederherstellung des Anbieters belegt nicht automatisch die Wiederherstellung beim Kunden.

Ein Rückstau kann in falscher Reihenfolge abgearbeitet werden, eine Wiederholungsschleife kann doppelte Objekte erzeugen, eine zwischengespeicherte Seite kann einen veralteten Inhalt verbergen und ein Supportworkflow kann weiterhin ausfallen, nachdem die Kernabhängigkeit wieder intakt ist. Der Abgleichschritt sollte die Aufzeichnungen benennen, die den lokalen Abschluss belegen: Warteschlangentiefe, erneute Ausführung fehlgeschlagener Aufträge, Objektzahlen, gegebenenfalls Prüfsummen von Schreibvorgängen, Trends bei Benutzerbeschwerden, Prüfung der Bereitstellungsartefakte und Abschluss der Statusmeldung.

Diese Nachweise bewahren den Kunden davor, den Erfolg zu früh auszurufen.

Für Anbieter gilt intern derselbe Gedanke. Wenn ein kritisches Subsystem wiederhergestellt ist, können abhängige Dienste weiterhin Aufholarbeiten, Cache-Neuaufbauten, eine Glättung von Wiederholungsversuchen oder verzögerte, für Kunden sichtbare Zustandsprüfungen benötigen. Eine Zusammenfassung nach dem Ereignis, die zwischen der Wiederherstellung des Anbietersubsystems und jener abhängiger Dienste unterscheidet, vermittelt Kunden ein realistischeres Bild der Wiederinbetriebnahme. Sie hilft Kunden außerdem, ihre eigenen Tests zu gestalten.

Die Rechenschaftslehre lautet, dass die Wiederherstellung von Abhängigkeiten eine Abfolge und kein Schalter ist.

Nachweisakte für Leser

Dieser Artikel verwendet die folgenden öffentlichen Quellen als Nachweisakte für die Störung von S3 US-EAST-1, die AWS-Statuskommunikation, den Kontext des S3-Dienstes, kundenseitige Resilienzkontrollen und die Gestaltung verteilter Systeme für Fehlerfälle. Quellen des Anbieters werden als Beleg dafür behandelt, was AWS öffentlich erklärte und wie AWS aktuelle Dienste dokumentiert. Sie gelten nicht als unabhängiger Beweis für jedes interne Protokoll, jede Kundenauswirkung, jeden vertraglichen Rechtsbehelf oder jedes Ergebnis einer internen Prüfung.

Fragen für die Prüfung durch den Vorstand

Ein Vorstand oder Risikoausschuss sollte nicht nur fragen, ob AWS S3 im Jahr 2017 von einem Ausfall betroffen war. Er sollte fragen, welche aktuellen Geschäftsprozesse von S3 abhängen, welche Regionen sie nutzen, welche Operationen kritisch sind, welche Inhalte oder Workflows über unabhängige Ausweichlösungen verfügen, welche Statuskanäle während eines Cloud-Vorfalls verfügbar bleiben und welche lokale Telemetrie Auswirkungen und Wiederherstellung belegen kann. Die Antwort sollte datiert, überprüfbar und an die geschäftliche Kritikalität gebunden sein.

Die Prüfung sollte fünf Nachweisbereiche trennen. Der erste Bereich umfasst Anbieternachweise: die Zusammenfassung von AWS nach dem Ereignis, aktuelle Statuskanäle und öffentliche Resilienzmaterialien. Der zweite umfasst Anwendungsnachweise: lokale Protokolle, Anfragefehler, betroffene Operationen, Verhalten von Warteschlangen, Auswirkungen auf Benutzer und Abbau des Rückstaus. Der dritte umfasst Architekturnachweise: Replikation, Caching, Gestaltung über mehrere Regionen hinweg, Richtlinien für Wiederholungsversuche und unabhängige Kommunikation.

Der vierte umfasst Governance-Nachweise: wer das Restrisiko akzeptiert hat, wer für Tests von Ausweichlösungen verantwortlich ist und wer entscheidet, wann ein Dienst lokal wiederhergestellt ist. Der fünfte Bereich betrifft die Kundenkommunikation: was Benutzern, Behörden, Mitarbeitern oder Gegenparteien wann mitgeteilt wurde.

Für diesen konkreten Fall bleibt die entscheidende Frage: Wer hatte die praktische Kontrolle über betriebliche Befehle, Schutzvorkehrungen für Subsystemkapazitäten, die regionale Konzentration, die Erfassung von Dienstabhängigkeiten, die kundenseitige Ausweicharchitektur, die Sichtbarkeit des Status und den Nachweis, dass die Wiederherstellung des Objektspeichers auch die abhängigen Dienste wiederhergestellt hat? Eine vollständige Antwort sollte AWS-Kontrollen, Kundenkontrollen, Nachweislücken, betroffene Zielgruppen und die Reparaturnachweise benennen, die eine künftige Entscheidung über Cloud-Beschaffung oder Architektur verändern würden.