Como aprendi AWS VPC — porque meu servidor não conseguia falar com o banco
Coloquei API no EC2 e banco no RDS. Não se falavam. Passei um dia inteiro debugando o que estava entre eles. Era a rede — e eu não sabia nada sobre rede em cloud.
EC2 com API Python. RDS com PostgreSQL. Os dois na mesma conta AWS, na mesma região.
connection refused. A API não conseguia conectar no banco.
Passei um dia debugando. Tentei mudar a connection string. Tentei reiniciar instâncias. Tentei checar se o PostgreSQL estava rodando (estava).
O problema era rede. Especificamente: Security Group.
Em cloud, redes não são abertas por default. É o inverso do físico, onde se você coloca dois servidores no mesmo rack eles podem se comunicar por default.
AWS VPC (Virtual Private Cloud) é uma rede privada isolada. Dentro da VPC, serviços não podem se comunicar a menos que você explicitamente permita.
Security Group é o firewall de cada recurso. Você define: de onde pode chegar tráfego (inbound) e para onde pode sair (outbound).
O problema:
- O RDS tinha Security Group que só aceitava tráfego na porta 5432 vindo de
0.0.0.0/0(qualquer lugar) — mas eu tinha configurado errado para127.0.0.1/32(localhost) - A API no EC2 tentava conectar na porta 5432 do RDS e levava
connection refused
A correção:
RDS Security Group — Inbound rules:
Type: PostgreSQL (5432)
Source: security-group-id-da-api-ec2 ← não IP, mas o SG da API
Em vez de liberar por IP (que muda quando você reinicia instâncias), você libera por Security Group. "Qualquer recurso que pertence a esse Security Group pode conectar aqui."
É mais seguro e mais manutenível.
O que aprendi sobre como pensar rede em cloud:
Subnets públicas vs privadas. Subnet pública tem rota para Internet Gateway — recursos lá podem ser acessados da internet. Subnet privada não tem — recursos lá só são acessíveis de dentro da VPC.
Banco de dados deve estar em subnet privada. Nunca exposto diretamente à internet. A API fica na subnet pública (ou atrás de load balancer), e a conexão da API para o banco atravessa a rede interna da VPC.
Internet → Load Balancer (subnet pública) → EC2/API (subnet pública) → RDS (subnet privada)
Tráfego de usuário nunca chega direto no banco. A rede é defesa em profundidade.
Depois disso, toda vez que tenho problema de conectividade em cloud, o checklist é:
- Os dois recursos estão na mesma VPC? (Ou têm VPC peering configurado?)
- O Security Group do destino permite tráfego na porta certa vindo da origem certa?
- Tem Network ACL bloqueando? (Mais raro, mas existe)
- Se é banco RDS: está em subnet privada acessível pela subnet onde a API roda?
A rede em cloud tem mais camadas que rede física, mas tem lógica consistente. Uma vez que você entende o modelo de "tudo bloqueado por default, você abre o que precisa", começa a fazer sentido.
Meu background de rede da Oi ajudou aqui — a lógica de firewall, roteamento e subnets é a mesma. A implementação na AWS é diferente, mas o modelo mental é familiar.