Acesso público ao banco de leads via VPC mkt

TLDR: Criar uma VPC pública dedicada na conta AWS mkt, com VPC Peering para a VPC compartilhada, de modo que o cluster Aurora de leads seja alcançável tanto da Hetzner (endpoint público direto) quanto do EKS (via peering).

Contexto

O cluster Aurora de leads vive na conta mkt, usando sub-redes privadas RAM-compartilhadas da conta shared. Essas sub-redes não podem ser usadas com publicly_accessible = true (a AWS as rejeita para RDS público quando não pertencem à conta). O cluster fica, portanto, inalcançável de fora da VPC — bloqueando o acesso direto a partir do n8n rodando na Hetzner.

Este é um arranjo temporário: quando a stack inteira migrar para a Hetzner, a VPC pública e o peering são deletados. Nenhuma mudança no repo infrastructure — tudo fica em automation/.infra/terraform/.

Objetivos

  • Endpoint de writer do Aurora de leads alcançável da Hetzner (IP público, porta 5432, SSL)
  • Aurora de leads ainda alcançável pelos pods do EKS na VPC compartilhada (via peering)
  • Toda a infra contida no repo marketing, deletável de uma vez quando não for mais necessária

Fora de escopo

— (não registrado na spec original)

Mudanças

automation/.infra/terraform/network_mkt.tf (novo)

  • aws_vpc.mkt — VPC pequena (10.1.0.0/16) na conta mkt (provider aws.mkt)
  • aws_internet_gateway.mkt — IGW ligado à VPC mkt
  • aws_subnet.mkt_public[3] — uma sub-rede pública por AZ (us-east-1a/b/c, 10.1.{0,1,2}.0/24)
  • aws_route_table.mkt_public + aws_route_table_association — rota default via IGW
  • aws_vpc_peering_connection.mkt_shared — pedido de peering da VPC mkt para a shared (o accepter é o provider aws default / conta management, que tem acesso à VPC compartilhada)
  • aws_vpc_peering_connection_accepter.mkt_shared — aceite do lado shared
  • aws_route.mkt_to_shared — rota na route table pública da mkt para o CIDR da VPC compartilhada, via peering
  • aws_route.shared_to_mkt — rota na(s) route table(s) privada(s) da VPC compartilhada para o CIDR da mkt, via peering (exige os IDs das route tables da VPC compartilhada vindos das saídas do remote state de rede — pode ser preciso adicionar essas saídas à stack de rede da infra antes, ou usar um data source)

automation/.infra/terraform/leads.tf (alterado)

  • aws_db_subnet_group.leads — passa a usar aws_subnet.mkt_public[*].id
  • aws_rds_cluster_instance.leads_writer e leads_reader — publicly_accessible (já definido)
  • aws_security_group.leads_db — mantém a regra de entrada da VPC + a regra pública 0.0.0.0/0 (já adicionada)

Como verificar

  • psql -h marketing-leads-production.cluster-<id>.us-east-1.rds.amazonaws.com -U leads -d leads conecta de uma máquina Hetzner/local fora da AWS
  • Um pod do EKS em marketing-automation--production também alcança o endpoint de writer do Aurora
  • terraform destroy -target=aws_vpc_peering_connection.mkt_shared -target=aws_vpc.mkt limpa tudo sem afetar o cluster Aurora (o cluster volta a ficar nas sub-redes privadas RAM-compartilhadas depois da reversão)

Documentação

  • O aprendizado database_cluster_vpc_is_fixed_at_creation registra o desdobramento desta mudança: como o cluster de produção nascera na VPC compartilhada, movê-lo para a VPC mkt exigiu snapshot/restore, não um apply simples.