Cluster Aurora dedicado para o leads

TLDR: Provisionar um cluster Aurora PostgreSQL Serverless v2 dedicado ao leads (writer + reader), por workspace (staging/produção), separado do cluster do n8n.

Contexto

Hoje o leads é apenas um banco criado dentro do cluster Aurora compartilhado do n8n (marketing-automation-<env>), que roda uma única instância db.serverless (ver automation/.infra/terraform/database.tf). O leads é o dataset mais importante do projeto e não deveria dividir ciclo de vida, escalabilidade nem raio de impacto com o n8n.

Provisionamos um cluster Aurora PostgreSQL Serverless v2 dedicado só para o leads, com uma instância writer completa e uma reader somente-leitura, em staging e em produção. Ele vive na mesma VPC compartilhada (sub-redes privadas RAM-compartilhadas), para que a carga no EKS o alcance de forma privada, e reutiliza o remote state de rede e o provider AWS existentes (aws.mkt, conta 970959930130).

O cluster é parametrizado por workspace, seguindo o padrão já existente (local.environment = terraform.workspace).

Nota sobre Aurora Serverless v2

No Aurora Serverless v2 a faixa de ACU (serverlessv2_scaling_configuration, min/max) é definida no nível do cluster — writer e reader compartilham a mesma faixa. Um teto de escala por reader não é nativamente possível dentro de um mesmo cluster, então writer e reader dividem a faixa. Ainda assim, o reader é uma instância distinta, servindo leituras pelo endpoint de reader.

Objetivos

  • Criar um cluster marketing-leads-<env> dedicado (writer + reader), separado do n8n
  • Mesma topologia em staging e produção; a faixa de ACU varia por ambiente (produção 0–16, staging 0–8)
  • O reader serve leituras (somente-leitura pelo endpoint de reader), com promotion_tier alto para não promover na frente do writer
  • Reutilizar a rede da VPC compartilhada (sub-redes privadas), com subnet group e security group dedicados
  • Criar o role leads e seus grants dentro do cluster, e expor os dados de conexão à app por um secret do k8s

Fora de escopo

  • Migração dos dados e limpeza do banco leads antigo (dentro do cluster do n8n) ficam fora.
  • Nenhuma mudança em database.tf — o cluster do n8n e seu banco leads embutido ficam como estão por ora.

Mudanças — automation/.infra/terraform

leads.tf (novo):

  • local.leads_scaling — mapa por ambiente: production = { min = 0, max = 16 }, staging = { min = 0, max = 8 }
  • random_password.leads_master — senha master do cluster
  • random_password.leads_app — senha do role de login leads
  • aws_db_subnet_group.leads — marketing-leads-<env>, sub-redes privadas da VPC compartilhada (data.terraform_remote_state.network.outputs.private_subnet_ids)
  • aws_security_group.leads_db — marketing-leads-db-<env>, entrada 5432 a partir do CIDR da VPC, saída liberada
  • aws_rds_cluster.leads — marketing-leads-<env>, aurora-postgresql 17.7, engine_mode = provisioned, database_name = "leads", master postgres, skip_final_snapshot = true, serverlessv2_scaling_configuration a partir de local.leads_scaling[local.environment]
  • aws_rds_cluster_instance.leads_writer — marketing-leads-<env>-writer, db.serverless, publicly_accessible = false, promotion_tier = 0
  • aws_rds_cluster_instance.leads_reader — marketing-leads-<env>-reader, db.serverless, publicly_accessible = false, promotion_tier = 15
  • kubernetes_job.leads_db_setup — job psql (mesmo padrão de automation_db_setup) que cria/atualiza o role LOGIN leads, concede a associação do role ao postgres e concede privilégios de schema e privilégios default no banco leads. Aponta PGHOST para o endpoint de writer do cluster.
  • kubernetes_secret.leads_db (ou estender o secret existente em secrets.tf) — expõe LEADS_DB_WRITER_HOST (aws_rds_cluster.leads.endpoint), LEADS_DB_READER_HOST (aws_rds_cluster.leads.reader_endpoint), LEADS_DB_PORT, LEADS_DB_NAME, LEADS_DB_USER, LEADS_DB_PASSWORD

Como verificar

  • terraform workspace select staging && terraform plan mostra o novo cluster marketing-leads-staging (writer + reader, 0–8) e nenhuma mudança inesperada nos recursos do n8n
  • Depois do terraform apply (staging), o cluster reporta uma instância writer e uma reader; o endpoint de reader resolve
  • terraform workspace select production && terraform plan mostra marketing-leads-production com 0–16
  • O job leads-db-setup do k8s completa com sucesso; conectando com o usuário leads no endpoint de writer chega-se ao banco leads e é possível criar/ler uma tabela; o endpoint de reader serve leituras
  • O secret do k8s contém hosts distintos para writer e reader

Documentação