7 Lehren aus dem AWS-Ausfall: Kosten und Konsequenzen

Eine Woche nach dem gravierenden AWS-Ausfall lässt sich inzwischen gut nachvollziehen, welche Fehler zu dem folgenreichen Absturz geführt haben, der nach Ansicht eines ehemaligen Topmanagers "unvermeidlich" war. Ersten Risikoanalysen zufolge könnte der Vorfall AWS und die Versicherungen mehr als eine halbe Milliarde US-Dollar kosten.

Vergangene Woche hatte ein ursprünglich regionaler Ausfall bei AWS durch eine Folgekaskade weltweit Tausende Unternehmen und Millionen Menschen in Mitleidenschaft gezogen. Während die Folgen im privaten Umfeld bei allem persönlichen Ärger meist gut zu verschmerzen waren, weil etwa Webseiten und Onlinedienste nicht erreichbar waren, hatten Unternehmen oft deutlich heftiger an den Problemen zu knabbern, weil ihnen etwa Teile ihrer Infrastruktur wegbrachen oder wichtige produktive Lösungen und Daten nicht mehr verfügbar waren.

"Wir entschuldigen uns für die Auswirkungen, die dieses Ereignis für unsere Kunden hatte", erklärte AWS in seinem Nachbericht über die Ergebnisse des Ausfalls und die Ursachen. Man wisse, dass dieses Ereignis viele Kunden erheblich beeinträchtigt habe und verspreche: "Wir werden alles in unserer Macht Stehende tun, um aus diesem Ereignis zu lernen und unsere Verfügbarkeit noch weiter zu verbessern."

Auch CRN hat sich intensiv mit dem Vorfall beschäftigt und fasst im Folgenden die wichtigsten Fakten, Lehren und Erkenntnisse aus dem AWS-Ausfall zusammen, die jeder Amazon-Kunde, -Partner und -Nutzer wissen sollte. Dabei geht es genauso um die technischen Ursachen, wie um Versäumnisse einiger Anbieter und auch organisatorische Defizite bei den Betroffenen.

Nr. 1: CyberCube schätzt Verluste auf bis zu 581 Millionen US-Dollar

Der Anbieter von Cybersicherheits-Risikoanalysen CyberCube gibt in einer ersten Abschätzung der Folgen und versicherungsfähigen Kosten des AWS-Ausfalls an, dass er mehr als 2.000 große Unternehmen und insgesamt rund 70.000 Unternehmen betroffen habe. Deutlich schwieriger gestaltet sich die Einschätzung der daraus resultierenden Schäden, da diese erst noch aufgearbeitet werden müssen und eventuell im weiteren Verlauf erst detaillierter zu klären sein wird, für welche Kunden und Ausfälle Amazon überhaupt in Haftung genommen werden kann.

In seiner vorläufigen Schätzung gibt CyberCube deshalb die enorme Spanne zwischen 38 und 581 Millionen US-Dollar an. Dabei gehen die Risikoexperten davon aus, dass AWS den betroffenen Unternehmen voraussichtlich unkompliziert die Ausfallzeiten erstatten wird, um so die versicherten Schäden zu begrenzen und Rechtsstreitigkeiten zu verhindern. Gleichzeitig erwartet CyberCube, dass viele Kunden aufgrund der kurzen Ausfallzeit von weniger als einem Tag möglicherweise überhaupt keine Ansprüche geltend machen werden. Das erklärt auch die äußerst niedrige untere Schwelle der Berechnung des potenziellen Schadens. Auf dieser Basis erwartet der Risikoanalyst nur geringe bis moderate Auswirkungen auf Cyber-Versicherer, wobei die meisten Schäden wahrscheinlich am unteren Ende der von CyberCube prognostizierten Spanne liegen werden.

Nr. 2: Kleiner Fehler, große Wirkung

Am 20. Oktober um ca. 2:48 Uhr ET (8:48 Uhr deutscher Zeit) führte ein kritischer Fehler im DNS-Verwaltungssystem von DynamoDB zu dem etwa 15-stündigen Ausfall, von dem letztendlich Millionen von Menschen betroffen waren. Die Ursache dafür war ein eigentlich banaler Vorgang: Zwei automatisierte Systeme wollten gleichzeitig dieselben Daten aktualisieren. Laut AWS lag das Problem konkret darin, dass die zwei unterschiedlichen Programme gleichzeitig versuchten, denselben DNS-Eintrag zu schreiben, was zu einem leeren DNS-Eintrag für den regionalen Endpunkt des Dienstes führte.

Diese Fehleranfälligkeit wurde durch einen "latenten Defekt" im automatisierten DNS-Verwaltungssystem des Dienstes ausgelöst, das laut Amazon steuert, wie Benutzeranfragen an Server weitergeleitet werden. Im vorliegenden Fall führte dies zur versehentlichen Löschung aller IP-Adressen für den regionalen Endpunkt des Datenbankdienstes. Damit legte das DNS-Problem die DynamoDB-Datenbank von AWS lahm, was einen Dominoeffekt auslöste, der sich auf viele AWS-Dienste wie EC2 und den Network Load Balancer auswirkte.

Nr. 3: Untersuchung der Ursachen für den DNS-Ausfall bei DynamoDB

Amazon gab an, dass der Ausfall durch eine "Race Condition" im automatisierten DNS-Managementsystem von DynamoDB verursacht wurde, wodurch ein leerer DNS-Eintrag für den regionalen Endpunkt des Dienstes zurückblieb. Das DNS-Managementsystem von Amazon besteht aus zwei separaten Komponenten: einem DNS Planner, der den Zustand des Load Balancers überwacht und DNS-Pläne erstellt, und einem DNS Enactor, der Änderungen über Amazon Route 53 übernimmt.

Die Race Condition trat laut Amazon auf, als ein DNS Enactor "ungewöhnlich hohe Verzögerungen" erlebte, während der DNS Planner weiterhin neue Pläne generierte. Ein zweiter DNS Enactor begann dann mit der Anwendung der neueren Pläne und führte einen Bereinigungsprozess durch, gerade als der erste Enactor seinen verzögerten Lauf abgeschlossen hatte. Durch diese Bereinigung wurde der ältere Plan gelöscht, wodurch sofort alle IP-Adressen für den regionalen Endpunkt entfernt wurden und das System in einen inkonsistenten Zustand versetzt wurde, der weitere automatisierte Updates durch DNS-Enactors verhinderte.

Vor dem manuellen Eingriff zur Behebung kam es laut Amazon bei Systemen, die mit DynamoDB verbunden waren, zu DNS-Ausfällen, darunter Kundenverkehr und interne AWS-Dienste, die sich auf den Start von EC2-Instanzen und die Netzwerkkonfiguration auswirkten.

Das Problem mit dem Network Load Balancer

Nach dem DNS-Problem begann der Network Manager von AWS, einen großen Rückstau an verzögerten Netzwerkkonfigurationen zu verbreiten, was zu Verzögerungen bei der Netzwerkkonfiguration neu gestarteter EC2-Instanzen führte. Diese Netzwerkverzögerungen wirkten sich wiederum auf den Network Load Balancer (NLB)-Dienst von AWS aus.

Das Health-Checking-Subsystem von NLB löschte neue EC2-Instanzen, die aufgrund von Netzwerkverzögerungen den Health-Check nicht bestanden hatten, um sie dann wiederherzustellen, wenn nachfolgende Checks erfolgreich waren. Da der Start von EC2-Instanzen jedoch beeinträchtigt war, traten bei allen abhängigen AWS-Diensten, darunter Lambda, Elastic Container Service (ECS) und Elastic Kubernetes Service (EKS), Probleme auf.

"Die Ursache für dieses Problem war eine latente Race Condition im DynamoDB-DNS-Verwaltungssystem, die zu einem falschen leeren DNS-Eintrag für den regionalen Endpunkt des Dienstes (dynamodb.us-east-1.amazonaws.com) führte, den die Automatisierung nicht reparieren konnte", erklärt Amazon. "Alle Systeme, die über den öffentlichen Endpunkt eine Verbindung zum DynamoDB-Dienst in der Region [AWS North Virginia US-East-1-Rechenzentrum] herstellen mussten, waren sofort von DNS-Ausfällen betroffen und konnten keine Verbindung zu DynamoDB herstellen. Dies betraf sowohl den Kundenverkehr als auch den Datenverkehr von internen AWS-Diensten, die auf DynamoDB angewiesen sind."

Nr. 4: Diese Sofortmaßnahmen und Änderungen plant Amazon, um ähnliche Ausfälle zu verhindern

Amazon kündigte im Nachgang an, dass es nach dem Ausfall mehrere Änderungen an seinen Systemen vornimmt, darunter die Behebung des ursächlichen "Race-Condition-Szenarios", das dazu führte, dass sich die beiden automatisierten Systeme gegenseitig überschrieben. Bis entsprechende Sicherheitsvorkehrungen getroffen werden können, um ein erneutes Auftreten der Race Condition zu verhindern, hat AWS die Automatisierung von DynamoDB DNS Planner und DNS Enactor weltweit deaktiviert.

Amazon kündigte außerdem an, eine zusätzliche Testsuite zu entwickeln, um ähnliche Fehler in Zukunft zu erkennen und die Drosselungsmechanismen zu verbessern. "Während wir weiterhin die Details dieses Vorfalls in allen AWS-Diensten untersuchen, werden wir nach weiteren Möglichkeiten suchen, um die Auswirkungen eines ähnlichen Vorfalls in Zukunft zu vermeiden und die Wiederherstellungszeit weiter zu verkürzen", erklärte Amazon dazu.

"Wir wissen, dass dieses Ereignis viele Kunden erheblich beeinträchtigt hat", entschuldigt sich Amazon. "Wir werden alles in unserer Macht Stehende tun, um aus diesem Ereignis zu lernen und unsere Verfügbarkeit noch weiter zu verbessern."

Nr. 5: Ehemaliger AWS-Manager warnt: Ausfall war "unvermeidlich" und wird nicht der letzte bleiben

Der ehemalige AWS-Topmanager Debanjan Saha erklärte gegenüber CRN, dass der Ausfall von AWS "unvermeidlich" gewesen sei. "Angesichts ihrer enormen globalen Reichweite und der Komplexität dieser verteilten Systeme ist es eigentlich bemerkenswert, dass großflächige Störungen wie diese so selten sind", sagte Saha in einer E-Mail an CRN. Aus seiner Sicht war der Ausfall von AWS "auf lange Sicht unvermeidlich", da sowohl öffentliche als auch private Cloud-Anbieter irgendwann einmal einen Ausfall erleben würden. "Die Frage ist nicht ob, sondern wann", fügte Saha hinzu.

Saha war von 2014 bis 2019 Vice President und General Manager des Datenbankgeschäfts von AWS, bevor er 2019 als Vice President und General Manager für das Datenanalyse-Geschäft von Google zum Konkurrenten Google Cloud wechselte. Im Jahr 2022 wurde er CEO von DataRobot.

Nr. 6: Vorsorge und Ernstfall für die Datensouveränität

Betroffene Unternehmen sollten aus dem Vorfall zwei Lehren ziehen. Zum einen traf er viele von ihnen unvorbereitet, da sie schlichtweg nicht mit einem solchen Ausfall gerechnet und sich deshalb die Investitionen in Vorsorgemaßnahmen wie Redundanzen gespart hatten. Zumindest bei kritischen Systemen ein fataler Fehler. "Jedes Unternehmen, das auf Cloud-Infrastruktur angewiesen ist, sollte eine klare Strategie für Ausfallsicherheit haben", empfiehlt Saha. "Das bedeutet, über ein einzelnes Rechenzentrum oder eine einzelne Region hinauszudenken, idealerweise über einen einzelnen Anbieter hinaus, und für mehrere Regionen und – wo möglich – für Multi-Cloud- oder Hybrid-Umgebungen zu planen."

Zugleich kann der Vorfall als Menetekel im Sinne der aktuellen Diskussion um digitale Souveränität in Europa gesehen werden. Er zeigt allzu deutlich auf, welche Risiken drohen, sollte ein Hyperscaler durch einen Fehler, Hackerangriff, oder auch politische Einflussnahme beeinträchtigt werden. Gerade in letzterem Szenario wäre selbst eine auf mehrere US-Dienste verteilte Multi-Cloud kein Garant für einen sicheren Weiterbetrieb und könnte wesentliche Teile der europäischen Wirtschaft schwer treffen.

Nr. 7: Vernetzte Produkte brauchen einen Offline-Notlauf

Eine weitere Lehre aus dem Ausfall betrifft die Hersteller vernetzter Geräte. Auch sie vergessen allzu oft, entsprechende Notfallpläne zu integrieren. Besonders eindrückliche Beispiele dafür lieferten im aktuellen Fall etwa vermeintlich smarte Wasserfilter, die ihre Nutzer ohne die AWS-Verbindung plötzlich auf dem Trockenen sitzen ließen. Ähnliches gilt für rund 2.000 Dollar teure Matratzen mit Healthcare-Funktionen, deren interne Systeme durch den Ausfall abstürzten. Dadurch ließen sich die Funktionen wie beispielsweise die integrierte Heizung und Schlafpositionsverstellung nicht mehr steuern, sodass sie dauerhaft heizten oder hochgestellte Kopfteile nicht mehr abgesenkt werden konnten. Hier sind die Hersteller gefordert, entsprechende Fallback-Möglichkeiten zu integrieren, die auch offline zumindest die Kontrolle der wichtigsten Funktionen erlauben.

Dieser Artikel basiert zum Teil auf Material unserer Schwester-Publikation crn.com

CRN-Newsletter beziehen und Archiv nutzen - kostenlos: Jetzt bei der CRN Community anmelden