Cloud SQL bekommt regionale API-Endpunkte – Backups bleiben global

Google hat regionale Endpunkte der Cloud SQL Admin API am 8. September 2026 für MySQL, PostgreSQL und SQL Server allgemein verfügbar gemacht. Die Cloud-SQL-Versionshinweise zum GA-Start nennen für alle drei Datenbank-Engines regional isolierte Frontends und Load Balancer.

Cloud-Architekten können administrative Aufrufe damit in die Region der jeweiligen Instanz lenken und die Abhängigkeit von globaler Frontend-Infrastruktur verringern. Eine unabhängige Einordnung der Veröffentlichung bestätigt Datum und Umfang, weist aber ebenfalls auf die entscheidende Grenze hin: Regionalisiert wird der Zugang zum Admin-API-Frontend, nicht jede beteiligte Komponente.

Das regionale Frontend verbessert Lokalität und Isolation

Für einen regionalen Aufruf wird der globale Host sqladmin.googleapis.com durch eine Adresse nach dem Muster sqladmin.{region}.rep.googleapis.com ersetzt. Authentifizierung, API-Pfade, Request-Bodies und API-Versionen ändern sich dabei nicht. Die technische Dokumentation der regionalen Endpunkte beschreibt das URL-Schema sowie sämtliche Migrationsgrenzen.

Die Frontend- und Load-Balancing-Infrastruktur verarbeitet den Verkehr in derselben Region wie die Instanz. Auch Zertifikatsverwaltung und TLS-Terminierung erfolgen am regionalen Load Balancer. Fällt das Frontend oder der Load Balancer einer Region aus, sollen die entsprechenden Komponenten anderer Regionen durch getrennte regionale Kontrollpfade unberührt bleiben.

Der Compliance-Nutzen ist dennoch enger als eine vollständig regionale Admin API. Die Zusage betrifft Daten während der Übertragung und die Frontend-Verarbeitung; bestimmte Backend-Abhängigkeiten und Metadaten können weiterhin globale Komponenten nutzen. Eine Architekturprüfung darf den neuen Host deshalb nicht mit einer durchgehend regionalen Verarbeitung aller Kontrolldaten gleichsetzen.

Jeder Aufruf muss zur Region der Ressource passen

Regionale Endpunkte erzwingen eine strikte Zuordnung zwischen Host und Zielressource. Bei GET-, INSERT-, UPDATE-, PATCH- und DELETE-Aufrufen führt eine abweichende Region zu einem Fehler der 4xx-Klasse. Ein dauerhaft eingestellter regionaler Host kann daher keine Ressourcen in beliebigen anderen Regionen verwalten.

Auch Instances.List ändert sein Verhalten. Über den globalen Endpunkt kann der Aufruf Instanzen aus allen verwendeten Regionen eines Projekts liefern; ein regionaler Endpunkt gibt nur Instanzen seiner eigenen Region zurück. Zentrale Inventarisierungs-, Sicherheits- oder Kostenprozesse müssen ihre Ergebnisse folglich über die verwendeten Regionen zusammenführen oder für diesen Zweck beim globalen Endpunkt bleiben.

Für DACH-Umgebungen stehen in der veröffentlichten Liste unter anderem europe-west3, europe-west10 und europe-west6. Ein eigener österreichischer Regionalcode ist dort nicht aufgeführt. Maßgeblich ist stets die tatsächliche Instanzregion, nicht der Standort des Administrators oder des ausführenden CI-Runners.

gcloud und Terraform wechseln nicht automatisch

Die allgemeine Verfügbarkeit bringt keine automatische Endpunktauswahl in allen Werkzeugen. Für die gcloud CLI muss api_endpoint_overrides/sql auf die passende regionale Basisadresse gesetzt werden. Terraform erwartet dafür GOOGLE_SQL_CUSTOM_ENDPOINT; der dokumentierte Wert endet nach dem regionalen Host zusätzlich auf /sql.

Bei einer Plattform mit mehreren Regionen sollte jeder Deployment-Lauf den Endpunkt der Ressource erhalten, die er tatsächlich verwaltet. Ein gemeinsam genutzter Runner mit einem festen Override würde Anfragen für andere Regionen an den falschen Host senden. Die Zuordnung gehört deshalb in die regionsbezogene Laufzeitkonfiguration und muss unabhängig vom Terraform-State nachvollziehbar bleiben.

Für die Google Cloud Console und Kubernetes Config Connector gibt es derzeit keine Unterstützung regionaler Endpunkte. Auch der Remote-MCP-Server von Cloud SQL ist auf den globalen Zugang beschränkt. Ein umgestellter REST-Client regionalisiert somit weder diese Werkzeuge noch andere Verwaltungswege automatisch.

Backups bilden eine bewusst globale Ausnahme

Backups bleiben globale Ressourcen, damit eine Wiederherstellung über Regionsgrenzen hinweg auch beim Ausfall einer einzelnen Region möglich bleibt. Regionale Endpunkte können zwar auf Backups zugreifen, für das Erstellen, den Zugriff und die Wiederherstellung wird jedoch weiterhin der globale Endpunkt empfohlen. Der globale Status beschreibt also die Ressource und den bevorzugten Verwaltungsweg, nicht eine technische Sperre regionaler Hosts.

Davon zu unterscheiden sind BackupRuns. Sie werden über den regionalen Endpunkt der Region bereitgestellt, in der sich die zugehörige Instanz befindet. Migrationsregeln müssen folglich gewöhnliche Backup-Ressourcen und instanzgebundene BackupRuns getrennt behandeln.

Für die Umstellung ergibt sich damit eine kompakte Prüffolge:

1. Die Region jeder Instanz erfassen und mit der Liste unterstützter regionaler Hosts abgleichen.
2. Den globalen Basis-Host in eigenen API-Clients durch den exakt passenden regionalen Host ersetzen.
3. Positive Aufrufe und bewusst falsch zugeordnete Requests auf die erwartete Regionsprüfung testen.
4. Regionale Listenabfragen aggregieren oder den globalen Listenpfad beibehalten.
5. gcloud- und Terraform-Overrides pro Ausführungsumgebung setzen.
6. Backups über den globalen Pfad planen und BackupRuns der Instanzregion zuordnen.

Private Verwaltungswege bleiben vorerst außen vor

Ein regionaler Endpunkt der Cloud SQL Admin API ist gegenwärtig nur über öffentliche Netzwerkverbindungen erreichbar. Aufrufe aus einer VPC oder über eine private Netzwerkverbindung werden nicht unterstützt. Ebenso fehlen multiregionale Hosts, die mehrere europäische Regionen unter einer gemeinsamen Adresse abdecken.

Damit ist der Stand klar abgegrenzt: Seit dem 8. September 2026 steht ein allgemein verfügbarer, regional isolierter Frontend-Pfad für die Admin APIs der drei Cloud-SQL-Engines bereit. Vollständig private Administration, mehrere Verwaltungswerkzeuge, globale Backend-Abhängigkeiten und die bevorzugte Backup-Verarbeitung bleiben außerhalb dieses Regionalisierungsumfangs. Ob und wann diese Lücken geschlossen werden, ist bislang nicht angekündigt.

Lesen Sie auch:

• GPT-6 Astra ist da – die stärksten Cyberfunktionen bleiben begrenzt
• Claude Cowork bekommt einen eigenen Browser – Passwörter bleiben getrennt
• VMware bündelt Private AI Cloud – 150 Modelle lösen die Kostenfrage nicht