Großer Ausfall bei Google Cloud: Fehler im API-Management stört Dienste weltweit

Am 12. Juni 2025 kam es bei Google Cloud zu einem massiven Ausfall, der zahlreiche Online-Dienste weltweit beeinträchtigte. Ein technischer Fehler im API-Managementsystem löste eine mehr als dreistündige Störung aus, die zentrale Cloud-Funktionen und abhängige Drittanbieterdienste lahmlegte.

Die Störung begann gegen 10:49 Uhr PDT und eskalierte schnell. Betroffen waren nicht nur Google-eigene Dienste, sondern auch viele Unternehmen und Plattformen, die auf die Infrastruktur von Google Cloud setzen. Der Vorfall wirft erneut ein Schlaglicht auf die Verwundbarkeit moderner Cloud-Architekturen – insbesondere im Hinblick auf zentrale Steuerungskomponenten wie das API-Management.

Google hat angekündigt, den Vorfall intern zu untersuchen und Maßnahmen zur Verbesserung der Systemstabilität zu ergreifen.

Wichtige Google-Dienste wie Gmail, Google Drive, Google Kalender, Google Meet und Google Docs waren nicht erreichbar oder instabil.

Die Auswirkungen waren auch bei namhaften Kunden wie Spotify, Discord, OpenAI, Cloudflare, Shopify und Twitch zu spüren, von denen viele Dienstunterbrechungen und Leistungseinbußen meldeten.

Der Crowdsourcing-Ausfall-Tracker Downdetector verzeichnete weltweit über 1,4 Millionen Nutzerberichte, was das Ausmaß des Vorfalls unterstreicht.

Die Störung war nicht auf Nordamerika beschränkt; auch in Europa, Asien und Australien wurden erhebliche Dienstprobleme gemeldet, wobei einige Standorte längere Wiederherstellungszeiten hatten als andere.

Google Cloud Service Health-Bericht vom 13. Juni 2025

Bei Google Cloud, Google Workspace und Google Security Operations-Produkten kam es zu vermehrten 503-Fehlern bei externen API-Anfragen, von denen Kunden betroffen waren.

Wir entschuldigen uns vielmals für die Auswirkungen dieser Störung. Google Cloud-Kunden und ihre Nutzer vertrauen Google ihre Geschäfte an, und wir werden uns verbessern. Wir entschuldigen uns für die Auswirkungen, die dies nicht nur auf die Geschäfte unserer Kunden und deren Nutzer, sondern auch auf das Vertrauen in unsere Systeme hatte. Wir sind bestrebt, Verbesserungen vorzunehmen, um solche Ausfälle in Zukunft zu vermeiden.

Was ist passiert?

Google und Google Cloud APIs werden über unsere Google API-Verwaltungs- und Steuerungsebenen bereitgestellt. Diese regional verteilten Verwaltungs- und Steuerungsebenen sind dafür verantwortlich, dass jede eingehende API-Anfrage autorisiert ist und über die erforderlichen Richtlinien und entsprechenden Überprüfungen (z. B. Kontingente) verfügt, um ihre Endpunkte zu erreichen. Die Kernbinärdatei, die Teil dieses Richtlinienüberprüfungssystems ist, wird als Service Control bezeichnet. Service Control ist ein regionaler Dienst, der über einen regionalen Datenspeicher verfügt, aus dem er Kontingent- und Richtlinieninformationen liest. Die Metadaten dieses Datenspeichers werden fast sofort weltweit repliziert, um die Quotenrichtlinien für Google Cloud und unsere Kunden zu verwalten.

Am 29. Mai 2025 wurde Service Control um eine neue Funktion für zusätzliche Quotenrichtlinienprüfungen erweitert. Diese Codeänderung und die Veröffentlichung der Binärdatei wurden regionweise eingeführt, aber der Code-Pfad, der fehlgeschlagen ist, wurde während dieser Einführung nie ausgeführt, da eine Richtlinienänderung erforderlich war, die den Code ausgelöst hätte. Als Sicherheitsvorkehrung wurde diese Codeänderung mit einer roten Schaltfläche versehen, um diesen bestimmten Richtlinienpfad zu deaktivieren. Das Problem bei dieser Änderung war, dass sie weder über eine angemessene Fehlerbehandlung verfügte noch durch Feature-Flags geschützt war. Ohne die entsprechende Fehlerbehandlung führte der Nullzeiger zum Absturz der Binärdatei. Feature-Flags werden verwendet, um die Funktion schrittweise regionweise pro Projekt zu aktivieren, beginnend mit internen Projekten, damit wir Probleme erkennen können. Wäre dies durch ein Feature-Flag geschützt gewesen, wäre das Problem in der Staging-Umgebung erkannt worden.

Am 12. Juni 2025 um ca. 10:45 Uhr PDT wurde eine Richtlinienänderung in die regionalen Spanner-Tabellen eingefügt, die Service Control für Richtlinien verwendet. Aufgrund des globalen Charakters der Quotenverwaltung wurden diese Metadaten innerhalb von Sekunden weltweit repliziert. Diese Richtliniendaten enthielten unbeabsichtigte leere Felder. Service Control führte dann regional Quotenprüfungen für Richtlinien in jedem regionalen Datenspeicher durch. Dadurch wurden leere Felder für diese jeweilige Richtlinienänderung abgerufen und der Codepfad ausgeführt, der auf den Nullzeiger traf, wodurch die Binärdateien in eine Absturzschleife gerieten. Dies geschah aufgrund der regionalen Bereitstellung weltweit.

Innerhalb von zwei Minuten begann unser Site Reliability Engineering-Team mit der Fehlerbehebung. Innerhalb von zehn Minuten wurde die Ursache identifiziert und der „rote Knopf“ (zum Deaktivieren des Serving-Pfads) betätigt. Der „rote Knopf“ war etwa 25 Minuten nach Beginn des Vorfalls einsatzbereit. Innerhalb von 40 Minuten nach dem Vorfall war die Bereitstellung des „roten Knopfs“ abgeschlossen, und wir konnten eine Wiederherstellung in allen Regionen feststellen, beginnend mit den kleineren.

In einigen unserer größeren Regionen, wie z. B. us-central-1, kam es beim Neustart der Service Control-Aufgaben zu einem Herd-Effekt auf die zugrunde liegende Infrastruktur (d. h. die Spanner-Tabelle), wodurch die Infrastruktur überlastet wurde. Service Control verfügte nicht über die geeignete zufällige exponentielle Verzögerung, um dies zu vermeiden. Es dauerte bis zu ~2 Stunden und 40 Minuten, bis das Problem in us-central-1 vollständig behoben war, da wir die Erstellung von Aufgaben drosselten, um die Auswirkungen auf die zugrunde liegende Infrastruktur zu minimieren, und den Datenverkehr an multiregionale Datenbanken umleiteten, um die Last zu reduzieren. Zu diesem Zeitpunkt waren die Service Control und der API-Dienst in allen Regionen vollständig wiederhergestellt. Die entsprechenden Google- und Google Cloud-Produkte begannen sich zu erholen, wobei einige aufgrund ihrer Architektur etwas länger benötigten.

Wie geht es jetzt weiter?

Unmittelbar nach der Wiederherstellung haben wir alle Änderungen am Service Control Stack und manuelle Richtlinienübernahmen eingefroren, bis wir das System vollständig reparieren können.

Wie haben wir kommuniziert?

Wir haben unseren ersten Vorfallbericht etwa eine Stunde nach Beginn der Abstürze in Cloud Service Health veröffentlicht, da die Cloud Service Health-Infrastruktur aufgrund dieses Ausfalls nicht verfügbar war. Bei einigen Kunden fiel auch die Überwachungsinfrastruktur aus, die sie auf Google Cloud betrieben, sodass sie keine Meldung über den Vorfall erhielten und keine Informationen über die Auswirkungen auf ihr Geschäft und/oder ihre Infrastruktur hatten. Wir werden uns in Zukunft darum kümmern.

Wie gehen wir weiter vor?

Über das oben erwähnte Einfrieren des Systems hinaus werden wir die folgenden Maßnahmen priorisieren und sicher umsetzen:

• Wir werden die Architektur von Service Control modularisieren, sodass die Funktionen isoliert sind und bei Ausfällen offen bleiben. Wenn eine entsprechende Überprüfung fehlschlägt, kann Service Control weiterhin API-Anfragen bedienen.
• Wir werden alle Systeme überprüfen, die global replizierte Daten verwenden. Unabhängig von der geschäftlichen Notwendigkeit einer nahezu sofortigen globalen Konsistenz der Daten (d. h. globale Quotenverwaltungseinstellungen) muss die Datenreplikation schrittweise und mit ausreichend Zeit für die Validierung und Erkennung von Problemen erfolgen.
• Wir werden alle Änderungen an kritischen Binärdateien mit Feature-Flags schützen und standardmäßig deaktivieren.
• Wir werden unsere statischen Analyse- und Testverfahren verbessern, um Fehler korrekt zu behandeln und gegebenenfalls einen Fail-Open zu ermöglichen.
• Wir werden überprüfen und sicherstellen, dass unsere Systeme einen zufälligen exponentiellen Backoff verwenden.
• Wir werden unsere externe Kommunikation, sowohl automatisiert als auch manuell, verbessern, damit unsere Kunden so schnell wie möglich die Informationen erhalten, die sie benötigen, um auf Probleme zu reagieren, ihre Systeme zu verwalten und ihren Kunden zu helfen.
• Wir werden sicherstellen, dass unsere Überwachungs- und Kommunikationsinfrastruktur auch dann betriebsbereit bleibt, wenn Google Cloud und unsere primären Überwachungsprodukte ausgefallen sind, um die Geschäftskontinuität zu gewährleisten.

Kurzbericht zum Vorfall

Wir bedauern die Auswirkungen, die diese Dienstunterbrechung/dieser Ausfall für alle unsere Nutzer und deren Kunden hatte, zutiefst. Große und kleine Unternehmen vertrauen Google Cloud ihre Arbeitslasten an, und wir werden uns verbessern. In den kommenden Tagen werden wir einen vollständigen Bericht zum Vorfall veröffentlichen, der die Ursache, einen detaillierten Zeitplan und die von uns ergriffenen Maßnahmen zur Behebung des Problems enthält. Angesichts des Ausmaßes und der Auswirkungen dieses Vorfalls möchten wir Ihnen nachfolgend einige Informationen zur Verfügung stellen.

Bitte beachten Sie, dass diese Informationen auf unserem aktuellen Kenntnisstand zum Zeitpunkt der Veröffentlichung basieren und sich im Laufe unserer Untersuchungen noch ändern können. Wenn Sie von anderen als den unten aufgeführten Auswirkungen betroffen sind, wenden Sie sich bitte an den Google Cloud-Support unter https://cloud.google.com/support oder an den Google Workspace-Support über den Hilfeartikel https://support.google.com/a/answer/1047213.

(Alle Zeiten in US/Pacific)

Beginn des Vorfalls: 12. Juni 2025, 10:49 Uhr

Alle Regionen außer us-central1 behoben: 12. Juni 2025, 12:48 Uhr

Ende des Vorfalls: 12. Juni 2025, 13:49 Uhr

Dauer: 3 Stunden

Regionen/Zonen: Weltweit

Beschreibung:

Bei mehreren Google Cloud- und Google Workspace-Produkten kam es zu vermehrten 503-Fehlern bei externen API-Anfragen, wodurch Kunden beeinträchtigt waren.

Nach unserer ersten Analyse trat das Problem aufgrund einer ungültigen automatischen Quota-Aktualisierung unseres API-Managementsystems auf, die weltweit verteilt wurde und dazu führte, dass externe API-Anfragen abgelehnt wurden. Um das Problem zu beheben, haben wir die fehlerhafte Kontingentprüfung umgangen, wodurch die Wiederherstellung in den meisten Regionen innerhalb von zwei Stunden möglich war. Die Kontingentrichtlinien-Datenbank in us-central1 war jedoch überlastet, was zu einer deutlich längeren Wiederherstellungszeit in dieser Region führte. Bei mehreren Produkten kam es nach Behebung des primären Problems noch bis zu einer Stunde lang zu moderaten Restauswirkungen (z. B. Rückstände), die anschließend in wenigen Fällen behoben wurden.

Google wird in den nächsten Tagen einen vollständigen Vorfallsbericht erstellen, der die genaue Ursache enthält.

Auswirkungen auf Kunden:

Kunden hatten zeitweise Probleme mit dem Zugriff auf die API und die Benutzeroberfläche der betroffenen Dienste. Bestehende Streaming- und IaaS-Ressourcen waren nicht betroffen.

Weitere Details:

Dieser Vorfall hätte nicht auftreten dürfen. Wir werden die folgenden Maßnahmen ergreifen, um eine Wiederholung in Zukunft zu verhindern:

• Verhindern, dass unsere API-Verwaltungsplattform aufgrund ungültiger oder beschädigter Daten ausfällt.
• Verhindern, dass Metadaten ohne angemessenen Schutz, Tests und Überwachung global verbreitet werden.
• Verbessern der Systemfehlerbehandlung und umfassender Tests für den Umgang mit ungültigen Daten.

Betroffene Dienste und Funktionen:

Google Cloud-Produkte:

• Identitäts- und Zugriffsverwaltung
• Cloud Build
• Cloud Key Management Service
• Google Cloud Storage
• Cloud Monitoring
• Google Cloud Dataproc
• Cloud Security Command Center
• Artifact Registry
• Cloud Workflows
• Cloud Healthcare
• Resource Manager API
• Dataproc Metastore
• Cloud Run
• VMWare-Engine
• Dataplex
• Migration zu virtuellen Maschinen
• Google BigQuery
• Contact Center AI-Plattform
• Google Cloud Deploy
• Media CDN
• Colab Enterprise
• Vertex Gemini API
• Cloud Data Fusion
• Cloud Asset Inventory
• Datastream
• Integrationskonnektoren
• Apigee
• Google Cloud NetApp Volumes
• Google Cloud Bigtable
• Looker (Google Cloud Core)
• Looker Studio
• Google Cloud Functions
• Cloud-Lastenausgleich
• Traffic Director
• Dokument-KI
• AutoML-Übersetzung
• Pub/Sub Lite
• API Gateway
• Agent Assist
• AlloyDB für PostgreSQL
• Cloud Firestore
• Cloud Logging
• Cloud Shell
• Cloud Memorystore
• Cloud Spanner
• Contact Center Insights
• Datenbankmigrationsdienst
• Dialogflow CX
• Dialogflow ES
• Google App Engine
• Google Cloud Composer
• Google Cloud Console
• Google Cloud DNS
• Google Cloud Pub/Sub
• Google Cloud SQL
• Google Compute Engine
• Identity Platform
• Managed Service für Apache Kafka
• Memorystore für Memcached
• Memorystore für Redis
• Memorystore für Redis Cluster
• Persistent Disk
• Personalisierter Servicezustand
• Sprache-zu-Text
• Text-zu-Sprache
• Vertex AI Search
• Retail API
• Vertex AI Feature Store
• BigQuery Data Transfer Service
• Google Cloud Marketplace
• Cloud NAT
• Hybride Konnektivität
• Cloud Vision
• Netzwerkkonnektivitätscenter
• Cloud-Workstations
• Google Security Operations

Google Workspace-Produkte:

• AppSheet
• Gmail
• Google Kalender
• Google Drive
• Google Chat
• Google Voice
• Google Docs
• Google Meet
• Google Cloud Search
• Google Tasks

Quelle: Google Cloud Services Health

---

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