Amazon SAP-C02: Redes e Conectividade Híbrida — Guia de estudos

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Faz parte do AWS Solutions Architect Professional SAP-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Padrões de arquitetura e segmentação de VPC

O design da topologia de VPC começa com o gerenciamento do raio de impacto (blast radius) e roteamento previsível. Para implantações pequenas, uma única VPC com múltiplas subnets e security groups rigorosos pode ser eficiente, mas à medida que as equipes e aplicações crescem, o padrão de VPC única se torna frágil: cotas de recursos, governança entre equipes e o efeito de “vizinhos barulhentos” (noisy neighbors) aumentam o risco operacional. O modelo de múltiplas VPCs por equipe ou de uma conta por equipe melhora o isolamento e as fronteiras do IAM; use o AWS Organizations com contas separadas para as equipes e uma conta de serviços compartilhados para DNS, logs e identidade. Para conectividade entre VPCs, o VPC peering é simples e de baixa latência, mas não é transitivo e se torna operacionalmente pesado em escala. O Transit Gateway (TGW) substitui o padrão de “VPC de trânsito”: ele suporta milhares de anexos (attachments), centraliza as tabelas de rotas e simplifica padrões multicast ou hub-and-spoke. O PrivateLink (Interface VPC Endpoints) permite o isolamento no nível do serviço sem expor os serviços à internet, o que é crítico para microsserviços entre contas (cross-account). Armadilhas comuns incluem depender apenas de security groups para segmentação (eles são stateful e grosseiros para filtragem leste-oeste), esquecer o comportamento stateless das NACLs e não planejar a alocação de CIDR (sobreposições dificultam o peering e o DX). As decisões dependem do custo versus a capacidade de gerenciamento: o TGW tem custos por anexo, mas reduz a complexidade por peering; o isolamento de múltiplas contas aumenta a sobrecarga da landing zone, mas diminui o raio de impacto. Sempre documente o plano de CIDR, as regras de propagação de rotas e a propriedade dos serviços compartilhados para evitar desvios (drift).

Conectividade híbrida, roteamento e resiliência

As escolhas de conectividade híbrida dependem de throughput, jitter, latência e endereçamento de egresso público consistente. VIFs privadas do AWS Direct Connect (DX) fornecem largura de banda determinística e custos de egresso mais baixos em comparação com VPNs pela internet para fluxos grandes e constantes; use um Direct Connect Gateway para abranger múltiplas Regiões ou anexe a um Transit Gateway para roteamento centralizado. A Site-to-Site VPN (IPsec gerenciado com BGP) é usada para configuração rápida ou como um backup resiliente para o DX; configure o BGP com os ASNs apropriados e prioridades de rota para evitar roteamento assimétrico. As principais armadilhas de roteamento são a sobreposição de CIDRs on-premises e na nuvem, a propagação inadequada de rotas no TGW e presumir que o roteamento é transitivo entre VPCs em peering. MTU e fragmentação podem interromper o tráfego da VPN — teste o path MTU e ajuste o MSS nos dispositivos. Para múltiplas regiões, considere DX ativo/ativo em múltiplos locais ou DX combinado com failover para VPN. Trade-offs: links de DX dedicados custam mais, mas reduzem o jitter e os custos de egresso; a VPN é mais barata e simples, mas menos estável em alto throughput. Arquitete para um failover previsível com dois túneis independentes, conexões de DX redundantes em locais separados e tabelas de rotas explícitas no TGW para controlar a seleção e os limites do caminho.

DNS, PrivateLink e padrões de conectividade de serviços

O DNS é central para redes híbridas e multi-contas. Use Private Hosted Zones do Route 53 para resolução no escopo da VPC e endpoints inbound/outbound do Route 53 Resolver para habilitar o encaminhamento condicional entre o DNS on-premises e o da AWS. Isso suporta DNS split-horizon, onde nomes internos resolvem para IPs privados enquanto os registros públicos permanecem globais. O PrivateLink (interface endpoints) fornece conectividade privada, baseada em ENIs, para serviços da AWS ou parceiros SaaS sem rotear o tráfego pela internet pública; compare isso com os Gateway Endpoints para S3 e DynamoDB, que são mais baratos e usam tabelas de rotas em vez de ENIs. O PrivateLink evita expor serviços a conflitos de CIDR da VPC e suporta consumidores em outras contas (cross-account) com políticas de aceitação de serviço. Erros comuns incluem esquecer de associar as private hosted zones a todas as VPCs consumidoras, não criar regras no Route 53 Resolver para domínios on-premises e subestimar o consumo de IPs por ENI de cada endpoint. Critérios de decisão: prefira Gateway endpoints para acesso de alto throughput ao S3/DynamoDB para evitar custos de NAT; use Interface endpoints quando precisar de acesso privado a endpoints de API ou serviços de terceiros com segurança mais rigorosa. Monitore a latência do DNS e defina os TTLs com controle de alterações para gerenciar o comportamento de failover.

Egresso, design de NAT, controles de segurança e práticas operacionais

A arquitetura de egresso afeta o custo, a auditabilidade e as integrações com terceiros. O NAT Gateway fornece egresso IPv4 gerenciado e de alta disponibilidade para sub-redes privadas com escalonamento automático por AZ; as NAT Instances são mais baratas para uso de baixa vazão, mas exigem manutenção operacional e scripts de failover. Centralizar o egresso por meio de uma VPC de egresso dedicada, conectada a um Transit Gateway, impõe IPs de saída consistentes, pontos de inspeção e políticas simplificadas, mas introduz roteamento em hairpin e possíveis gargalos de largura de banda. Para IPv6, use um Egress-Only Internet Gateway. Substitua os bastions SSH pelo AWS Systems Manager Session Manager para auditoria e para eliminar credenciais de entrada públicas; o Session Manager funciona por meio do agente SSM sem abrir portas SSH. Para filtragem avançada e DPI, implante o AWS Network Firewall ou appliances de terceiros atrás do TGW. Compromissos de custo vs. performance: os NAT Gateways são fáceis, mas adicionam cobranças por GB — use VPC endpoints para reduzir os custos de egresso do S3 e de NAT. As armadilhas operacionais incluem não habilitar os VPC Flow Logs para solucionar problemas de tráfego, deixar regras de egresso muito amplas que permitem a exfiltração de dados e usar SCPs ou políticas do IAM que bloqueiam operações de ciclo de vida involuntariamente; aplique o princípio do menor privilégio e registre tudo em uma conta central para análise.

Problema Prático: Acme Financial Services — Egresso Centralizado e Previsível para Whitelisting de Terceiros

Cenário: A Acme Financial Services executa múltiplas VPCs de aplicação em duas AWS Regions, conectadas com um Transit Gateway e com data centers on-premises via Direct Connect e VPN. Várias aplicações em contas separadas precisam chamar uma API de parceiro que aceita requisições apenas de um único bloco CIDR público.

Desafio: Fornecer um caminho de egresso de alta disponibilidade e auditável com um único bloco CIDR público previsível para todas as VPCs de aplicação entre as Regions, minimizando a latência e a sobrecarga operacional.

Abordagem Recomendada:

Traga um CIDR IPv4 público para a AWS usando o BYOIP (Bring Your Own IP) e aloque Elastic IPs desse CIDR para serem usados como os endereços de egresso.
Construa uma VPC de egresso centralizada em cada Region com NAT Gateways em múltiplas AZs; associe os Elastic IPs do BYOIP a esses NAT Gateways e anexe as VPCs de egresso ao Transit Gateway.
Atualize as tabelas de rotas do TGW para que todas as VPCs de aplicação roteiem 0.0.0.0/0 para o anexo da VPC de egresso, habilite a propagação de rotas e o failover com verificação de saúde entre as AZs; configure o roteamento on-prem para preferir o egresso local quando necessário.
Implante o Network Firewall ou um IDS gerenciado na VPC de egresso para filtragem de saída, habilite os VPC Flow Logs e alarmes do CloudWatch, e use o Route 53 Resolver para quaisquer necessidades de encaminhamento de DNS.

Justificativa: Centralizar o egresso via TGW e NAT Gateways com o espaço de IP fornecido pelo BYOIP oferece um CIDR previsível para whitelisting, ao mesmo tempo que preserva a alta disponibilidade e o monitoramento centralizado. Isso equilibra a simplicidade operacional, os controles de segurança e o requisito do parceiro de um único CIDR público.

← Complexidade Organizacional e Estratégia de Múltiplas Contas · Todos os domínios · Segurança →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →