🧠FFVAcademy
🕸️

VPC em Profundidade: NAT, Peering, Transit Gateway

16 min de leitura·+85 XP

VPC é onde o SAA-C03 separa os candidatos. Não basta “saber o que é”: você precisa desenhar, escolher entre NAT Gateway e VPC Endpoint, entender quando Transit Gateway vence Peering, saber quando PrivateLink é a única opção. Este módulo é denso — relê se precisar.

Onde isso entra no exame

📘 Domain 2 — Design Resilient Architectures· 26%

Networking é transversal: aparece em Resilient (multi-AZ, DR), Secure (SG/NACL, VPC Endpoints), High-Performing (Transit Gateway, Direct Connect) e Cost (escolha entre NAT Gateway e VPC Endpoint).

Anatomia de uma VPC

🗺️ VPC padrão com subnets pública e privada em 2 AZs

           VPC  10.0.0.0/16
  ┌──────────────────────────────────────────┐
  │                                          │
  │   AZ us-east-1a         AZ us-east-1b    │
  │   ┌──────────┐          ┌──────────┐     │
  │   │ Public   │          │ Public   │ ← IGW
  │   │ Subnet   │          │ Subnet   │     │
  │   │ 10.0.1.0 │          │ 10.0.2.0 │     │
  │   │ /24      │          │ /24      │     │
  │   │          │          │          │     │
  │   │ NAT-GW ──┼──────────┤ ALB      │     │
  │   └─────┬────┘          └─────┬────┘     │
  │         │                     │          │
  │   ┌─────▼────┐          ┌─────▼────┐     │
  │   │ Private  │          │ Private  │     │
  │   │ Subnet   │          │ Subnet   │     │
  │   │ 10.0.10.0│          │ 10.0.11.0│     │
  │   │ /24      │          │ /24      │     │
  │   │ EC2 app  │          │ EC2 app  │     │
  │   └──────────┘          └──────────┘     │
  │                                          │
  │   ┌─────────────┐     ┌─────────────┐    │
  │   │ DB Subnet   │     │ DB Subnet   │    │
  │   │ 10.0.20.0/24│     │ 10.0.21.0/24│    │
  │   │  RDS primary│     │ RDS standby │    │
  │   └─────────────┘     └─────────────┘    │
  └──────────────────────────────────────────┘

Componentes essenciais:

  • CIDR block — range IPv4 privado (ex: 10.0.0.0/16 = 65k IPs)
  • Subnets — subdivisões da VPC, cada uma em UMA AZ específica
  • Route Tables — definem destino do tráfego; associadas a subnets
  • Internet Gateway (IGW) — acesso bidirecional à internet (1 por VPC)
  • NAT Gateway — acesso outbound-only à internet para subnets privadas
  • Security Groups — firewall stateful em nível de ENI
  • Network ACLs — firewall stateless em nível de subnet

Subnet pública vs privada — a diferença técnica

Não existe flag "public" em subnet. Uma subnet é pública se sua route table tem rota 0.0.0.0/0 → IGW E as instâncias têm IP público (ou Elastic IP). Privada = sem rota direta para IGW.

Tipo de subnetRoute table aponta paraUso
PúblicaIGW em 0.0.0.0/0ALB/NLB frontais, Bastion, NAT Gateway
Privada (com NAT)NAT Gateway em 0.0.0.0/0EC2 app que precisa updates/APIs
Privada isoladaSem 0.0.0.0/0 (só local VPC)RDS, ElastiCache, bastiões sensíveis

NAT Gateway vs NAT Instance

AspectoNAT Gateway (recomendado)NAT Instance (legacy)
GerenciamentoTotalmente gerenciado pela AWSVocê gerencia (EC2 + AMI)
BandwidthAté 100 Gbps automaticamenteLimitada pela instance type
HAHA dentro da AZ (deploy 1 por AZ para Multi-AZ)Manual via failover scripts
Custo$0,045/h + $0,045/GBCusto da EC2 + data transfer
Security Groups❌ Não suporta✅ Suporta
Port Forwarding
Usar como Bastion
💡
Regra prática: use NAT Gateway em 99% dos casos. NAT Instance só aparece em questões "legacy/custom" ou onde port forwarding é requerido.

Security Groups vs NACLs

AspectoSecurity GroupNetwork ACL
NívelENI (instância)Subnet
Stateful?Sim — retorno automáticoNão — precisa regra ida + volta
Allow/DenySó allow (implicit deny)Allow e Deny
Regras avaliadasTodas (union)Em ordem numérica (primeiro match ganha)
Max rules60 inbound + 60 outbound20 inbound + 20 outbound (soft limit 40)
Attach aInstâncias (até 5 SGs por ENI)1 NACL por subnet
Uso típicoControle fine-grained por app/tierBloqueio amplo (ex: IP banido)
⚠️
NACL ephemeral ports: como é stateless, resposta de uma request sai por porta ephemeral (1024-65535). Se NACL não permitir outbound nessas portas, a resposta é bloqueada — e você fica sem entender por quê.

Conectividade entre VPCs — opções

SoluçãoUsoLimitações
VPC Peering2 VPCs, 1-a-1Não-transitivo. CIDRs não podem overlap.
Transit GatewayHub-and-spoke para muitas VPCs + on-premCusto por attachment + data processing
VPC Endpoint / PrivateLinkExpor serviço de uma VPC para outras (sem peering)Unidirecional (consumer → provider)
Site-to-Site VPNVPC ↔ on-prem via IPSecPassa pela internet (encrypted)
Direct ConnectVPC ↔ on-prem via link físico dedicadoAlto custo, setup em semanas/meses
Client VPNUsuários individuais ↔ VPCOpenVPN-based, por usuário

VPC Peering — detalhes

🗺️ VPC Peering é 1-a-1, não-transitivo

   VPC-A ══peer══ VPC-B ══peer══ VPC-C
     │              │              │
     └──────── ❌ não fala ────────┘
   (A e C NÃO se conectam via B)

   Para A ↔ C: crie peering A↔C também (full mesh)
  • • Conexão lógica entre 2 VPCs (mesma conta ou cross-account)
  • • Funciona cross-region desde 2018 (Inter-Region Peering)
  • • CIDRs não podem se sobrepor
  • • Não-transitivo — cada par precisa peering próprio
  • • Atualize route tables de AMBAS as VPCs manualmente
  • • Custo: só data transfer ($0,01/GB same-AZ, $0,02/GB cross-AZ)

Transit Gateway — a solução moderna

🗺️ Transit Gateway centraliza roteamento

                    ┌────────────────┐
                    │ Transit Gateway│
                    └────┬───────────┘
         ┌───────────────┼───────────────┐
         │        │      │       │       │
      VPC-A    VPC-B  VPC-C   VPN      Direct
      (prod)  (dev)  (shared) on-prem  Connect
  • • Hub central que conecta VPCs + VPNs + Direct Connect
  • • Suporta milhares de VPCs
  • • Roteamento por TGW Route Tables (pode segregar: prod-TGW-RT não fala com dev-TGW-RT)
  • • Cross-region: TGW Peering
  • • Multicast support (único AWS service nativamente)
  • • Custo: $0,05/h por attachment + $0,02/GB processamento
💡
Quando escolher TGW vs Peering:se você tem >3 VPCs ou prevê crescimento, Transit Gateway vale a pena. Full-mesh com peering é insustentável acima de ~5 VPCs.

VPC Endpoints — dois tipos

TipoServiçosCustoComo funciona
Gateway EndpointS3 e DynamoDB (apenas)GRÁTISRota adicionada à route table para prefix-list do serviço
Interface Endpoint (PrivateLink)Todos os outros (SQS, SNS, KMS, API GW, ECS, etc.)$0,01/h + $0,01/GBENI criada na subnet com DNS privado
🗺️ Gateway Endpoint (S3)

   Private Subnet              ┌─────────────┐
   ┌────────────┐              │ S3 Service  │
   │    EC2     │─────tráfego──┤ (AWS)       │
   └────────────┘   via rota    └─────────────┘
                    para
                    Gateway
                    Endpoint
   (sem IGW, sem NAT, sem passar na internet)
Economia concreta: se sua app em subnet privada faz muito S3/DynamoDB, troque NAT Gateway por Gateway Endpoint. Elimina $0,045/GB de data transfer do NAT — pode economizar milhares/mês.

AWS PrivateLink — serviço privado seu

PrivateLink permite expor um serviço (atrás de NLB) em uma VPC para consumidores em outras VPCs/contas, via Interface Endpoint. Unidirecional: consumer chama provider, provider não enxerga consumer de volta.

🗺️ PrivateLink pattern SaaS

   VPC Consumer A         VPC Consumer B
   ┌──────────┐           ┌──────────┐
   │ EC2      │           │ EC2      │
   └────┬─────┘           └────┬─────┘
        │                      │
   [VPC Endpoint]         [VPC Endpoint]
        │                      │
        └──────► NLB ◄─────────┘
                │
          VPC Provider (SaaS)

VPN vs Direct Connect

AspectoSite-to-Site VPNDirect Connect
Meio físicoInternet (IPSec tunnel)Link físico dedicado (fibra 1/10/100 Gbps)
LatênciaVariável (depende da internet)Consistente, baixa
BandaAté ~1,25 Gbps por tunnel1/10/100 Gbps dedicada
SetupMinutosSemanas a meses
Custo$0,05/h + data transfer$$$ taxa de porta + datacenter partner
CriptografiaNativa (IPSec)NÃO criptografada por padrão (use DX + VPN)
Uso típicoSmall/medium, burst, DRThroughput sustentado, compliance
💡
Direct Connect + VPN: combo comum — DX para banda/latência, VPN por cima para criptografia. Também serve de failover (DX cai → VPN assume).

VPC Flow Logs, Reachability Analyzer, Network Access Analyzer

  • VPC Flow Logs — metadata de tráfego (src, dst, port, ACCEPT/REJECT). Entregue a CloudWatch Logs ou S3.
  • Reachability Analyzer — testa se A consegue chegar em B (considera SG, NACL, routes). Útil para debug.
  • Network Access Analyzer — audita postura: "liste todas as EC2 que podem alcançar a internet" — ótimo para compliance.

Cenários de decisão

📋 Startup com 2 VPCs (prod + analytics) que precisam se comunicar

VPC Peering

2 VPCs = peering direto, barato, simples. Transit Gateway seria overkill e custaria $0,05/h por attachment + processing.

📋 Empresa com 30 VPCs em 3 regiões, precisando conectar todas + on-prem

Transit Gateway em cada região + TGW Peering entre regiões + Direct Connect para on-prem

30 VPCs em peering seriam 435 conexões. TGW centraliza, simplifica routing via TGW Route Tables. DX para on-prem se throughput justifica.

📋 App em subnet privada faz 5TB/mês de leituras do S3

Gateway VPC Endpoint para S3

5TB via NAT Gateway = 5000 × $0,045 = $225/mês só de processamento + bandwidth. Gateway Endpoint = $0.

📋 SaaS precisa expor seu serviço a múltiplos clientes de forma privada (sem internet)

PrivateLink (VPC Endpoint Service) com NLB na frente

Cada cliente cria um Interface Endpoint na sua VPC, conecta via NLB do provedor. Sem roteamento complexo, sem CIDR overlap, isolamento total.

📋 Backup semanal de 50 TB de on-prem → S3

Direct Connect

50 TB via VPN levaria semanas. DX 10 Gbps entrega em ~11h. Se é único/infrequente, use Snowball em vez.

⚠️
Pegadinhas VPC no SAA:
  • • Subnet vive em UMA AZ (não abrange múltiplas).
  • • CIDR mínimo /28 (16 IPs) e máximo /16 (65k IPs) na VPC.
  • • AWS reserva 5 IPs por subnet (primeiro .0 network, .1 VPC router, .2 DNS, .3 futuro, .255 broadcast).
  • • NAT Gateway é por AZ — deploy 1 em cada AZ para HA real.
  • • Security Groups permitem referenciar OUTROS SGs como source/dest (pattern para micro-segmentação).
  • • VPC Peering e TGW não suportam CIDRs sobrepostos.
  • • Default VPC vem com subnets públicas em cada AZ. Production sempre cria VPC custom.

Perguntas típicas (Q&A)

Como permitir que uma EC2 em subnet privada faça download de patches do OS?

NAT Gateway em subnet pública + route 0.0.0.0/0 → NAT-GW na route table da subnet privada. A instância inicia conexão outbound; tráfego inbound é bloqueado.

Quais serviços suportam Gateway VPC Endpoint (grátis)?

Apenas S3 e DynamoDB. Todos os outros (SQS, SNS, KMS, Lambda, API Gateway, ECS, SSM, etc.) usam Interface Endpoint via PrivateLink (pago).

Minha instância privada em subnet X consegue fazer ping em outra instância privada na subnet Y mesma VPC?

Sim, por padrão rotas locais da VPC permitem tráfego entre subnets. O que decide é: SGs de ambas as instâncias permitem? NACL de ambas permitem? Regra do SG geralmente é o que bloqueia.

Como garantir que certas subnets nunca tenham internet mesmo se alguém tentar criar uma rota por acidente?

Use SCPs no Organizations negando ec2:CreateRoute para destinos que envolvam IGW. Complementar: NACLs rígidas bloqueando 0.0.0.0/0 outbound. Combinação dá defense-in-depth.
Take-aways: VPC = rede isolada com CIDR próprio. Subnets ficam em 1 AZ. Pública = rota IGW; privada = rota NAT ou isolada. SG é stateful (allow-only); NACL é stateless (allow/deny numeradas). Peering = 1-a-1 não-transitivo; Transit Gateway = hub-and-spoke para muitas. Gateway Endpoint (S3/DynamoDB) é grátis; Interface Endpoint (PrivateLink) é pago mas cobre quase tudo. VPN via internet; DX via fibra dedicada. Use Reachability Analyzer para debug de conectividade.
🧩

Quiz rápido

3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito