Großflächiger Ausfall bei Google Cloud und Cloudflare legt zahlreiche Dienste lahm

Cloudflare-Ausfall vom 12. Juni 2025 zeigt Risiken zentralisierter Infrastruktur + Am 12. Juni 2025 kam es zu einem massiven Ausfall bei Cloudflare und gleichzeitig zu Störungen in der Google Cloud-Infrastruktur. Die Vorfälle legten weltweit zahlreiche Online-Dienste lahm und machten erneut die Verwundbarkeit stark vernetzter Cloud-Ökosysteme deutlich.

Der Ausfall bei Cloudflare begann um 17:52 Uhr UTC, als interne Systeme Anomalien bei der Geräteregistrierung für den Zero Trust-Dienst WARP registrierten. Die Ursache: Ein Fehler in der Speicherinfrastruktur eines Drittanbieters, auf die der verteilte Schlüssel-Wert-Speicher „Workers KV“ von Cloudflare angewiesen ist. Dieser Dienst spielt eine zentrale Rolle bei der Konfiguration, Authentifizierung und Bereitstellung digitaler Inhalte.

Die Fehlerrate bei Anfragen an Workers KV erreichte zwischenzeitlich über 90 Prozent – mit weitreichenden Konsequenzen. Zahlreiche darauf basierende Dienste wie Access, Gateway, Images, Stream, Workers AI, Turnstile, AutoRAG, Zaraz sowie Teile des Cloudflare-Dashboards fielen aus oder arbeiteten nur eingeschränkt. Weltweit waren tausende Nutzer betroffen. Die Störung dauerte rund zweieinhalb Stunden.

Cloudflare betonte, dass es sich nicht um einen Sicherheitsvorfall oder Cyberangriff handelte und keine Daten verloren gingen. Grundlegende Netzwerkinfrastrukturen wie DNS, Magic Transit, Proxy und WAF blieben weitgehend stabil.

In einem Statement räumte das Unternehmen eigene Versäumnisse ein: Zwar habe der Fehler beim externen Speicheranbieter gelegen, doch die Verantwortung für Architektur und gewählte Abhängigkeiten liege bei Cloudflare selbst. Man arbeite bereits an Maßnahmen zur Stärkung der Resilienz.

Die Ausfälle bei Google Cloud, die sich zeitgleich ereigneten, trugen zusätzlich zur Instabilität zahlreicher Webdienste bei – und werfen erneut die Frage auf, wie robust die digitale Infrastruktur in Zeiten zunehmender Cloud-Konzentration tatsächlich ist.

Die Mitarbeiter von KV verzeichneten eine Fehlerquote von 90,22 % bei Anfragen, was zu einer Kettenreaktion von Ausfällen bei abhängigen Diensten führte:

Workers KV

Bei Workers KV schlugen 90,22 % der Anfragen fehl: Alle nicht zwischengespeicherten Schlüssel-Wert-Paare, für die der Wert aus den ursprünglichen Speicher-Backends von Workers KV abgerufen werden musste, führten zu fehlgeschlagenen Anfragen mit dem Antwortcode 503 oder 500.

Die übrigen Anfragen wurden erfolgreich aus dem Cache von Workers KV bedient (Statuscode 200 und 404) oder lieferten Fehler innerhalb unserer erwarteten Grenzen und/oder unseres Fehlerbudgets zurück.

Dies hatte keine Auswirkungen auf die in Workers KV gespeicherten Daten.

Zugriff

Access verwendet Workers KV zum Speichern von Anwendungs- und Richtlinienkonfigurationen sowie von Benutzeridentitätsinformationen.

Während des Vorfalls schlugen 100 % der identitätsbasierten Anmeldungen für alle Anwendungstypen, einschließlich Self-Hosted, SaaS und Infrastructure, fehl. Während dieses Vorfalls standen Benutzeridentitätsinformationen anderen Diensten wie WARP und Gateway nicht zur Verfügung. Access ist so konzipiert, dass es bei einem Fehler geschlossen wird, wenn es die Richtlinienkonfiguration oder die Identität eines Benutzers nicht erfolgreich abrufen kann.

Aktive Infrastruktur Bei SSH-Sitzungen mit aktivierter Befehlsprotokollierung konnten die Protokolle aufgrund einer Abhängigkeit von Workers KV nicht gespeichert werden.

Der SCIM-Dienst (System for Cross Domain Identity) von Access war ebenfalls betroffen, da er zur Speicherung von Benutzerinformationen auf Workers KV und Durable Objects (die von KV abhängig waren) angewiesen war. Während dieses Vorfalls wurden Benutzeridentitäten aufgrund von Fehlern bei der Aktualisierung von Workers KV nicht aktualisiert. Diese Fehler führten zu einer 500-Fehlermeldung, die an Identitätsanbieter zurückgegeben wurde. Bei einigen Anbietern war möglicherweise eine manuelle Neusynchronisierung erforderlich, aber die meisten Kunden konnten dank der Wiederholungslogik des Identitätsanbieters sofort nach der Wiederherstellung des SCIM-Dienstes von Access wieder auf den Dienst zugreifen.

Dienstauthentifizierungsbasierte Anmeldungen (z. B. Dienst-Token, Mutual TLS und IP-basierte Richtlinien) und Bypass-Richtlinien waren nicht betroffen. Während dieses Zeitraums gingen keine Änderungen an Access-Richtlinien verloren.

Gateway

Dieser Vorfall hatte keine Auswirkungen auf die meisten Gateway-DNS-Abfragen, einschließlich solcher über IPv4, IPv6, DNS über TLS (DoT) und DNS über HTTPS (DoH).

Es gab jedoch zwei Ausnahmen:

DoH-Abfragen mit identitätsbasierten Regeln schlugen fehl. Dies geschah, weil Gateway die erforderlichen Identitätsinformationen des Benutzers nicht abrufen konnte.

Die authentifizierte DoH wurde für einige Benutzer unterbrochen. Benutzer mit aktiven Sitzungen mit gültigen Authentifizierungstoken waren davon nicht betroffen, aber diejenigen, die neue Sitzungen starten oder Authentifizierungstoken aktualisieren mussten, konnten dies nicht tun.

Benutzer von Gateway-Proxy, Egress und TLS-Entschlüsselung konnten keine Verbindung herstellen, sich registrieren, Proxy verwenden oder Datenverkehr protokollieren.

Dies lag daran, dass wir zur Abfrage aktueller Identitäts- und Gerätezustandsinformationen auf Workers KV angewiesen waren. Jede dieser Aktionen erfordert einen Aufruf von Workers KV. Wenn dieser nicht verfügbar ist, ist Gateway so konzipiert, dass es geschlossen wird, um zu verhindern, dass Datenverkehr die vom Kunden konfigurierten Regeln umgeht.

WARP

Der WARP-Client war aufgrund von Kernabhängigkeiten von Access und Workers KV betroffen, die für die Geräteregistrierung und -authentifizierung erforderlich sind. Infolgedessen konnten während des Vorfalls keine neuen Clients eine Verbindung herstellen oder sich anmelden.

Bestehende WARP-Client-Benutzersitzungen, die über den Gateway-Proxy geleitet wurden, waren unterbrochen, da Gateway die erforderlichen Richtlinienbewertungen nicht durchführen konnte.

Darüber hinaus war die WARP-Notfall-Trennungsübersteuerung aufgrund eines Fehlers in der zugrunde liegenden Abhängigkeit, Workers KV, nicht verfügbar.

Consumer WARP war ähnlich sporadisch betroffen wie die Zero Trust-Version.

Dashboard

Die Anmeldungen von Dashboard-Benutzern und die meisten bestehenden Dashboard-Sitzungen waren nicht verfügbar. Dies war auf einen Ausfall von Turnstile, DO, KV und Access zurückzuführen. Die spezifischen Ursachen für die Anmeldefehler waren:

Standardanmeldungen (Benutzername/Passwort): Fehlgeschlagen aufgrund der Nichtverfügbarkeit von Turnstile.

Anmeldung mit Google (OIDC): Fehlgeschlagen aufgrund eines Problems mit der KV-Abhängigkeit.

SSO-Anmeldungen: Fehlgeschlagen aufgrund einer vollständigen Abhängigkeit von Access.

Die Cloudflare v4-API war von diesem Vorfall nicht betroffen.

Herausforderungen und Turnstile

Die Challenge-Plattform, auf der Cloudflare Challenges und Turnstile basieren, verzeichnete während des Vorfalls aufgrund ihrer Abhängigkeiten von Workers KV und Durable Objects eine hohe Fehler- und Zeitüberschreitungsrate bei Siteverify-API-Anfragen.

Wir verfügen über Kill-Switches, um diese Aufrufe im Falle von Vorfällen und Ausfällen wie diesem zu deaktivieren. Wir haben diese Kill-Switches als Abhilfemaßnahme aktiviert, damit die Weiterleitung nicht blockiert wird. Während diese Kill-Switches aktiv waren, konnte die Siteverify-API von Turnstile (die API, die ausgegebene Tokens validiert) gültige Tokens mehrfach einlösen, was potenziell Angriffe ermöglicht hätte, bei denen ein Angreifer versuchen könnte, einen zuvor gültigen Token zu verwenden, um die Überprüfung zu umgehen.

Die Fähigkeit von Turnstile, Bots zu erkennen, war davon nicht beeinträchtigt. Ein Bot, der versucht hätte, eine Herausforderung zu lösen, hätte diese weiterhin nicht bestanden und somit kein Token erhalten.

Browser-Isolation

Bestehende Browser-Isolationssitzungen über die linkbasierte Isolation waren aufgrund der Abhängigkeit von Gateway für die Richtlinienauswertung betroffen.

Neue linkbasierte Browser-Isolationssitzungen konnten aufgrund einer Abhängigkeit von Cloudflare Access nicht initiiert werden. Alle von Gateway initiierten Isolationssitzungen schlugen aufgrund ihrer Gateway-Abhängigkeit fehl.

Bilder

Uploads zu Cloudflare Images waren während des Vorfalls betroffen, mit einer Ausfallrate von 100 % zum Höhepunkt des Vorfalls.

Die Gesamtbildbereitstellung sank auf eine Erfolgsrate von etwa 97 %. Bildtransformationen waren nicht wesentlich betroffen, und Polish war nicht betroffen.

Stream

Die Fehlerrate von Stream lag während des Vorfalls bei über 90 %, da Videowiedergabelisten nicht bereitgestellt werden konnten. Bei Stream Live wurde eine Fehlerrate von 100 % festgestellt.

Video-Uploads waren nicht betroffen.

Realtime

Der Realtime TURN-Dienst (Traversal Using Relays around NAT) verwendet KV und war stark betroffen. Die Fehlerraten lagen während des gesamten Vorfalls bei fast 100 %.

Der Realtime SFU-Dienst (Selective Forwarding Unit) konnte keine neuen Sitzungen erstellen, obwohl bestehende Verbindungen aufrechterhalten wurden. Dies führte zu einer Reduzierung des normalen Datenverkehrs auf 20 % während des Ausfallzeitfensters.

Workers AI

Alle Inferenzanfragen an Workers AI schlugen während der Dauer des Vorfalls fehl. Workers AI ist für die globale Verteilung von Konfigurations- und Routing-Informationen für KI-Anfragen auf Workers KV angewiesen.

Seiten und Workers-Assets

Statische Assets, die von Cloudflare Pages und Workers bereitgestellt werden (z. B. HTML, JavaScript, CSS, Bilder usw.), werden in Workers KV gespeichert, zwischengespeichert und bei Bedarf abgerufen. Bei Workers Assets stieg die durchschnittliche Fehlerrate während dieses Zeitraums um etwa 0,06 % der Gesamtanfragen.

Während des Zeitraums des Vorfalls stieg die Fehlerrate bei Pages auf bis zu 100 % und alle Pages-Builds konnten nicht abgeschlossen werden.

AutoRAG

AutoRAG nutzt Workers-KI-Modelle sowohl für die Dokumentkonvertierung und die Generierung von Vektoreinbettungen während der Indizierung als auch LLM-Modelle für Abfragen und Suchvorgänge. Aufgrund der Abhängigkeit von Workers-KI war AutoRAG während des Vorfalls nicht verfügbar.

Durable Objects

SQLite-gestützte dauerhafte Objekte nutzen dieselbe zugrunde liegende Speicherinfrastruktur wie Workers KV. Die durchschnittliche Fehlerrate während des Vorfalls stieg auf 22 % und sank auf 2 %, als die Dienste wiederhergestellt wurden.

Namensräume für dauerhafte Objekte, die den alten Schlüsselwertspeicher verwenden, waren nicht betroffen.

D1

D1-Datenbanken nutzen dieselbe zugrunde liegende Speicherinfrastruktur wie Workers KV und dauerhafte Objekte.

Ähnlich wie bei dauerhaften Objekten lag die durchschnittliche Fehlerrate während des Vorfalls bei maximal 22 % und sank auf 2 %, als die Dienste wiederhergestellt wurden.

Warteschlangen und Ereignisbenachrichtigungen

Warteschlangen-Nachrichtenvorgänge, einschließlich Pushen und Verbrauchen, waren während des Vorfalls nicht verfügbar.

Warteschlangen verwenden KV, um jede Warteschlange den zugrunde liegenden dauerhaften Objekten zuzuordnen, die Nachrichten in der Warteschlange enthalten.

Ereignisbenachrichtigungen verwenden Warteschlangen als zugrunde liegenden Übermittlungsmechanismus.

AI Gateway

AI Gateway basiert auf Workers und nutzt Workers KV für Client- und interne Konfigurationen. Während des Vorfalls stieg die Fehlerrate bei AI Gateway auf 97 % der Anfragen, bis die Abhängigkeiten wiederhergestellt waren.

CDN

Die automatisierte Infrastruktur für das Traffic-Management war funktionsfähig, arbeitete jedoch während des Ausfalls mit verminderter Effizienz. Insbesondere die Registrierungsanfragen von Zero Trust-Clients nahmen infolge des Ausfalls erheblich zu.

Der Anstieg der Anfragen führte zu einer zusätzlichen Belastung an mehreren Cloudflare-Standorten, was eine Reaktion des automatisierten Traffic-Managements auslöste. Als Reaktion auf diese Bedingungen leiteten die Systeme den eingehenden CDN-Traffic an nahegelegene Standorte um, wodurch die Auswirkungen für die Kunden verringert wurden. Ein Teil des Traffics wurde nicht wie erwartet umgeleitet und wird derzeit untersucht. CDN-Anfragen, die von diesem Problem betroffen waren, wiesen erhöhte Latenzzeiten, HTTP-499-Fehler und/oder HTTP-503-Fehler auf. Zu den betroffenen Cloudflare-Dienstbereichen gehörten São Paulo, Philadelphia, Atlanta und Raleigh.

Workers / Workers for Platforms

Workers und Workers for Platforms sind für Uploads auf einen Drittanbieter-Dienst angewiesen. Während des Vorfalls stieg die Fehlerrate bei Workers insgesamt auf einen Spitzenwert von ~2 % der gesamten Anfragen. Bei Workers for Platforms stieg die Fehlerrate im gleichen Zeitraum auf einen Spitzenwert von ~10 % der gesamten Anfragen.

Workers-Builds (CI/CD)

Ab 18:03 UTC konnten Workers-Builds aufgrund eines Ausfalls des Zugriffs keine neuen Push-Ereignisse zur Quellcodeverwaltung empfangen.

100 % der neuen Workers-Builds schlugen während des Vorfalls fehl.

Browser-Rendering

Das Browser-Rendering hängt von der Browserisolierung für die Browserinstanzinfrastruktur ab.

Anfragen sowohl an die REST-API als auch über die Workers-Browser-Bindung waren während des Vorfalls zu 100 % betroffen.

Zaraz

100 % der Anfragen waren während des Vorfalls betroffen. Zaraz ist bei der Verarbeitung von Eyeball-Traffic auf Workers-KV-Konfigurationen für Websites angewiesen. Aufgrund dieser Abhängigkeit waren Versuche, Aktualisierungen der Zaraz-Konfigurationen zu speichern, während dieses Zeitraums erfolglos, aber unsere Überwachung zeigt, dass nur ein einziger Benutzer betroffen war.

Hintergrund

Workers KV ist als sogenannter „coreless“ Dienst aufgebaut, was bedeutet, dass es keinen Single Point of Failure geben sollte, da der Dienst an jedem unserer Standorte weltweit unabhängig voneinander läuft. Allerdings ist Workers KV derzeit auf einen zentralen Datenspeicher angewiesen, der als Quelle für Daten dient. Ein Ausfall dieses Speichers führte zu einem vollständigen Ausfall für Cold Reads und Writes in den KV-Namespaces, die von Diensten in der gesamten Cloudflare-Infrastruktur genutzt werden.

Workers KV wird derzeit auf eine deutlich widerstandsfähigere Infrastruktur für seinen zentralen Speicher umgestellt: Leider gab es eine Lücke in der Abdeckung, die während dieses Vorfalls aufgedeckt wurde. Workers KV hat einen Speicheranbieter entfernt, während wir daran arbeiteten, das Backend von KV neu zu strukturieren, einschließlich der Migration zu Cloudflare R2, um Probleme mit der Datenkonsistenz (verursacht durch die ursprüngliche Datenabgleichsarchitektur) zu vermeiden und die Unterstützung für Datenresidenzanforderungen zu verbessern.

Einer unserer Grundsätze ist es, Cloudflare-Dienste so weit wie möglich auf unserer eigenen Plattform aufzubauen, und Workers KV bildet da keine Ausnahme. Viele unserer internen und externen Dienste sind stark von Workers KV abhängig, das uns unter normalen Umständen dabei hilft, möglichst robuste Dienste bereitzustellen, anstatt dass Serviceteams versuchen, ihre eigenen Speicherdienste aufzubauen. In diesem Fall verschärfte die Kettenreaktion durch den Ausfall von Workers KV das Problem und vergrößerte den Ausbruchsradius erheblich.

Alle Zeitangaben beziehen sich auf die koordinierte Weltzeit (UTC).

Zeitpunkt – Ereignis

12.06.2025, 17:52

BEGINN DES VORFALLS Das Cloudflare WARP-Team stellt fest, dass die Registrierung neuer Geräte fehlschlägt, beginnt mit der Untersuchung dieser Fehler und meldet einen Vorfall.

12.06.2025, 18:05

Das Cloudflare Access-Team erhält eine Warnmeldung aufgrund eines rapiden Anstiegs der Fehlerraten.

Die Service Level Objectives für mehrere Dienste fallen unter die Zielwerte und lösen Warnmeldungen in den entsprechenden Teams aus.

12.06.2025, 18:06

Mehrere dienstspezifische Vorfälle werden zu einem einzigen Vorfall zusammengefasst, da wir eine gemeinsame Ursache identifizieren (Workers KV nicht verfügbar). Die Priorität des Vorfalls wird auf P1 erhöht.

12.06.2025, 18:21

Die Priorität des Vorfalls wird von P1 auf P0 erhöht, da das Ausmaß der Auswirkungen deutlich wird.

12.06.2025, 18:43

Cloudflare Access beginnt gemeinsam mit dem Workers KV-Entwicklungsteam, Optionen zu prüfen, um die Abhängigkeit von Workers KV durch die Migration zu einem anderen Backing-Datenspeicher zu beseitigen. Dies war eine proaktive Maßnahme für den Fall, dass die Speicherinfrastruktur weiterhin ausgefallen sein sollte.

12.06.2025, 19:09

Zero Trust Gateway begann mit der Arbeit an der Beseitigung der Abhängigkeiten von Workers KV, indem Regeln, die auf den Identitäts- oder Gerätestatus verwiesen, reibungslos heruntergestuft wurden.

12.06.2025, 19:32

Access und Device Posture erzwingen das Verwerfen von Identitäts- und Gerätestatus-Anfragen, um die Last auf Workers KV zu verringern, bis der Drittanbieterdienst wieder online ist.

12.06.2025, 19:45

Die Cloudflare-Teams arbeiten weiterhin daran, eine Workers KV-Version für einen alternativen Backing-Datenspeicher bereitzustellen und kritische Dienste dazu zu veranlassen, Konfigurationsdaten in diesen Speicher zu schreiben.

12.06.2025, 20:23

Die Dienste beginnen sich zu erholen, da die Speicherinfrastruktur wieder funktioniert. Aufgrund des hohen Datenaufkommens durch die Wiederauffüllung der Caches durch die Dienste kommt es weiterhin zu einer nicht unerheblichen Fehlerrate und zu Einschränkungen der Infrastruktur.

12.06.2025, 20:25

Zugriff und Gerätekonfiguration stellen die Aufrufe von Workers KV wieder her, da der Drittanbieterdienst wieder verfügbar ist.

12.06.2025, 20:28

AUSWIRKUNGEN BEENDET Die Service Level Objectives kehren auf das Niveau vor dem Vorfall zurück. Die Cloudflare-Teams überwachen die Systeme weiterhin, um sicherzustellen, dass die Dienste während der Wiederherstellung der abhängigen Systeme nicht beeinträchtigt werden.

VORFALL BEENDET Das Cloudflare-Team stellt fest, dass alle betroffenen Dienste wieder normal funktionieren. Die Warnmeldungen zu den Service Level Objectives werden zurückgesetzt.

Gleichzeitige Ausfälle bei Cloudflare und Google offenbaren strukturelle Schwächen

Obwohl sowohl Cloudflare als auch Google betonen, dass ihre Ausfälle am 12. Juni 2025 unabhängig voneinander auftraten, führte die zeitliche Überschneidung zu weitreichenden Störungen in den digitalen Arbeitsabläufen von Millionen von Nutzern weltweit.

Beide Unternehmen kündigten umfassende Untersuchungen der Vorfälle an. Cloudflare plant als Reaktion eine stärkere Diversifizierung seiner Infrastruktur, während Google eine Überarbeitung der Sicherheitsmechanismen bei der Bereitstellung seiner Identitäts- und Zugriffsverwaltung (IAM) in Aussicht stellte.

Die Vorfälle machen deutlich, wie verwundbar zentrale Internetdienste trotz hoher Ausfallsicherheit sind. Experten fordern angesichts der zunehmenden Komplexität vernetzter Systeme verstärkt Cloud-übergreifende Redundanzen sowie eine verbesserte Echtzeit-Überwachung von Abhängigkeiten in kritischen Infrastrukturen.

Quelle: Cloudflare

Bild/Quelle: https://depositphotos.com/de/home.html