Résumé

  • Google Cloud annonce le 8 septembre la disponibilité générale des points d'accès régionaux pour l'API d'administration Cloud SQL for MySQL, après une préversion lancée en mai.
  • La frontière concerne le frontal et certaines requêtes ; elle ne supprime ni toutes les dépendances mondiales ni les exceptions de restauration.

Dans un cahier des charges, « régional » semble parfois décrire un service entier. Pour Cloud SQL, il faut désormais préciser ce que ce mot qualifie : l'emplacement de l'instance, le frontal qui reçoit une requête d'administration, ou les composants dont dépend la réponse. Les trois périmètres ne se confondent pas.

La publication du 8 septembre de Google Cloud annonce la disponibilité générale des points d'accès régionaux de l'API d'administration Cloud SQL for MySQL. La fonctionnalité figurait déjà en préversion dans les notes du 11 mai. Il s'agit donc d'un changement de stade, pas d'une première possibilité de choisir une entrée régionale.

Une frontière utile, un inventaire partiel

Le guide d'exploitation distingue le frontal régional du chemin passant par l'équilibrage de charge mondial. Pour les opérations soumises à une correspondance régionale, la ressource visée doit se trouver dans la région du point d'accès ; sinon, la requête reçoit une erreur 4xx.

La liste des instances change elle aussi de portée. Le point d'accès mondial restitue les instances des différentes régions, tandis qu'un point régional ne retourne que celles de sa propre région. Une réponse techniquement réussie peut donc être insuffisante pour un inventaire d'entreprise. Il faut vérifier la couverture de la collecte, pas simplement son absence d'erreur.

Pour l'acheteur, la valeur réside dans une dépendance frontale mieux délimitée. Le guide indique toutefois que certaines dépendances de l'API côté serveur et certaines métadonnées peuvent encore reposer sur des composants mondiaux. Le fournisseur ne devient pas une juxtaposition de services entièrement autonomes parce que plusieurs adresses d'entrée existent.

La restauration oblige à conserver les nuances

Les ressources de sauvegarde sont considérées comme mondiales afin de permettre des restaurations entre régions. Google Cloud recommande le point d'accès mondial pour leur accès et leur restauration, sans interdire l'accès régional. Le cas de BackupRuns est distinct : cette ressource est servie depuis la région de l'instance. Une règle unique affirmant que « les sauvegardes sont régionales » serait donc trompeuse.

Les outils ne suivent pas non plus un chemin uniforme. gcloud et Terraform peuvent utiliser les points régionaux avec une configuration manuelle de remplacement. La console et Config Connector ne les prennent pas en charge ; le serveur MCP distant de Cloud SQL conserve son point d'accès mondial. Les méthodes d'authentification, les chemins, les corps de requête et les versions d'API restent inchangés.

Enfin, ces points d'administration ne sont actuellement accessibles que par une connexion réseau publique. L'accès privé et les adresses couvrant plusieurs régions ne sont pas pris en charge. Cela ne signifie pas qu'une base privée doit être exposée publiquement : la restriction porte sur l'accès à l'API d'administration.

La nouvelle option peut être utile sans constituer, à elle seule, une garantie globale de résidence des données ou de conformité. Elle impose surtout de faire correspondre les promesses du contrat d'exploitation aux chemins réellement employés. Aucune économie client mesurée ni nouvelle tarification ne permet ici de chiffrer automatiquement son avantage.