Joao Brietzke Blog

← voltar

Subnets na VPC: como dividir um /16

18 de ago. de 2026 — #aws #infraestrutura #redes

Toda VPC nasce de um número: o bloco CIDR. Ele parece só um detalhe de formulário na hora de criar a VPC, mas é ele que decide, de uma vez, quantas subnets você consegue criar, quantas instâncias cabem em cada uma e se essa VPC vai conseguir conversar com outra rede no futuro sem dar conflito de rota. Errar essa conta no dia 1 é o tipo de coisa que só aparece de novo seis meses depois, quando não sobra mais IP livre pra uma subnet nova.

O que o número depois da barra realmente significa

Um endereço IPv4 tem 32 bits, escritos como 4 blocos de 8 bits (os octetos): 10.0.0.0 é 00001010.00000000.00000000.00000000. A notação CIDR (10.0.0.0/16) diz quantos desses 32 bits são fixos, a parte de rede, e quantos ficam livres para variar, a parte de host.

  • /16 → 16 bits fixos, 16 livres → 2^16 = 65.536 endereços
  • /24 → 24 bits fixos, 8 livres → 2^8 = 256 endereços

O detalhe que costuma confundir: quanto menor o número depois da barra, maior o bloco. Menos bits fixos significa mais combinações possíveis nos bits livres.

CIDR Bits livres Total de IPs Uso comum
/16 16 65.536 VPC inteira
/20 12 4.096 Subnet grande (EKS, muitas ENIs)
/24 8 256 Subnet típica
/28 4 16 Subnet pequena e fixa (NAT, firewall)
/32 0 1 Um único host

De um /16 a várias /24: a conta do terceiro octeto

Uma VPC 10.0.0.0/16 cobre todo o intervalo de 10.0.0.0 até 10.0.255.255. Se você fatia isso em subnets /24, cada subnet consome um valor inteiro do terceiro octeto:

  • 10.0.0.0/24 → 10.0.0.0 até 10.0.0.255
  • 10.0.1.0/24 → 10.0.1.0 até 10.0.1.255
  • 10.0.2.0/24 → 10.0.2.0 até 10.0.2.255
  • ...até 10.0.255.0/24

Ou seja: uma VPC /16 comporta até 256 subnets /24. Você não precisa usar todas de uma vez, e não deveria, deixar números pulados entre grupos de subnets é o que sobra de espaço pra crescer sem precisar redesenhar a VPC inteira depois.

Nem todo IP da subnet é utilizável

Numa subnet /24 com 256 endereços, a AWS reserva 5 para uso interno, sobrando 251 utilizáveis:

Endereço (exemplo em 10.0.1.0/24) Reservado para
10.0.1.0 Endereço de rede
10.0.1.1 Roteador da VPC
10.0.1.2 DNS
10.0.1.3 Uso futuro da AWS
10.0.1.255 Broadcast (não usado, mas reservado)

Essa reserva é fixa em 5 endereços por subnet, não importa o tamanho dela. Numa /28 (16 endereços), sobram só 11 utilizáveis, o que faz subnets muito pequenas ficarem apertadas rápido se você não planejar o uso.

O que faz uma subnet ser pública ou privada

O CIDR não define isso, a tabela de rotas define. A mesma subnet /24 pode ser pública ou privada dependendo só de para onde ela manda o tráfego 0.0.0.0/0:

  • Pública: rota 0.0.0.0/0 → Internet Gateway. Instâncias aqui podem ter IP público e alcançar a internet direto.
  • Privada: rota 0.0.0.0/0 → NAT Gateway. Saída para internet sim, entrada direta não.
  • Isolada: sem rota 0.0.0.0/0 nenhuma. Nem entra, nem sai.

Duas subnets podem ter CIDRs vizinhos (10.0.0.0/24 e 10.0.1.0/24) e terem comportamentos completamente diferentes na internet. O range de IP não carrega essa informação sozinho.

Desenhando uma VPC real: 3 AZs, público e privado

Um layout de referência, replicando o padrão que a própria AWS usa nos templates de VPC:

Subnet CIDR AZ Camada IPs utilizáveis
public-a 10.0.0.0/24 us-east-1a Pública 251
private-a 10.0.1.0/24 us-east-1a Privada 251
public-b 10.0.2.0/24 us-east-1b Pública 251
private-b 10.0.3.0/24 us-east-1b Privada 251
public-c 10.0.4.0/24 us-east-1c Pública 251
private-c 10.0.5.0/24 us-east-1c Privada 251

Isso usa só 6 dos 256 blocos /24 disponíveis no /16. O resto fica livre para uma camada de banco de dados isolada, uma quarta AZ, ou uma subnet dedicada a EKS. Um convenção comum é agrupar por faixa: 10.0.0.0 a 10.0.9.0 para público/privado, 10.0.10.0 em diante para dados isolados, deixando o layout legível sem precisar de documentação externa pra lembrar o que é o quê.

Cada AZ costuma ter seu próprio NAT Gateway, e não um único compartilhado entre todas. Isso evita ponto único de falha e evita tráfego cruzando AZ (que tem custo por GB) só para sair para a internet.

Como criar isso via CLI

aws ec2 create-vpc --cidr-block 10.0.0.0/16

aws ec2 create-subnet \
  --vpc-id vpc-0123456789abcdef0 \
  --cidr-block 10.0.0.0/24 \
  --availability-zone us-east-1a

aws ec2 create-subnet \
  --vpc-id vpc-0123456789abcdef0 \
  --cidr-block 10.0.1.0/24 \
  --availability-zone us-east-1a

A tabela de rotas é o passo que transforma essas subnets em públicas ou privadas de fato:

aws ec2 create-route \
  --route-table-id rtb-public0123456789 \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-0123456789abcdef0

aws ec2 create-route \
  --route-table-id rtb-private0123456789 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0123456789abcdef0

No console, o mesmo fluxo fica em VPC > Subnets para criar, e VPC > Route Tables > Edit routes para associar cada subnet ao seu comportamento público ou privado.

Quando ir além do /24

Algumas cargas consomem IP privado muito mais rápido do que parece:

  • EKS com VPC CNI: cada pod recebe um IP da subnet, não só cada nó. Um cluster com autoscaling agressivo pode esgotar uma /24 em pouco tempo.
  • Lambda dentro da VPC: cada execução concorrente também consome ENI/IP da subnet configurada.
  • Frotas grandes de Auto Scaling: picos de escala momentâneos podem passar de 251 instâncias numa subnet só.

Nesses casos, subir para /20 (4.091 utilizáveis) ou /22 (1.019 utilizáveis) na subnet específica resolve, sem precisar mexer no tamanho da VPC. Se mesmo assim o /16 original não for suficiente, a AWS permite associar um CIDR secundário à VPC depois de criada, desde que ele não sobreponha o bloco principal nem o de nenhuma rede já conectada por peering ou VPN.

Por que sobreposição de CIDR quebra tudo

Peering, Transit Gateway e VPN roteiam tráfego comparando blocos CIDR. Se duas VPCs usam o mesmo range, ou ranges que se sobrepõem parcialmente, não existe rota inequívoca possível, o pacote não tem como saber pra qual das duas redes ele deveria ir. Por isso vale planejar o espaço de IP privado antes de multiplicar VPCs pela conta: reservar faixas diferentes do 10.0.0.0/8 (ou 172.16.0.0/12, ou 192.168.0.0/16) para cada VPC, do mesmo jeito que se reserva faixas de subnet dentro de uma VPC só.

Como isso se conecta com o resto

O tipo de IP que cada instância recebe dentro dessas subnets, privado, público automático ou Elastic IP, é uma decisão separada da divisão de CIDR, coberta em IP privado, público e Elastic IP: quem é o dono do endereço. A VPC e suas subnets, por sua vez, vivem dentro de uma região e se espalham por zonas de disponibilidade, cuja estrutura está em Como funciona a estrutura da AWS.

Referências