- Der Ausfall des weltweit größten Cloud-Dienstes AWS hat tausende Websites und Apps zum Stillstand gebracht und eine Warnung ausgelöst, dass die Internet-Infrastruktur übermäßig von wenigen Unternehmen abhängig ist.
- Neben zentralen Diensten wie Snapchat, Roblox, Signal, Duolingo waren auch Lloyds Bank, Ring, HMRC sowie andere öffentliche und Finanzinstitute von der Störung betroffen.
- AWS erklärte einen internen Systemfehler in der US-Ost-Region als Ursache, schloss eine Cyberattacke aus und stellte den Großteil der Dienste nach wenigen Stunden wieder her.
- Experten warnten, die Basis für demokratische Debatten und den Journalismus dürfe nicht von der Infrastruktur weniger Unternehmen abhängen, und unterstrichen die Notwendigkeit der Diversifizierung der Cloud-Infrastruktur.
- Die dominierende Struktur großer Cloud-Anbieter habe die Anfälligkeit des globalen Internets offengelegt und die Diskussion über die technologische Souveränität öffentlicher Infrastruktur ausgelöst.
Ausfallübersicht
- Der Ausfall entstand durch einen internen Fehler in der AWS US-Ost-Region (US-East-1) und verursachte einen groß angelegten globalen Serviceunterbruch.
- Er begann am Montagmorgen gegen 8 Uhr Ortszeit (16 Uhr britischer Zeit).
- Amazon teilte mit, dass die API-Fehlerrate und die Latenz zugenommen hätten.
- Laut Downdetector waren weltweit rund 2.000 Unternehmen betroffen, und in den USA, Großbritannien und Australien meldeten jeweils über 1,9 Millionen, 1 Million bzw. 410.000 Personen Störungen.
- AWS machte ein Problem im Überwachungssubsystem des internen Load Balancers verantwortlich und schloss einen Cyberangriff aus.
- Es wurde gemeldet, dass API-Antworten wegen eines Fehlers im Zusammenhang mit DynamoDB fehlschlugen.
- Um einen Verkehrsanstieg einzudämmen, wurde vorübergehend eine Begrenzung der Anfragerate eingeführt.
- AWS gab am Abend offiziell seine Rückkehr zum Normalbetrieb bekannt, doch bei einzelnen Diensten wurden weiterhin Ausfälle gemeldet.
Betroffener Bereich
- Wichtige Dienste: Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton u. a.
- In Großbritannien kam es zu Zugriffsproblemen auf die Websites von Finanzdiensten wie Lloyds, Halifax, Bank of Scotland sowie der HMRC-Website (HMRC, britische Steuerbehörde).
- Nutzer der Ring-Türklingel beklagten, dass der Service zur Türüberwachung vorübergehend ausgefallen sei.
- Auch auf globalen Plattformen wie Epic Games, Pokémon Go, Wordle wurden Verbindungsprobleme gemeldet.
Expertenanalyse
- Dr. Corinne Cath-Speth (Article 19): „Es ist riskant, wenn die Grundlage für den demokratischen Diskurs und unabhängigen Journalismus von der Infrastruktur weniger Unternehmen abhängt. Die Diversifizierung der Cloud ist dringend erforderlich.“
- Cori Crider (Future of Technology Institute): „Großbritannien muss sich von der Abhängigkeit von US-Big-Tech lösen. Der Ausfall eines einzelnen AWS-Systems hat gezeigt, dass die gesamte moderne Wirtschaft stehen bleiben kann.“
- Madeline Carr (UCL): „Die Sicherheits- und Skalierungsvorteile ergeben sich aus der kapitalstarken Natur großer Cloud-Anbieter, doch die Struktur, die die Welt an ein gemeinsames Risiko bindet, ist extrem gefährlich."
- Steven Murdoch (UCL): „Vermutlich war es kein Cyberangriff, sondern ein operativer Fehler innerhalb von AWS als Ursache."
Regierung und Regulierung
- Die Regierung im Vereinigten Königreich teilte mit, dass sie einen Notfallkommunikationskanal mit AWS eingerichtet und die Wiederherstellung überwacht habe.
- Der Finanzausschuss des Unterhauses forderte, AWS zum „kritischen Drittanbieter (critical third party)“ im Finanzsektor zu erklären.
- In diesem Fall wäre AWS Aufsicht durch die Finanzaufsichtsbehörden unterworfen, was die Sicherstellung der Stabilität der Finanzinfrastruktur erleichtern könnte.
- Ausschussvorsitzender Meg Hillier kritisierte, AWS verspreche zwar „Widerstandsfähigkeit“, habe in der Praxis aber Schwachstellen offengelegt.
Hintergrund und Implikationen
- AWS führt mit einem globalen Marktanteil von über 30 % bei Cloud-Diensten und liegt damit auf Platz 1.
- Zusammen mit Microsoft Azure und Google Cloud entsteht eine Struktur des „dreifachen Cloud-Oligopols“.
- Im Jahr 2024 kam es bereits zu einem globalen Bluescreen-Ereignis auf Windows-PCs durch einen Softwarefehler von CrowdStrike.
- Der Vorfall hat erneut die Systemrisiken durch die Konzentration digitaler Infrastrukturen hervorgehoben und Diskussionen über technologische Souveränität und Cloud-Diversifizierungsstrategien in vielen Ländern angefacht.
3 Kommentare
Kopf hoch, Naver Cloud!
„Wenn dir die Cloud nicht gefällt, dann bau sie doch einfach selbst auf und nutze sie.“ Da fragt man sich, ob man darüber überhaupt sinnvoll diskutieren kann. Multi-Cloud? Aufbau und Betrieb macht schließlich auch nicht die Vorfahren für dich.
Hacker News Kommentar
Es wird derzeit darüber diskutiert, dass im AWS us-east-1 mehrere Dienste ausgefallen sind; der zugehörige lange Thread ist hier zu finden.
Auch beim Fastly-Vorfall 2021 gab es ähnliche Kritik von angeblichen „Experten“, aber es kam zu keinen klaren Veränderungen. Ein solches Thema ist eine Woche später auch in den Nachrichten nicht mehr zu lesen. Praktiker:innen wissen, wie schwierig es ist, in der Größenordnung von AWS zu operieren. Echte Gegenmaßnahmen für diese Situation sind so teuer, dass sie für die meisten Unternehmen nur geringen Nutzen bringen. Für wirklich „kritische“ Services ist es selbstverständlich richtig, so zu entwerfen, dass sie für solche Ausfälle gerüstet sind. Dass man sich nicht bei Fortnite anmelden konnte, zeigt, wie schwierig und teuer es ist, dies realistisch umzusetzen. Die Medien behandeln im Alltag die Bedeutung von Multi-Region oder Multi-Cloud nicht, greifen das Thema nur beim Vorfall auf und vergessen es dann schnell wieder. Am Ende geht es im Grunde nur um die Frage nach der technischen Ursache. Ohne Folgemaßnahmen haben die Vorwürfe dieser „Experten“ kaum Bedeutung. Entscheidend ist eine konstruktive Vorfallanalyse ohne Schuldzuweisungen statt bloßer Vorwürfe ohne Konsequenz.
Die hier genannten „Experten“ sind Personen ohne Erfahrung im Infrastruktur- oder Cloud-Betrieb. Beispielsweise ist Dr Corinne Cath-Speth promovierte Anthropologin, Cori Crider Anwältin und Madeline Carr Professorin für Politikwissenschaft. Sie sind also Menschen, die Papers schreiben und Interviews geben, aber keine praktische Erfahrung im Betrieb von Hosting-Services haben.
Wenn man Cloud-Abhängigkeit kritisiert, wird man oft bei der Annahme landen, dass man in der Praxis mit mehr als 16 Stunden Downtime pro Jahr leben muss. Während eines mehrstündigen Ausfalls spürt man diesen Zustand deutlich, aber die Leistungsdegradation über die verbleibenden 8.742 Stunden kann tödlicher sein. Wenn ein Unternehmen bei nur 16 Ausfallstunden kaputt geht, dann kennen sowohl ich als auch die Gegenseite das Geschäft nicht wirklich. Ich interessiere mich eher für Hochverfügbarkeit, Geo-Redundanz und langlebige Systeme.
Es muss nicht unbedingt riesig viel Geld investiert werden. Nicht jeder Service muss auf demselben Niveau abgesichert werden. Mit unterschiedlichen Providern kann verhindert werden, dass alle gleichzeitig betroffen sind.
In den Berichten, die in den Medien diskutiert werden, wird betont, dass Multi-Region-/Multi-Cloud-Redundanz ineffektiv ist. Auch wenn es äußerlich wie ein Ausfall in nur einer Region aussieht, sind oft mehrere Regionen von einem einzelnen Vorfall betroffen. Multi-Cloud-Hot-Standby wird besonders teuer, je komplexer die Infrastruktur ist. Ohne frühzeitige Planung ist der spätere Einzug sehr schwierig.
Auch in den von AWS selbst veröffentlichten Berichten sieht man eine starke Konzentration auf bestimmte Regionen und bestimmte Dienste (z. B. DynamoDB). Eine solch zentralisierte Architektur wird seit über zehn Jahren beobachtet. Dennoch bleibt die Frage, warum sie sich nicht ändert. Bei diesem Ausfall waren mehr als 2.000 Dienste lange Zeit offline. Siehe AWS-Statusseite
Vielleicht sollte man darüber nachdenken, die Begriffe „Cloud“ oder „Internet“ durch „Lagerhaus in Virginia“ zu ersetzen. Zum Beispiel: „Unser Service liegt vollständig im Lagerhaus in Virginia“, „Alle meine Dateien sind im Lagerhaus in Virginia“, „Das Lagerhaus in Virginia ist so gebaut, dass es einen Atomkrieg übersteht“ usw. Original
Es gibt bereits viele VPS-Anbieter, und es tauchen fortlaufend Beispiele auf, in denen ein Umstieg dorthin Kosten senkt; real ist es in erster Linie ein Cloud-Lock-In- und Marketingthema.
Heute nutzen Unternehmen weniger grundlegende IaaS-Dienste wie EC2 als primitive Schicht, sondern hochrangige AWS-PaaS-Services wie DynamoDB oder RedShift. Das gilt ähnlich für Azure und Google Cloud. Sind Unternehmen an solche High-Level-Services gebunden, wird eine Migration zu einem VPS wie Hetzner oder zu Self-Hosting extrem komplex, da man den AWS-Stack praktisch neu aufbauen und betreiben müsste. Es genügt eben nicht, nur PostgreSQL zu installieren.
Bei jedem Beitrag, der behauptet, mit VPS gespart zu haben, wird oft der Gegenstoß gepostet: „AWS ist Web-Scale und fällt niemals aus, VPS haben nur einen Tag Uptime im Monat.“
Amazon bietet auch VPS-ähnliche Angebote wie EC2 an – ich frage mich, ob EC2 bei diesem Vorfall ebenfalls betroffen war.
Expertenmeinungen fokussieren sich oft eher auf den geopolitischen Kontext (z. B. die Echtzeit-Abhängigkeit nationaler Gesamtsysteme von ausländischen Unternehmen) als auf Technik. Für ein gewöhnliches Unternehmen kann die Abhängigkeit von einem einzelnen Anbieter die Komplexität reduzieren und ist in Bezug auf Ausfallhäufigkeit nicht unangemessen. Es muss nicht zwingend Multi-Cloud verwendet werden; mit nur einem Anbieter kann die Downtime auch seltener werden.
Ich glaube, die gesamte Branche steckt im Cloud-Lock-In. Die Frage ist, wie man das rückgängig machen kann. Docker sehe ich – ähnlich wie die großen Cloud-Anbieter – als einen der Gründe für das Lock-In-Problem.
Aus der Sicht eines Engineers oder Support-Mitarbeiters ist die Realität, dass niemand versucht, etwas zu verändern, wenn man um 1 Uhr nachts feststellt, dass alles aufgrund eines AWS-Globalausfalls zusammenbricht.
Warum Docker hier ein Problem ist, interessiert mich.
Ich habe die praktische Cloud-Arbeit schon lange hinter mir, aber damals wurden die Grundfunktionen (Primitives) zwischen den Providern bereits vereinheitlicht. Ich frage mich, ob Multi-Cloud-Redundanz damals zu teuer war, die technischen Unterschiede zu groß waren oder ob es geschäftlich nicht einmal abgewogen werden musste. Pets-vs-Cattle-Folie
Das Deployment und der Betrieb über mehrere Clouds ist für Teams zu belastend, was Management- und kognitive Last angeht. Die Aufrechterhaltung von Fachwissen für die Infrastruktur von zwei oder mehr Clouds benötigt viel Personal. Kleine oder schnelle Teams sind dafür ungeeignet. Die Einfachheit eines einzelnen Clouds geht direkt in bessere Uptime über. Auch große Unternehmen profitieren oft von Volumenrabatten bei einem Cloud-Anbieter. Und niemand wird entlassen, nur weil er sich für AWS entscheidet.
Multi-Cloud wirkt kaum, wenn die andere Cloud im Falle eines Ausfalls in der eigenen Region nicht helfen kann. Die Anbieter halten weiterhin zu 100 % an proprietären Standards fest; die Control Plane ist ebenfalls Kubernetes. Am Ende sind alle bei Kubernetes gelandet.
Alle Clouds stellen Compute günstig bereit, jedoch ist Netzwerk-Egress absurd teuer. Wer Multi-Cloud aufsetzt, erlebt schnell explodierende Traffic-Kosten. Das wirkt auf mich eher absichtlich.
Tatsächlich scheinen Clouds ihren Gewinn mit Egress-Gebühren zu machen. Aus diesem Grund sind Multi-Cloud-Setups, ja selbst Regionen- und AZ-Redundanz innerhalb einer einzelnen Cloud, für viele Clouds und Anwendungen zu teuer. Bei einem globalen Ausfall innerhalb einer einzelnen Cloud nützt sogar die Regionen-Redundanz nichts. Wenn eine Cloud ausfällt, ist es außerdem schwer, den Traffic auf eine andere Cloud zu verlagern, und der Aufwand ist unverhältnismäßig hoch. Für die meisten Anwendungen ist es besser, diese paar Stunden Ausfall in Kauf zu nehmen und Budget sowie Aufwand anderswo einzusetzen.
Viele Kunden haben Dateien/Daten in der Cloud; wenn sie nicht beim gleichen Anbieter wie der Service liegen, ist der Betrieb nicht einfach und die Akquise von Neukunden wird eher erschwert. Dass der Anbieter zum Marktstandard wird und alle potenziellen Kunden ihre Daten dort bündeln, macht es schwer, die Kosten für Storage in beiden Clouds zu rechtfertigen. Ich habe zwar versucht, platformunabhängig zu starten, aber tatsächlich nutzen alle potenziellen Kunden dieselbe Cloud, sodass die Komplexität geringer ist.
Diese Einschätzung, dass AWS us-east-1 dieses Jahr keine zweistellige „9er“-Uptime erzielen wird, hätte man nicht vorauswissen können.
Als jemand, der AWS seit fast 20 Jahren nutzt, kann ich nicht nachvollziehen, warum man us-east-1 gewählt hat, wo der meiste Verkehr und die höchste Kritikalität liegt. Es ist der älteste und instabilste Ort.
Ich frage mich, ob Instanzen wie EC2 im konkreten Fall tatsächlich betroffen waren.
Viele halten es für „nicht schlimm“, wenn alle ausfallen, aber in der Praxis gilt das nicht für einen Service mit echten Endkund:innen.
Der Auslöser dieses Ausfalls war ein internes Subsystem, das die Health Checks für Network Load Balancer verwaltete. AWS Service-Statusseite