Amazon MQ para RabbitMQ em cluster tem restrições próprias

O que aconteceu

Ao migrar o messagebroker compartilhado (RabbitMQ) do droplet DigitalOcean para o Amazon MQ, algumas suposições comuns quebrariam o terraform apply se não fossem verificadas antes.

Causa raiz

O Amazon MQ para RabbitMQ tem regras diferentes do que se espera (e diferentes do ActiveMQ):

  • mq.t3.micro NÃO suporta cluster. Só faz SINGLE_INSTANCE. O menor tipo de instância que suporta CLUSTER_MULTI_AZ é mq.m7g.medium (Graviton, o mais barato da lista). Foi preciso consultar aws mq describe-broker-instance-options --engine-type RabbitMQ.
  • Cluster RabbitMQ usa exatamente 1 subnet. Ao contrário do ActiveMQ (que pede 2 para failover), o RabbitMQ em CLUSTER_MULTI_AZ recebe apenas um subnet_id — a AWS distribui os nós entre as AZs internamente. Passar mais de uma subnet causa erro no apply.
  • Endpoints são hostnames com TLS, não IPs. O broker expõe AMQPS na porta 5671 (não 5672 em texto puro) e a management API em HTTPS 443 (não 15672 em HTTP). Consumidores que assumiam IP privado + porta plaintext precisam ser atualizados para hostname + TLS.
  • Permissão IAM. A role de terraform precisa de mq:* e ec2:*NetworkInterface* (o broker cria ENIs nas subnets) — nada disso vinha por padrão.

Correção

O stack src/shared/messagebroker/aws usa mq.m7g.medium, engine 4.2, CLUSTER_MULTI_AZ, publicly_accessible=false, uma única subnet (slice(private_subnet_ids, 0, 1)), e um security group liberando 5671 e 443 a partir do CIDR da VPC. As permissões foram adicionadas ao TerraformPolicy no bootstrap. Os outputs entregam host AMQPS, porta 5671, flag de TLS e host de management 443.

Como evitar

  • Antes de escrever um aws_mq_broker, consulte aws mq describe-broker-instance-options e describe-broker-engine-types para o engine certo — não assuma tipos/versões.
  • Para RabbitMQ cluster, passe uma subnet, não várias.
  • Consumidores de messagebroker no Amazon MQ devem usar AMQPS (5671) + TLS e management HTTPS (443) — nunca IP + porta plaintext.
  • Recursos específicos de aplicação (vhost, user, permissões) ficam no projeto que consome, não no stack compartilhado. Veja [[reference_n8n_aws_gotchas]] e [[feedback_naming_messagebroker]].