VPC, Sub-redes, Security Groups

A VPC (Virtual Private Cloud) é a rede privada virtual que isola logicamente os recursos de uma conta dentro do provedor de nuvem, com endereçamento IP próprio, roteamento próprio e controles de tráfego próprios. Ela é o fundamento da camada de rede em produção: todo desenho de segurança que envolve o que pode conversar com o que começa pelo desenho da VPC e de suas sub-redes. Dentro dela, security groups definem o tráfego permitido por recurso, e NACLs aplicam filtros por sub-rede, formando juntos a primeira barreira da defesa em profundidade. Errar o planejamento de rede é caro de consertar depois, porque endereçamento e segmentação permeiam conexões, peering, hybrid e observabilidade, e redimensionar uma VPC em produção é um projeto, não um ajuste. Este arquivo trata do desenho de referência de VPC de produção e das decisões que o sustentam.

Conceito: a VPC como rede isolada

Uma VPC é uma porção da rede do provedor controlada pela conta: você define o bloco CIDR, cria sub-redes dentro dele, configura tabelas de rota e decide o que tem caminho para a internet. O isolamento é lógico, mas efetivo: tráfego entre VPCs diferentes não se vê a menos que você o crie explicitamente por peering, transit gateway ou endpoint. Em uma conta bem organizada, cada ambiente, desenvolvimento, staging e produção, tem VPC própria, e produção nunca compartilha rede com os demais.

A VPC também é o plano de controle que governa o que a nuvem significa na prática: onde os recursos nascem, por onde o tráfego sai, como o on-premises se conecta e o que está exposto. Toda decisão posterior de segurança, de security group a endpoint, acontece dentro do escopo de uma VPC, e é por isso que o desenho de rede é a primeira decisão séria de qualquer arquitetura em nuvem.

CIDR blocks e planejamento de endereçamento

O bloco CIDR define o tamanho da rede e é uma decisão de longo prazo. VPCs em produção costumam usar /16 ou /20, que sobram segmentos para crescer, e sub-redes /20 a /24 por função e por zona de disponibilidade. O planejamento precisa responder três perguntas antes do primeiro recurso existir: quantos endereços a aplicação precisa com crescimento de cinco anos; quanto espaço as sub-redes reservadas do provedor consomem; e como os blocos não vão colidir com a rede corporativa nas conexões híbridas.

• Reserve folga estrutural: uma VPC /16 oferece 65.536 endereços; VPCs apertadas viram migratórias forçadas anos depois, quando peering e endpoints já gravaram o desenho.
• Espalhe blocos por padrão previsível: prefixos regionais ou por ambiente facilitam regras de firewall corporativo e rotas híbridas sem tabela manual.
• Cuidado com colisão RFC 1918: blocos como 10.0.0.0/16 são comuns na rede on-premises, e sobreposição impede conexão direta sem NAT doloroso.
• Conte as reservas: em sub-redes AWS, cinco endereços por sub-rede são reservados pelo provedor, e instâncias grandes consomem múltiplos endereços por interface.

Endereçamento mal planejado é a falha de rede mais difícil de corrigir, porque tudo que veio depois depende dele. Documente a tabela de blocos como código, junto da VPC, para que a decisão tenha dono e histórico. Uma convenção simples e estável, como um dígito de ambiente, um de camada e um de zona no prefixo, evita conflito acidental entre contas e simplifica qualquer auditoria futura.

Sub-redes públicas e privadas por zona de disponibilidade

O termo público ou privado não descreve propriedade da sub-rede, e sim presença de rota para a internet. Sub-rede pública tem rota padrão apontando para um Internet Gateway, e é o lugar do que precisa receber tráfego externo: balanceadores, proxies e bastiões. Sub-rede privada não tem esse caminho, e é o lugar de tudo que processa ou guarda dado: aplicação, banco, cache e fila. A regra de produção é simples e rígida: nada que guarda dado vive em sub-rede pública.

A distribuição por zona de disponibilidade é a outra metade do desenho: cada camada se replica em no mínimo duas AZs, o que mantém o serviço de pé quando uma zona falha. O desenho de referência com três AZs e duas camadas gera seis sub-redes aplicativas, além das sub-redes públicas para os balanceadores.

Security Groups versus NACLs

Security groups e NACLs formam duas barreiras com semântica diferente, e confundi-las produz tanto excesso quanto buracos:

• Security group é stateful e opera por recurso: a resposta de um tráfego permitido retorna automaticamente, e regras referenciam outros security groups em vez de IPs, o que torna o desenho legível e imune a mudança de endereço.
• NACL é stateless e opera por sub-rede: cada direção precisa de regra explícita, inclusive a resposta, e a ordem numérica das regras define a avaliação, com a primeira que casa vencendo.
• Security group nega por omissão: sem regra de ingress, nada entra; por isso o desenho padrão é começar fechado e abrir a porta exata por origem exata.
• NACL permite e nega explicitamente: é o instrumento para blocar um IP conhecido malicioso em toda a sub-rede, algo que o security group não faz por endereço.
• A combinação correta é NACL como filtro de borda de sub-rede, grosseiro, e security group como política fina por recurso, específica.

Em produção, o erro clássico é o security group com ingress 0.0.0.0/0 em porta administrativa, que anula toda a segmentação feita antes. O correto é origem por security group referenciado: o ALB alcança a aplicação, a aplicação alcança o banco, e nada mais.

A prática que mantém a dupla auditável é a origem por referência: regras de ingress que citam security groups em vez de blocos CIDR sobrevivem ao escalonamento sem revisão manual, porque a identidade da origem não muda quando instâncias nascem e morrem. O grupo padrão de cada VPC, que costuma permitir tráfego livre entre recursos que o compartilham, merece atenção redobrada: reaproveitá-lo em produção acopla a política de rede de todos os recursos que o usam, o que é o oposto de segmentação.

Roteamento e Internet Gateway

O roteamento dentro da VPC é governado por tabelas de rota associadas a sub-redes. A tabela padrão tem rota local para o CIDR da VPC, que é o que permite o tráfego interno entre sub-redes; toda rota além dela precisa ser declarada: 0.0.0.0/0 para o Internet Gateway nas sub-redes públicas, para o NAT Gateway nas privadas, e rotas específicas para endpoints, peering e conexões híbridas. O Internet Gateway é o componente que, associado à VPC, dá à sub-rede pública seu caminho bidirecional com a internet.

Rotas são o ponto onde segmentação quebra silenciosamente: uma rota 0.0.0.0/0 extra, ou um peering mal recortado, conecta ambientes que o desenho declarava isolados. Revisão de rota pertence à mesma disciplina de revisão de política IAM, porque a tabela de rota é a política de alcance da rede. Rotas propagadas automaticamente por gateway VPN ou Transit Gateway merecem a mesma revisão das rotas estáticas, já que a propagação também pode alcançar redes que o desenho separava.

Desenho de referência de produção

# Terraform: VPC de produção com 3 AZs, camada pública e camada privada
resource "aws_vpc" "prod" {
  cidr_block           = "10.40.0.0/16"     # folga para crescer anos
  enable_dns_support   = true
  enable_dns_hostnames = true
}

resource "aws_subnet" "publica" {
  count                   = 3               # uma por zona de disponibilidade
  vpc_id                  = aws_vpc.prod.id
  cidr_block              = cidrsubnet(aws_vpc.prod.cidr_block, 8, count.index)
  availability_zone       = data.aws_availability_zones.disp.names[count.index]
  map_public_ip_on_launch = false           # IP público por necessidade, não por padrão
}

resource "aws_subnet" "privada_app" {
  count             = 3
  vpc_id            = aws_vpc.prod.id
  cidr_block        = cidrsubnet(aws_vpc.prod.cidr_block, 8, count.index + 10)
  availability_zone = data.aws_availability_zones.disp.names[count.index]
}

resource "aws_security_group" "app" {
  name   = "app-producao"
  vpc_id = aws_vpc.prod.id
  # Ingress somente do ALB; egress somente HTTPS para o SG do banco
  ingress {
    from_port       = 8443
    to_port         = 8443
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }
  egress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.banco.id]
  }
}

Zona a                    Zona b                    Zona c
+--------------------+    +--------------------+    +--------------------+
| publica-a   ALB    |    | publica-b   ALB    |    | publica-c   ALB    |
| privada-a   app    |    | privada-b   app    |    | privada-c   app    |
| dados-a     banco  |    | dados-b     banco  |    | dados-c     banco  |
+--------------------+    +--------------------+    +--------------------+
        |                         |                         |
        +---------------- rota local (10.40.0.0/16) --------+

O desenho separa três camadas, publica, aplicação e dados, cada uma em três zonas, com security groups encadeados por referência. A camada de dados não tem rota para a internet e só aceita tráfego do security group da aplicação, o que fecha a cadeia de responsabilidade na rede.

Erros comuns

• Uma VPC gigante compartilhada por todos os ambientes: produção convive com experimentos, e um incidente de rede derruba tudo; VPC por ambiente é o mínimo de isolamento.
• CIDR /24 esgotado no primeiro ano: sub-rede sem endereço para escalar é o sintoma; dimensione por crescimento projetado, e não pela carga de hoje.
• Recursos com IP público por padrão: qualquer instância de banco ou fila com endereço público anula a segmentação; desligue map_public_ip_on_launch em toda sub-rede.
• Security group de administrador aberto em 0.0.0.0/0: a porta 22 ou 3389 exposta para o mundo é achado imediato em qualquer varredura; acesso administrativo via SSM ou bastion.
• Depender só de NACL: stateless e por ordem numérica, a NACL dá falsa sensação quando usada como única barreira; a política fina é o security group.
• Reaproveitar o security group padrão: política de rede acoplada entre recursos sem relação nenhuma; crie grupo por função e deixe o padrão vazio de ingress.
• NACL com bloqueio amplo esquecido: a regra de deny ampla que aparece como segurança no diagrama e é liberada no primeiro erro de conexão; ordem numérica precisa de revisão.
• Rotas e peering sem revisão: conexão adicionada para resolver um problema pontual permanece para sempre, ligando redes que deveriam estar separadas.
• Migrar de sub-rede sem limpar o caminho antigo: recursos recriados em nova sub-rede deixam regras, NACLs e rotas órfãs que ninguém ousa remover depois.

Boas práticas em produção

Declare a VPC inteira em IaC, do CIDR às tabelas de rota, com convenção de nomenclatura que permita entender a função de cada sub-rede pelo nome, e audite divergência com o mesmo rigor de IAM. Referencie security groups por identidade de grupo em vez de CIDR, o que mantém o desenho correto quando instâncias escalam e endereços mudam.

Adote o desenho de três zonas como padrão de produção e reduza o número de zonas apenas quando a carga justificar, documentando a decisão. Use ferramentas de análise de rede, como Reachability Analyzer, para provar que o caminho esperado existe e que caminhos proibidos não existem, transformando o desenho de rede em teste verificável. Por fim, mantenha a camada pública mínima: quanto menos recursos precisarem de entrada direta da internet, menor a superfície que os próximos controles do módulo precisam defender.