Zusammenfassung

  • Google Cloud meldet am 8. September die allgemeine Verfügbarkeit regionaler Endpunkte für die Verwaltungs-API von Cloud SQL for MySQL; die Vorschau begann im Mai.
  • Regional wird ein Teil des Zugangs, nicht zwangsläufig die gesamte Dienstabhängigkeit. Inventar und Wiederherstellung folgen unterschiedlichen Regeln.

Wer einen regionalen Cloud-Dienst einkauft, muss inzwischen genauer fragen, welche Ebene gemeint ist. Der Standort einer Datenbank, der Eingang einer Verwaltungsanfrage und die Abhängigkeiten hinter diesem Eingang beschreiben nicht dieselbe Grenze. Die neue Cloud-SQL-Option macht diese Unterscheidung im Betrieb sichtbar.

Laut Google Clouds Mitteilung vom 8. September sind regionale Endpunkte für die Verwaltungs-API von Cloud SQL for MySQL nun allgemein verfügbar. Die MySQL-Versionshinweise führten sie bereits am 11. Mai als Vorschau auf. Es geht um einen neuen Freigabestatus, nicht um die erstmalige Einführung regionaler Zugänge.

Ein erfolgreicher Abruf kann unvollständig sein

Die Betriebsdokumentation beschreibt einen regionalen Eingang, der Anfragen an die Frontend-Infrastruktur der gewählten Region führt. Der bisherige globale Eingang nutzt zunächst einen globalen Lastverteiler. Bei Operationen mit vorgeschriebener Regionszuordnung müssen Endpunkt und Zielressource zusammenpassen; andernfalls wird die Anfrage mit einem 4xx-Fehler abgewiesen.

Bei der Instanzliste ist der Unterschied leiser. Über den globalen Endpunkt enthält sie Instanzen aus mehreren Regionen, über einen regionalen nur die dort vorhandenen. Ein fehlerfrei abgeschlossener Inventarlauf beweist deshalb nicht, dass der gesamte Bestand erfasst ist. Weniger Einträge nach dem Wechsel bedeuten auch nicht, dass Datenbanken gelöscht wurden.

Für zentrale Plattformteams entsteht damit eine konkrete Aufgabe: Sie müssen den Erfassungsbereich definieren und regionale Listen zu einer belastbaren Gesamtsicht abgleichen. Mehrere richtige Teillisten können nebeneinander bestehen, ohne dass jemand den vollständigen Bestand kennt. Das ist eine Folgerung aus der API-Semantik, kein berichteter Kundenstörfall.

Die globale Ebene bleibt sichtbar

Die Dokumentation hält ausdrücklich fest, dass bestimmte Backend-Abhängigkeiten der API und Metadaten weiterhin globale Komponenten benötigen können. Ein regionales Frontend ist daher weder vollständige Dienstisolation noch ein automatischer Nachweis rechtlicher Konformität.

Auch bei Sicherungen ist Differenzierung nötig. Backup-Ressourcen werden global behandelt, um Wiederherstellungen über Regionsgrenzen hinweg zu ermöglichen. Google Cloud empfiehlt dafür den globalen Endpunkt, obwohl regionaler Zugriff möglich bleibt. Davon unterscheidet die Dokumentation BackupRuns: Diese Ressource wird über die Region der Instanz bedient. Eine pauschale Regel für sämtliche Sicherungsoperationen würde den Unterschied verdecken.

gcloud und Terraform unterstützen die Nutzung regionaler Endpunkte mittels manueller Überschreibungen der Standardkonfiguration. Für die Konsole und Config Connector fehlt die Unterstützung; der entfernte Cloud-SQL-MCP-Server verwendet weiterhin seinen globalen Endpunkt. Authentifizierungsmethoden, Anfrageinhalte, API-Pfade und Versionen bleiben unverändert.

Der Zugang zu den regionalen Verwaltungsendpunkten ist derzeit auf öffentliche Netzwerkverbindungen beschränkt. Private Verbindungen und Endpunktadressen für mehrere Regionen werden nicht unterstützt. Daraus folgt keine Pflicht, eine private Datenbank öffentlich erreichbar zu machen: Es geht um die Verbindung zur Verwaltungs-API.

Der wirtschaftliche Nutzen lässt sich somit nicht aus der Zahl regionaler Adressen ablesen. Käufer erhalten eine genauer begrenzte Frontend-Abhängigkeit, müssen aber die unterschiedlichen Betriebswege beherrschen. Neue Preise oder gemessene Kundeneinsparungen nennt die Ankündigung nicht.