Google-Cloud-Ausfall: Wenn ein globaler Dienst die halbe Cloud mitreißt
Ein fehlerhaftes Update in Googles Service Control legte am 12. Juni zahlreiche Cloud-Dienste für Stunden lahm. Betroffen waren nicht nur Google-Kunden, sondern auch Anbieter, die auf Google Cloud aufbauen. Was kleine und mittlere Unternehmen daraus über versteckte Abhängigkeiten lernen können.
Was ist passiert?
Am 12. Juni 2025 lieferten viele APIs der Google Cloud Platform und von Google Workspace plötzlich Fehler zurück. Laut Googles Statusseite dauerte der Vorfall von 10:51 bis 18:18 Uhr pazifischer Zeit, also bis in die Nacht nach mitteleuropäischer Zeit. Die meisten Produkte liefen nach rund drei Stunden wieder, einzelne Dienste brauchten deutlich länger. Betroffen waren unter anderem Compute Engine, Cloud Storage, BigQuery, Cloud Run und Cloud SQL sowie Gmail und Drive, und zwar in nahezu allen Regionen.
Die Ursache lag in Service Control, einem zentralen Baustein, der API-Anfragen unter anderem auf Berechtigungen und Kontingente prüft. Ende Mai hatte Google dort eine neue Prüflogik ausgerollt, ohne Fehlerbehandlung und ohne Feature-Flag. Am 12. Juni gelangte eine Richtlinienänderung mit leeren Feldern in die regionalen Spanner-Tabellen. Diese Daten wurden innerhalb von Sekunden weltweit repliziert. Beim Verarbeiten stieß der Code auf einen Nullzeiger, und Service Control geriet in allen Regionen in eine Absturzschleife. In der Region us-central1 verzögerte sich die Erholung zusätzlich, weil die massenhaften Neustarts die darunterliegende Datenbank überlasteten.
Auch Dienste, die auf Google Cloud aufbauen, fielen aus. Cloudflare meldete einen rund zweieinhalbstündigen Ausfall von Workers KV, weil ein Teil des Speichers bei einem externen Cloud-Anbieter lag. In der Folge waren auch Access, WARP, Turnstile und Teile des Dashboards gestört. Cloudflare will Workers KV nun von einzelnen Anbietern unabhängiger machen.
Google hat angekündigt, Service Control modularer aufzubauen, sodass fehlschlagende Prüfungen den API-Betrieb nicht mehr blockieren. Außerdem sollen global replizierte Daten künftig schrittweise verteilt und Änderungen an kritischen Komponenten grundsätzlich hinter Feature-Flags ausgeliefert werden.
Warum betrifft Sie das?
Viele Unternehmen sind überzeugt, Google Cloud gar nicht zu nutzen, und waren trotzdem betroffen. Der Grund sind indirekte Abhängigkeiten: Ihr Ticketsystem, Ihr Login-Anbieter, Ihr CDN oder ein Zahlungsdienst kann im Hintergrund auf genau der Plattform laufen, die gerade ausfällt. Hinzu kommt: Auch innerhalb einer einzelnen Cloud gibt es globale Komponenten. Eine Multi-Region-Architektur schützt nicht, wenn ein zentraler Steuerdienst überall gleichzeitig ausfällt.
Bemerkenswert ist außerdem, dass Kunden anfangs kaum Informationen hatten, weil auch Statusseiten und Monitoring betroffen waren. Wer sich allein auf die Statusseite seines Anbieters verlässt, erfährt von Problemen unter Umständen zu spät.
Was Sie jetzt tun sollten
- Abhängigkeiten inventarisieren: Erfassen Sie, welche Cloud- und SaaS-Dienste geschäftskritisch sind, und fragen Sie nach, auf welcher Infrastruktur diese wiederum laufen.
- Single Points of Failure identifizieren: Prüfen Sie, ob Login, DNS, Zahlungen oder Datenhaltung an einem einzigen Anbieter hängen.
- Notfallpläne schreiben: Legen Sie fest, wie Ihr Betrieb weiterläuft, wenn ein zentraler Dienst einige Stunden ausfällt, etwa mit Wartungsseite, manuellem Prozess oder Fallback-Anbieter.
- Eigenes Monitoring aufsetzen: Überwachen Sie Ihre wichtigsten Endpunkte von außen und unabhängig von der Plattform, auf der sie laufen.
- Statusseiten Dritter abonnieren: Bündeln Sie Status-Feeds Ihrer Dienstleister in einem gemeinsamen Kanal, zum Beispiel per RSS oder Webhook in Ihren Team-Chat.
- Eigene Deployments absichern: Übernehmen Sie Googles Lehren für Ihre Systeme: Feature-Flags für neue Codepfade, saubere Fehlerbehandlung, schrittweise Rollouts und Neustarts mit zufälligem exponentiellem Backoff.
Fazit
Der Ausfall zeigt, dass Hochverfügbarkeit nicht beim eigenen Cluster endet. Entscheidend ist, die gesamte Kette der Abhängigkeiten zu kennen und für den Ernstfall einen Plan zu haben. Das muss kein teures Multi-Cloud-Projekt sein: Oft reichen eine ehrliche Bestandsaufnahme, unabhängiges Monitoring und klar definierte Notfallprozesse. Wenn Sie Ihre Cloud-Architektur auf solche Risiken prüfen möchten, sprechen Sie uns an.