Resumo

  • Google Cloud anunciou em 8 de setembro a disponibilidade geral dos endpoints regionais da API de administração do Cloud SQL for MySQL, antes em prévia.
  • O novo alcance do frontend não equivale à independência de todo o serviço; inventário e recuperação continuam exigindo atenção própria.

Uma política de nuvem regional só é tão clara quanto suas exceções. No Cloud SQL, uma chamada administrativa pode entrar pela região escolhida, uma listagem pode enxergar apenas parte do parque e uma operação de recuperação pode seguir a recomendação de usar o endpoint global. Não são três bancos diferentes: são fronteiras operacionais diferentes.

A atualização de 8 de setembro do Google Cloud coloca os endpoints regionais da API de administração do Cloud SQL for MySQL em disponibilidade geral. A cronologia do produto já registrava a prévia em 11 de maio. A mudança atual é de estágio de lançamento, não a criação de um serviço autônomo em cada região.

O inventário também muda de tamanho

O guia de utilização explica que o endereço regional encaminha a chamada à infraestrutura de frontend da região indicada, em vez de passar primeiro pelo balanceador global. Nas operações sujeitas à correspondência regional, o recurso e o endpoint precisam apontar para a mesma região. Caso contrário, a resposta é um erro 4xx.

A listagem de instâncias tem uma diferença menos ruidosa. Pelo endpoint global, ela abrange instâncias de várias regiões; pelo regional, somente as daquela região. Uma resposta bem-sucedida, portanto, não comprova que o inventário corporativo está completo. Se a contagem cair após a troca de endereço, isso não demonstra que bancos foram excluídos.

Para quem compra e opera o serviço, essa fronteira é útil, mas cria trabalho de coordenação. É preciso definir quem reúne as visões locais e quem verifica sua cobertura. Sem isso, cada equipe pode manter uma lista correta e, ainda assim, a organização não ter uma visão correta do conjunto.

A parte global não desaparece

A própria documentação ressalta que algumas dependências internas da API e certos metadados ainda podem depender de componentes globais. Regionalizar o frontend não garante isolamento integral, residência de todos os dados em todas as etapas ou conformidade automática com uma norma.

As cópias de segurança mostram por que a ressalva importa. Esses recursos são tratados como globais para viabilizar restaurações entre regiões; Google Cloud recomenda o endpoint global para acessá-los e recuperá-los. O acesso regional continua possível. Já BackupRuns tem tratamento distinto e é servido pela região da instância. Resumir os dois como «backup regional» apagaria uma diferença relevante para a recuperação.

gcloud e Terraform podem usar os novos endpoints por meio de configurações manuais que substituem o endereço padrão. O console e Config Connector não têm suporte, e o servidor MCP remoto do Cloud SQL permanece no endpoint global. Métodos de autenticação, corpo das chamadas, caminhos e versões da API não mudam.

O acesso aos endpoints regionais administrativos está limitado, por enquanto, a conexões de rede públicas. Não há suporte a conexões privadas nem a endereços que englobem várias regiões. Isso não exige tornar pública uma instância privada de banco de dados: a limitação trata da conexão com a API de administração.

O ganho possível está em delimitar melhor uma parte da dependência operacional. O anúncio não oferece preço novo ou economia de cliente medida que permita atribuir a essa escolha um retorno financeiro automático.