Conectando Duas VPCs com VPC Peering: Guia Completo de Configuração e Tabelas de Rotas

Você tem duas VPCs na mesma conta e região, e os recursos precisam se comunicar usando IPs privados — sem passar pela internet pública. O VPC Peering é a solução nativa da AWS para isso, mas a armadilha clássica é criar a conexão de peering e achar que está pronto. Sem atualizar as tabelas de rotas e os security groups em ambos os lados, o tráfego simplesmente não flui.

TL;DR — Conectando Duas VPCs com VPC Peering

EtapaO que fazerOnde
1Criar a solicitação de peeringVPC-A (solicitante)
2Aceitar a solicitação de peeringVPC-B (aceitante)
3Adicionar rota na tabela de rotas da VPC-A apontando para o CIDR da VPC-BRoute table da VPC-A
4Adicionar rota na tabela de rotas da VPC-B apontando para o CIDR da VPC-ARoute table da VPC-B
5Atualizar security groups para permitir tráfego do CIDR remotoInstâncias em ambas as VPCs

Como o VPC Peering Funciona

O VPC Peering cria uma conexão de rede privada entre duas VPCs, permitindo que o tráfego roteie diretamente entre elas usando a infraestrutura da AWS — sem gateway de internet, VPN ou dispositivo físico intermediário. A conexão é estabelecida no nível da camada de rede e aparece como uma rota normal nas suas tabelas de rotas.

O ponto que mais causa confusão: o peering em si é apenas um canal. Ele não injeta rotas automaticamente. Você precisa configurar explicitamente cada tabela de rotas nas subnets relevantes de ambas as VPCs para direcionar o tráfego pelo peering. Se uma subnet não tem a rota, o tráfego originado dela não alcança a VPC remota — mesmo que o peering esteja ativo.

Pense no VPC Peering como construir uma ponte entre dois bairros. A ponte existe, mas se as ruas locais não tiverem placas apontando para ela, os carros nunca chegam até lá.
graph LR A["VPC-A 10.0.0.0/16"] -- "Peering Connection pcx-..." --> B["VPC-B 10.1.0.0/16"] A --> RT_A["Route Table VPC-A 10.1.0.0/16 → pcx-..."] B --> RT_B["Route Table VPC-B 10.0.0.0/16 → pcx-..."] RT_A -. "rota necessária" .-> B RT_B -. "rota necessária" .-> A
  1. VPC-A (10.0.0.0/16) e VPC-B (10.1.0.0/16) são redes isoladas por padrão.
  2. A Conexão de Peering cria o canal direto entre as duas VPCs.
  3. As tabelas de rotas de cada VPC precisam ser atualizadas manualmente para apontar o CIDR remoto para o peering.
  4. Os security groups nas instâncias controlam quais portas e protocolos são permitidos — o peering não os bypassa.

Pré-requisitos: Verificando CIDRs Antes de Começar

VPC Peering não funciona com CIDRs sobrepostos. Se a VPC-A usa 10.0.0.0/16 e a VPC-B também usa 10.0.0.0/16, a conexão será rejeitada. Verifique os CIDRs antes de qualquer coisa.

# Listar CIDRs das suas VPCs
aws ec2 describe-vpcs \
  --query 'Vpcs[*].{VpcId:VpcId,CidrBlock:CidrBlock,Name:Tags[?Key==`Name`].Value|[0]}' \
  --output table \
  --region us-east-1

Anote os VPC IDs e CIDRs — você vai precisar deles em todas as etapas seguintes. Nos exemplos abaixo, usaremos:

  • VPC-A: vpc-0a1b2c3d4e5f00001 — CIDR 10.0.0.0/16
  • VPC-B: vpc-0a1b2c3d4e5f00002 — CIDR 10.1.0.0/16

Etapa 1: Criar a Solicitação de VPC Peering

A solicitação é feita a partir de uma VPC (solicitante) em direção à outra (aceitante). Como ambas estão na mesma conta e região neste cenário, o processo é direto.

aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-0a1b2c3d4e5f00001 \
  --peer-vpc-id vpc-0a1b2c3d4e5f00002 \
  --region us-east-1

O comando retorna um objeto com o VpcPeeringConnectionId — algo como pcx-0123456789abcdef0. Guarde esse ID. O status inicial será pending-acceptance.

# Verificar o status da solicitação
aws ec2 describe-vpc-peering-connections \
  --filters Name=status-code,Values=pending-acceptance \
  --query 'VpcPeeringConnections[*].{Id:VpcPeeringConnectionId,Status:Status.Code,RequesterCIDR:RequesterVpcInfo.CidrBlock,AccepterCIDR:AccepterVpcInfo.CidrBlock}' \
  --output table \
  --region us-east-1

Etapa 2: Aceitar a Solicitação de Peering

Como as duas VPCs estão na mesma conta, você aceita a solicitação imediatamente. Em cenários cross-account, o owner da conta aceitante precisaria fazer isso separadamente.

aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-0123456789abcdef0 \
  --region us-east-1

Após aceitar, o status muda para active. Confirme antes de continuar — adicionar rotas para um peering que não está ativo não causa erro imediato, mas o tráfego não vai fluir.

# Confirmar que o peering está ativo
aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0123456789abcdef0 \
  --query 'VpcPeeringConnections[0].Status.Code' \
  --output text \
  --region us-east-1

O retorno esperado é active.

Etapa 3: Atualizar as Tabelas de Rotas — O Passo que Mais Esquece

Aqui está onde a maioria das pessoas trava. O peering está ativo, o ping não funciona, e a primeira suspeita é security group. Mas o problema quase sempre é rota faltando. Você precisa atualizar as tabelas de rotas em ambas as VPCs.

Identificar as Tabelas de Rotas Relevantes

Identifique quais tabelas de rotas estão associadas às subnets onde seus recursos estão. Uma VPC pode ter múltiplas tabelas de rotas — atualize apenas as que precisam alcançar a VPC remota.

# Listar tabelas de rotas da VPC-A com suas associações de subnet
aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0a1b2c3d4e5f00001 \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Subnets:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1
# Listar tabelas de rotas da VPC-B
aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0a1b2c3d4e5f00002 \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Subnets:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1

Adicionar Rota na Tabela da VPC-A (aponta para VPC-B)

Na tabela de rotas da VPC-A, adicione uma rota que direciona o CIDR da VPC-B (10.1.0.0/16) pelo peering.

aws ec2 create-route \
  --route-table-id rtb-0a1b2c3d4e5f00001 \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-0123456789abcdef0 \
  --region us-east-1

Adicionar Rota na Tabela da VPC-B (aponta para VPC-A)

O caminho de retorno também precisa ser explícito. Na tabela de rotas da VPC-B, adicione a rota para o CIDR da VPC-A (10.0.0.0/16).

aws ec2 create-route \
  --route-table-id rtb-0a1b2c3d4e5f00002 \
  --destination-cidr-block 10.0.0.0/16 \
  --vpc-peering-connection-id pcx-0123456789abcdef0 \
  --region us-east-1
sequenceDiagram participant InstA as Instância VPC-A
(10.0.0.5) participant RTA as Route Table VPC-A participant PCX as Peering Connection participant RTB as Route Table VPC-B participant InstB as Instância VPC-B
(10.1.0.5) InstA->>RTA: Destino 10.1.0.5 RTA->>PCX: Rota: 10.1.0.0/16 → pcx-... PCX->>RTB: Entrega na VPC-B RTB->>InstB: Rota local → instância InstB-->>RTA: Resposta: destino 10.0.0.5 RTA-->>InstA: Rota: 10.0.0.0/16 → pcx-...
  1. A instância na Subnet-A envia tráfego para 10.1.x.x.
  2. A Route Table da VPC-A tem a entrada 10.1.0.0/16 → pcx-... e encaminha pelo peering.
  3. O tráfego chega na VPC-B e é entregue à instância na Subnet-B.
  4. O tráfego de retorno segue o caminho inverso via a rota 10.0.0.0/16 → pcx-... na Route Table da VPC-B.

Etapa 4: Atualizar os Security Groups

Rotas corretas, mas security groups bloqueando — o resultado é o mesmo: sem comunicação. O VPC Peering não altera as regras de security group. Você precisa permitir explicitamente o tráfego originado do CIDR da VPC remota (ou do security group específico, se preferir granularidade maior).

Permitir tráfego nas instâncias da VPC-B vindo da VPC-A

# Adicionar regra de entrada no security group das instâncias na VPC-B
# Permitindo, por exemplo, tráfego TCP na porta 8080 vindo do CIDR da VPC-A
aws ec2 authorize-security-group-ingress \
  --group-id sg-0a1b2c3d4e5f00002 \
  --protocol tcp \
  --port 8080 \
  --cidr 10.0.0.0/16 \
  --region us-east-1

Permitir tráfego nas instâncias da VPC-A vindo da VPC-B (para tráfego de retorno iniciado pela VPC-B)

aws ec2 authorize-security-group-ingress \
  --group-id sg-0a1b2c3d4e5f00001 \
  --protocol tcp \
  --port 8080 \
  --cidr 10.1.0.0/16 \
  --region us-east-1

Security groups são stateful — se a conexão é iniciada da VPC-A para a VPC-B, o tráfego de retorno é permitido automaticamente sem regra de saída explícita. Mas se a VPC-B também inicia conexões, você precisa da regra de entrada na VPC-A também.

Verificando a Conectividade

Com peering ativo, rotas configuradas e security groups atualizados, valide a conectividade. A forma mais direta é um ping ICMP ou uma conexão TCP simples entre instâncias.

# A partir de uma instância na VPC-A, testar conectividade com instância na VPC-B
# (substitua pelo IP privado real da instância na VPC-B)
ping 10.1.0.5

Se o ping não responder, o diagnóstico segue esta ordem:

1. Confirmar que as rotas existem nas tabelas corretas

aws ec2 describe-route-tables \
  --route-table-ids rtb-0a1b2c3d4e5f00001 \
  --query 'RouteTables[0].Routes[?VpcPeeringConnectionId!=null]' \
  --output table \
  --region us-east-1

Se a saída estiver vazia, a rota não foi adicionada à tabela correta — ou você atualizou uma tabela que não está associada à subnet da instância.

2. Confirmar que a subnet da instância usa a tabela de rotas atualizada

# Descobrir a subnet de uma instância específica
aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[0].Instances[0].SubnetId' \
  --output text \
  --region us-east-1

# Verificar qual tabela de rotas está associada a essa subnet
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f00001 \
  --query 'RouteTables[0].RouteTableId' \
  --output text \
  --region us-east-1

Se a subnet usa a tabela de rotas principal da VPC e você adicionou a rota em uma tabela customizada (ou vice-versa), o tráfego não vai encontrar o caminho correto.

3. Verificar o status do peering novamente

aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0123456789abcdef0 \
  --query 'VpcPeeringConnections[0].{Status:Status.Code,Requester:RequesterVpcInfo.CidrBlock,Accepter:AccepterVpcInfo.CidrBlock}' \
  --output table \
  --region us-east-1

O Erro que Todo Mundo Comete na Primeira Vez

O cenário clássico: peering criado e aceito, você adiciona a rota na tabela de rotas da VPC-A, testa o ping da instância na VPC-A para a VPC-B — sem resposta. Suspeita imediata: security group bloqueando ICMP. Você abre ICMP no security group da VPC-B. Ainda sem resposta.

O problema real: a instância na VPC-A está em uma subnet privada associada a uma tabela de rotas customizada, mas você adicionou a rota na tabela de rotas principal da VPC-A. São tabelas diferentes. A rota existe, mas não está no caminho que o tráfego da instância percorre.

A correção é verificar qual tabela de rotas está efetivamente associada à subnet da instância — não assumir que é a tabela principal. Depois de adicionar a rota na tabela correta, o tráfego flui sem nenhuma mudança adicional nos security groups.

Uma VPC pode ter várias tabelas de rotas. Atualizar a tabela errada é silencioso — não gera erro, não gera alerta. O tráfego simplesmente não encontra o caminho.

IAM: Permissões Necessárias para Configurar VPC Peering

Se você está executando esses comandos com credenciais que não são de administrador, as permissões mínimas necessárias são:

🔽 Clique para expandir — Política IAM mínima para VPC Peering 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVpcPeeringConnection",
        "ec2:AcceptVpcPeeringConnection",
        "ec2:DescribeVpcPeeringConnections",
        "ec2:CreateRoute",
        "ec2:DescribeRouteTables",
        "ec2:DescribeVpcs",
        "ec2:DescribeInstances",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:DescribeSecurityGroups"
      ],
      "Resource": "*"
    }
  ]
}

As ações Describe* exigem "Resource": "*" — não é possível restringi-las por ARN de recurso específico conforme a Service Authorization Reference da AWS.

Considerações Importantes sobre VPC Peering

  • Sem transitividade: Se VPC-A faz peering com VPC-B, e VPC-B faz peering com VPC-C, a VPC-A não alcança a VPC-C automaticamente. Cada par precisa de sua própria conexão de peering. Para topologias hub-and-spoke com muitas VPCs, considere o AWS Transit Gateway.
  • CIDRs sobrepostos bloqueiam o peering: A solicitação de peering será recusada se os blocos CIDR se sobrepuserem.
  • DNS resolution entre VPCs: Por padrão, hostnames DNS privados de uma VPC não resolvem para IPs privados na VPC remota. Para habilitar isso, ative a opção enableDnsResolution na configuração do peering em ambos os lados.
# Habilitar resolução DNS para o lado solicitante
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-0123456789abcdef0 \
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --region us-east-1

# Habilitar resolução DNS para o lado aceitante
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-0123456789abcdef0 \
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --region us-east-1

Conclusão e Próximos Passos com VPC Peering

Configurar o VPC Peering se resume a três camadas: a conexão de peering em si, as rotas nas tabelas corretas de ambas as VPCs, e as regras de security group nas instâncias. Qualquer uma dessas camadas faltando resulta em falha silenciosa de conectividade.

Para ambientes com mais de quatro ou cinco VPCs que precisam se comunicar entre si, o modelo de peering individual escala mal — cada novo par exige nova conexão e novas rotas. Nesse ponto, avalie o AWS Transit Gateway, que centraliza o roteamento entre VPCs em um único hub.

Documentação de referência:

Glossário

TermoDefinição
VPC PeeringConexão de rede privada entre duas VPCs que permite roteamento direto usando IPs privados, sem internet pública.
CIDR BlockIntervalo de endereços IP associado a uma VPC ou subnet, definido em notação CIDR (ex: 10.0.0.0/16).
Route TableConjunto de regras de roteamento que determinam para onde o tráfego de uma subnet é direcionado.
Security GroupFirewall stateful no nível da instância que controla tráfego de entrada e saída por protocolo, porta e origem/destino.
Peering Connection IDIdentificador único de uma conexão de VPC Peering, no formato pcx-xxxxxxxxxxxxxxxxx.

Related Posts

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Variáveis de Ambiente no Lambda: Configuração, Acesso e Criptografia com KMS

Você tem um endpoint de banco de dados que precisa chegar até a função Lambda — hardcodar isso no código é o caminho mais rápido para um vazamento de credencial em um repositório público. Variáveis de ambiente no Lambda resolvem esse problema, e quando combinadas com KMS, você adiciona uma camada de criptografia que vai além do padrão gerenciado pela AWS. TL;DR — Variáveis de Ambiente no Lambda Ponto Detalhe Onde configurar Console, CLI ( --environment ), IaC (CloudFormation/SAM/Terraform) Criptografia padrão AWS gerencia com chave própria (aws/lambda) — transparente, sem custo adicional de KMS Criptografia customizada Você fornece uma CMK do KMS; Lambda criptografa em repouso e você descriptografa em runtime Acesso no código process.env.NOME (Node.js), os.environ['NOME'] (Python) Limite de tamanho 4 KB total para todas as variáveis — verifique a documentação oficial para limites atuais ...
Leia mais

Monitoramento de Memória RAM no EC2: Por que o CloudWatch Agent é Obrigatório

Você abre o console do CloudWatch, navega até as métricas da sua instância EC2 e percebe que CPU, rede e disco de I/O estão lá — mas RAM não aparece em lugar nenhum. Não é um bug, não é permissão faltando: o CloudWatch simplesmente não coleta métricas de memória por padrão, e entender por que isso acontece evita horas de busca no lugar errado. TL;DR — Monitoramento de Memória no EC2 Ponto Detalhe Métricas padrão do EC2 Coletadas pelo hipervisor AWS — CPU, rede, disco de I/O de bloco. Sem acesso ao SO convidado. Memória RAM e disco usado Visíveis apenas de dentro do SO. Exigem o CloudWatch Agent instalado na instância. CloudWatch Agent Processo rodando dentro do SO que publica métricas customizadas no namespace CWAgent . IAM necessário A instância precisa de uma IAM Role com a policy CloudWatchAgentServerPolicy . Custo Métricas customizadas têm custo separado das métricas padrão — verifique a tabela ...
Leia mais

S3 Access Denied: Por que 'Bloquear Acesso Público' impede seu objeto mesmo após torná-lo público

Você fez upload de uma imagem no S3, marcou o objeto como público, copiou a URL e abriu no navegador — e recebeu um 403 Access Denied . A configuração de ACL do objeto está correta, mas o acesso público continua bloqueado. O culpado quase sempre é o Block Public Access no nível do bucket, uma camada de controle que opera acima das ACLs e políticas de objeto e que muita gente ignora até levar o primeiro 403 em produção. TL;DR — S3 Access Denied com objeto público Camada O que controla O que verificar Block Public Access (bucket) Bloqueia ACLs e políticas públicas no bucket inteiro aws s3api get-public-access-block --bucket NOME ACL do objeto Permissão pública no objeto individual aws s3api get-object-acl --bucket NOME --key CHAVE Bucket Policy Permissões baseadas em política no bucket aws s3api get-bucket-policy --bucket NOME Object Ownership Controla se ACLs são respeitadas ou ignoradas aws s3api get-buc...
Leia mais