A VPC de um cluster RDS/Aurora é fixada na criação e não muda depois

O que aconteceu

O cluster Aurora marketing-leads-production tinha sido criado na VPC compartilhada (sub-redes privadas), enquanto o staging — e o que o leads.tf descrevia — usava a VPC mkt (sub-redes públicas). Quando surgiu o requisito de expor uma réplica de leitura pública para o Looker Studio consultar, produção não conseguiu expor nada: o reader estava marcado como PubliclyAccessible: true, mas sua sub-rede privada só tinha rota de saída via NAT, sem nenhum caminho de entrada vindo da internet. E não havia como mover apenas o reader para a VPC pública.

Causa raiz

Duas restrições do RDS/Aurora se combinam:

  1. Todas as instâncias de um cluster compartilham um único DB subnet group, e o subnet group pertence a exatamente uma VPC. Não existe writer-na-VPC-A + reader-na-VPC-B dentro do mesmo cluster.
  2. Não dá para trocar a VPC de um cluster no lugar. O ModifyDBSubnetGroup rejeita sub-redes de outra VPC (The new Subnets are not in the same Vpc as the existing subnet group). Mudar de VPC significa recriar o cluster.

Ou seja: a VPC é decidida na criação e fica. Um cluster na VPC errada só se conserta recriando — via snapshot → restore, que é uma janela de risco sobre o dado mais crítico do projeto.

Correção

Migração por snapshot → restore, mantendo o cluster antigo como plano B:

  1. create-db-cluster-snapshot do cluster atual.
  2. Renomear cluster e instâncias atuais para -old (libera os nomes).
  3. No terraform: snapshot_identifier temporário no aws_rds_cluster + lifecycle { ignore_changes = [master_password, snapshot_identifier] } (a senha master vem do snapshot; não regerar o random_password).
  4. terraform state rm dos recursos antigos (preservando o random_password) e apply — recria o cluster a partir do snapshot, na VPC correta.
  5. Detalhe: o nome do DB subnet group é único por conta/região (não por VPC), então o novo subnet group precisa de um nome distinto enquanto o -old coexiste (por exemplo, um sufixo -mkt). Já o nome de security group é único por VPC, então não colide entre VPCs diferentes.
  6. Validar o cluster novo, depois derrubar o -old e remover o snapshot_identifier.

Como evitar

Escolher a VPC certa na criação é uma decisão importante e, na prática, irreversível. Antes de criar um cluster RDS/Aurora, decida explicitamente:

  • Precisa de acesso público (Looker, ferramenta SaaS externa, colega externo)? → VPC com sub-redes públicas + IGW. O writer continua publicly_accessible = false e só o reader fica true; a proteção é SSL obrigatório (rds.force_ssl) + usuário somente-leitura, não esconder o banco.
  • Só uso interno (EKS, apps dentro da VPC)? → sub-redes privadas.
  • Todo ambiente (staging/produção) precisa nascer na mesma VPC e topologia. Divergência entre ambientes indica que um foi criado antes do terraform final — corrigir cedo, enquanto ainda não há dado, é barato; depois vira snapshot/restore.

Ver também a skill commons:database (“Choosing the VPC — decide up front”) e o aprendizado database_aurora_password_authentication.