VPC Peering e Transit Gateway são os dois principais mecanismos da AWS para conectar redes VPC entre si (e, no caso do Transit Gateway, também com redes on-premises). A escolha entre eles depende essencialmente de escala: poucas VPCs se conectam bem com peering direto; dezenas ou centenas de VPCs exigem uma arquitetura centralizada.

🎯 Para a certificação

Questões sobre este tema testam se você entende por que VPC Peering não é transitivo (a pegadinha mais recorrente do assunto), sabe quando a escala de conexões torna peering inviável operacionalmente, entende a arquitetura hub-and-spoke do Transit Gateway e como route tables/propagation controlam o tráfego nele, e reconhece o risco de overlapping CIDR em qualquer uma das duas abordagens.

---

Resumo

Pense em VPC Peering como um cabo direto entre duas casas — funciona bem para conectar poucas casas vizinhas, mas se você tiver um bairro inteiro querendo se conectar dois a dois, vai acabar com um emaranhado de cabos cruzando tudo. O Transit Gateway resolve isso como uma caixa de distribuição elétrica central do bairro — cada casa puxa um único cabo até a caixa, e a caixa cuida de rotear a eletricidade (o tráfego) para onde for necessário, sem que as casas precisem se conectar diretamente umas às outras.

• VPC Peering: conexão ponto-a-ponto entre exatamente duas VPCs, sem custo de hub, mas sem roteamento transitivo — A↔B e B↔C não permitem A↔C automaticamente.
• Transit Gateway (TGW): hub central regional (e multi-região, via peering entre TGWs) que suporta roteamento transitivo nativo entre dezenas/centenas de VPCs e conexões on-premises, através de um único attachment por VPC.
• Overlapping CIDR é o problema que ameaça ambas as abordagens: se duas VPCs usam a mesma faixa de endereços IP, elas simplesmente não conseguem ser conectadas de forma funcional, seja via peering ou via TGW.

---

1. VPC Peering

1.1 Como funciona

Uma VPC Peering Connection cria uma conexão de rede direta entre exatamente duas VPCs, permitindo que instâncias em cada uma se comuniquem usando endereços IP privados, como se estivessem na mesma rede — sem passar pela internet pública, sem gateway intermediário, sem hardware físico dedicado (é implementado inteiramente na infraestrutura de rede da AWS).

Para que o tráfego realmente flua, três coisas precisam estar corretas simultaneamente:

• A peering connection precisa estar ativa (aceita por ambos os lados — inclusive entre contas diferentes).
• As route tables de cada VPC precisam ter uma rota explícita apontando o CIDR da VPC parceira através da peering connection.
• Security groups / NACLs precisam permitir o tráfego entre as faixas de IP envolvidas.

1.2 Por que não é transitivo — a pegadinha central do tema

Esse é o ponto mais cobrado do assunto inteiro. VPC Peering não propaga rotas através de múltiplos saltos. Se existe peering entre A↔B e outro peering separado entre B↔C, isso não cria automaticamente um caminho A↔C — mesmo que ambas passem "por B".

Explicação didática: pense em VPC Peering como um cabo direto entre duas casas. Se você liga a casa A à casa B, e a casa B à casa C, isso não cria automaticamente um caminho entre A e C — você precisaria puxar um cabo direto A↔C também, criando uma terceira conexão de peering independente. A rota simplesmente não existe entre A e C a menos que você a crie explicitamente.

1.3 O problema de escala: crescimento quadrático

Com N VPCs que todas precisam se comunicar entre si via peering, o número de conexões necessárias segue a fórmula combinatória N × (N-1) / 2:

Além do número de conexões em si, cada VPC também precisa manter rotas manuais para cada parceiro na sua route table — o esforço operacional de gerenciar isso cresce junto, tornando peering impraticável como estratégia central de conectividade a partir de algumas dezenas de VPCs.

💡 Para a prova: "muitas VPCs precisando de comunicação transitiva entre si" ou "crescimento previsto do número de VPCs ao longo do tempo" são sinais fortes de que a resposta é Transit Gateway, não peering — mesmo que o cenário atual tenha poucas VPCs, se o enunciado menciona escala futura, o TGW já é a resposta mais defensável.

---

2. Transit Gateway

2.1 Arquitetura hub-and-spoke

O Transit Gateway funciona como um roteador central regional: cada VPC (ou conexão VPN, ou Direct Connect) se conecta uma única vez ao TGW através de um attachment, e o TGW cuida de rotear o tráfego entre todos os attachments conectados a ele — de forma nativamente transitiva.

Explicação didática: voltando ao exemplo de escala, as mesmas 20 VPCs que precisariam de 190 conexões de peering para se comunicar todas entre si precisam de apenas 20 conexões (um attachment por VPC) com o Transit Gateway — e, uma vez conectadas, todas conseguem se comunicar entre si por padrão (sujeito às route tables do TGW), sem qualquer conexão adicional par a par.

2.2 O que pode se conectar a um Transit Gateway

• VPCs (o caso mais comum), via VPC attachment.
• Conexões VPN Site-to-Site, conectando redes on-premises.
• Direct Connect, através de um Direct Connect Gateway associado ao TGW — permitindo que uma única conexão física on-premises alcance múltiplas VPCs através do hub central.
• Outros Transit Gateways, via peering entre TGWs — inclusive entre regiões diferentes, permitindo conectividade transitiva também entre regiões (algo que VPC Peering tradicional também suporta entre regiões, mas ainda sem transitividade).

2.3 Route tables e propagation no TGW

Diferente do peering (onde cada VPC só precisa rotear diretamente para seu parceiro), o Transit Gateway tem sua própria camada de route tables, independente das route tables de cada VPC:

• Cada attachment é associado a uma route table do TGW (é possível ter múltiplas route tables no mesmo TGW, para segmentar tráfego — por exemplo, isolando um ambiente de produção de um ambiente de desenvolvimento mesmo compartilhando o mesmo hub).
• Propagation é o mecanismo que popula automaticamente as rotas de um attachment numa route table do TGW — evitando que você precise adicionar cada rota manualmente.
• Ainda assim, dentro de cada VPC individual, a route table da própria VPC precisa ter uma rota apontando para o TGW como próximo salto para os CIDRs que devem passar por ele — o TGW não substitui essa configuração local, ele centraliza o roteamento entre VPCs, não dentro de cada uma.

💡 Para a prova: se o cenário menciona "isolar tráfego entre ambientes que compartilham o mesmo Transit Gateway" (ex: produção não deve alcançar desenvolvimento, mesmo ambos conectados ao TGW), a resposta envolve usar múltiplas route tables no TGW, associando e propagando seletivamente cada attachment apenas na route table apropriada — não múltiplos Transit Gateways separados.

---

3. Overlapping CIDR — o problema que ameaça as duas abordagens

Se duas VPCs usam a mesma faixa de endereços IP (ex: ambas usando 10.0.0.0/16), elas não podem ser conectadas de forma funcional nem via peering nem via Transit Gateway — o roteador (seja a peering connection ou o TGW) não tem como distinguir para qual das duas VPCs um pacote destinado a 10.0.0.5 deveria ir, já que o mesmo endereço existiria fisicamente nas duas redes.

Esse problema é especialmente comum em ambientes multi-conta que cresceram organicamente, sem um plano de endereçamento IP centralizado desde o início — cada conta/time criou suas VPCs usando os mesmos blocos CIDR "padrão" recomendados pela documentação, sem coordenação entre times.

💡 Para a prova: se o cenário descreve "tentativa de conectar VPCs falhando" ou "tráfego não chega ao destino esperado apesar da conexão parecer configurada corretamente", overlapping CIDR é uma das causas mais cobradas — a solução real geralmente envolve replanejar o endereçamento (re-CIDR de uma das VPCs, quando possível) ou usar mecanismos de NAT específicos para contornar o conflito em casos onde replanejar não é viável.

---

4. Conectividade híbrida (on-premises)

Tanto VPC Peering quanto Transit Gateway se relacionam com o tema de conectividade híbrida, mas de formas diferentes:

• VPC Peering não se conecta diretamente a redes on-premises — ele é exclusivamente VPC-a-VPC (dentro da AWS).
• Transit Gateway é o ponto de centralização recomendado quando existem múltiplas VPCs precisando alcançar uma rede on-premises através de uma única conexão VPN ou Direct Connect — em vez de configurar uma VPN/Direct Connect separada para cada VPC individualmente, todas se conectam ao TGW, e o TGW compartilha a conectividade on-premises entre elas.

💡 Para a prova: "múltiplas VPCs precisam alcançar o data center on-premises através de uma única conexão VPN, sem duplicar a configuração de VPN por VPC" é um cenário clássico de Transit Gateway centralizando conectividade híbrida.

---

5. Custos

• VPC Peering: sem custo pela conexão em si; cobrança apenas por transferência de dados através da peering connection (com tarifas diferentes para tráfego dentro da mesma AZ, entre AZs, ou entre regiões).
• Transit Gateway: cobrança por hora por attachment conectado, além de cobrança por GB de dados processados através do TGW — geralmente mais caro que peering para um número pequeno de VPCs, mas o custo operacional evitado (menos conexões para gerenciar, rotas centralizadas) tende a compensar rapidamente conforme o número de VPCs cresce.

💡 Para a prova: se o cenário enfatiza fortemente "menor custo possível" para conectar apenas duas VPCs com comunicação direta e sem previsão de crescimento, VPC Peering ainda é a resposta mais econômica — o TGW não é automaticamente a resposta certa só porque existe; a decisão depende do número de VPCs envolvidas e da necessidade real de transitividade.

---

6. Segurança

• Tanto peering quanto TGW dependem de security groups e NACLs configurados corretamente nas instâncias/subnets de cada VPC — a conectividade de rede (rota) e a permissão de tráfego (security group/NACL) são camadas independentes, e ambas precisam estar corretas.
• No Transit Gateway, a segmentação via múltiplas route tables funciona como uma camada adicional de controle — mesmo que duas VPCs estejam conectadas ao mesmo TGW fisicamente, elas só conseguem se comunicar se suas rotas estiverem propagadas na(s) mesma(s) route table(s), o que permite isolar grupos de VPCs dentro do mesmo hub sem precisar de hubs separados.
• Referenciar security groups entre VPCs peered é possível (referenciando o security group da VPC parceira diretamente como origem/destino de uma regra), o que simplifica a governança de segurança em comparação a depender só de faixas de CIDR nas regras.

---

7. Boas práticas

• Use VPC Peering para poucos pares de VPCs com comunicação direta, baixa complexidade e sem necessidade de roteamento transitivo.
• Use Transit Gateway para topologias com dezenas/centenas de VPCs, múltiplas contas, ou necessidade de roteamento transitivo nativo — inclusive quando o crescimento futuro é esperado, mesmo que o número atual de VPCs ainda seja pequeno.
• Planeje o endereçamento CIDR centralizadamente desde o início em ambientes multi-conta, evitando overlapping que impede conectividade futura.
• Use múltiplas route tables no TGW para segmentar tráfego entre ambientes que compartilham o mesmo hub (ex: produção isolada de desenvolvimento).
• Centralize conectividade on-premises (VPN/Direct Connect) através do TGW quando múltiplas VPCs precisam alcançá-la, evitando duplicar conexões híbridas por VPC.
• Documente e audite regularmente as rotas propagadas no TGW, especialmente em ambientes multi-conta onde diferentes times podem gerenciar attachments distintos.

---

8. Como cai na certificação

• Cenário "poucas VPCs (2-3), comunicação direta, baixo custo, sem necessidade de transitividade" → VPC Peering.
• Cenário "dezenas/centenas de VPCs em múltiplas contas precisando se comunicar entre si" → Transit Gateway.
• Cenário "VPC A não consegue alcançar VPC C, mesmo existindo peering A↔B e B↔C" → VPC Peering não é transitivo; é necessário criar peering direto A↔C ou migrar para Transit Gateway.
• Cenário "conexão entre VPCs falha ou tráfego não chega ao destino, apesar de tudo parecer configurado" → verificar overlapping CIDR.
• Cenário "múltiplas VPCs precisam alcançar o data center on-premises via uma única VPN/Direct Connect, sem duplicar configuração por VPC" → Transit Gateway centralizando conectividade híbrida.
• Cenário "isolar tráfego entre ambientes que compartilham o mesmo Transit Gateway" → múltiplas route tables no TGW, com associação/propagation seletiva por attachment.
• Cenário "conectividade transitiva entre regiões diferentes" → peering entre Transit Gateways de regiões diferentes.
• Cenário "menor custo para conectar apenas duas VPCs, sem previsão de crescimento" → VPC Peering continua sendo a resposta mais econômica, mesmo com TGW disponível.

---

9. Exercícios práticos

1. Escolha entre VPC Peering e Transit Gateway para um ambiente com 50 VPCs distribuídas em 10 contas diferentes, e justifique com base no número de conexões necessárias em cada abordagem.
2. Desenhe como evitar overlapping CIDR ao planejar o endereçamento de uma organização que espera crescer para dezenas de contas AWS ao longo do tempo.
3. Explique, com um exemplo concreto de topologia, por que VPC Peering não suporta roteamento transitivo.
4. Liste os passos conceituais para conectar uma rede on-premises via VPN a múltiplas VPCs, centralizando a conectividade através de um Transit Gateway.
5. Um time relata que duas VPCs peered não conseguem se comunicar, mesmo com a peering connection ativa. Liste os três pontos de configuração que precisam ser verificados.

---

10. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Laboratório Prático

Objetivo: criar duas VPCs, conectá-las via VPC Peering, observar a falta de transitividade com uma terceira VPC, e depois resolver o cenário migrando para Transit Gateway.

Pré-requisitos: conta AWS com permissão para VPC, Transit Gateway e EC2.

Tempo estimado: 40 minutos

Possíveis custos: baixo a moderado — Transit Gateway cobra por hora de attachment; recomenda-se deletar os recursos ao final.

Passos:

1. Crie três VPCs com CIDRs não sobrepostos (ex: 10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16), cada uma com uma instância EC2 simples para teste de conectividade.
2. Crie uma VPC Peering Connection entre a VPC 1 e a VPC 2, aceite a conexão, e adicione as rotas correspondentes nas route tables de ambas.
3. Crie uma segunda VPC Peering Connection entre a VPC 2 e a VPC 3, com as rotas correspondentes.
4. Teste conectividade (ex: ping ou uma conexão TCP simples) entre a instância da VPC 1 e a instância da VPC 2 — confirme que funciona.
5. Tente o mesmo teste entre a instância da VPC 1 e a instância da VPC 3 — confirme que falha, demonstrando a falta de transitividade do VPC Peering.
6. Crie um Transit Gateway, e conecte as três VPCs a ele via attachments (mantendo ou removendo as peering connections anteriores, para efeito de comparação).
7. Configure as route tables de cada VPC para apontar para o Transit Gateway como próximo salto para os CIDRs das outras VPCs.
8. Repita o teste entre a instância da VPC 1 e a instância da VPC 3 — confirme que agora funciona, através do roteamento transitivo do Transit Gateway.

Resultado esperado: você confirma na prática a limitação de transitividade do VPC Peering e como o Transit Gateway resolve esse mesmo cenário de forma nativa.

Limpeza dos recursos: delete os attachments do Transit Gateway, o próprio Transit Gateway, as peering connections, e as VPCs/instâncias criadas para o laboratório.

---

Referências:

• VPC Peering: https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
• Transit Gateway: https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html
• Route tables e propagation no Transit Gateway: https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html
• Conectividade VPN Site-to-Site: https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html
• Referenciar Security Groups entre VPCs peered: https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html