Amazon SAA-C03: Redes e Conectividade — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Projeto de VPC e Planejamento de CIDR

Toda VPC começa com um bloco CIDR, e a escolha feita no momento da criação tem consequências posteriores para peering, anexos do Transit Gateway e conectividade híbrida. O CIDR primário deve estar entre /16 e /28, escolhido do espaço RFC 1918, e não deve se sobrepor a nenhuma rede com a qual você pretenda fazer peering, rotear através de um Transit Gateway ou alcançar via Direct Connect ou VPN. CIDRs sobrepostos são a causa mais comum de falhas em projetos híbridos, pois a AWS não consegue rotear entre duas redes que compartilham o mesmo espaço de endereçamento — o Transit Gateway aceitará o anexo, mas a propagação falhará ou descartará o tráfego silenciosamente.

Quando uma VPC fica sem espaço de endereçamento, não é necessário reconstruí-la. Até quatro blocos CIDR IPv4 secundários podem ser anexados (e faixas adicionais de um pool mais amplo para um total padrão de cinco, extensível via aumento de cota). Blocos secundários podem vir da mesma faixa RFC 1918 ou do espaço de endereço compartilhado 100.64.0.0/10, o que é útil quando o 10.0.0.0/8 foi esgotado ou quando o espaço para NAT de nível de operadora (carrier-grade) é necessário. CIDRs secundários permitem que você crie novas subnets para expansão — como para a rede de pods do EKS ou uma nova camada (tier) — sem precisar renumerar as cargas de trabalho existentes.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

Um projeto robusto reserva um /17 ou /18 para crescimento futuro, alinha os limites das subnets com as Zonas de Disponibilidade (um padrão comum é um /20 por AZ por camada), e deixa uma folga para as ENIs consumidas por interface endpoints, NAT gateways e load balancers.

Uma VPC é um recurso regional particionado em subnets, cada uma vinculada a uma única AZ. A distinção entre “pública” e “privada” é puramente uma decisão de roteamento: uma subnet pública tem uma rota 0.0.0.0/0 → igw-xxxx apontando para um Internet Gateway, enquanto uma subnet privada ou não tem rota padrão ou aponta 0.0.0.0/0 para um dispositivo NAT. Instâncias em uma subnet pública também precisam de um IP público ou Elastic IP para serem acessíveis de fora (inbound); o IGW realiza um NAT 1:1 entre o IP privado e o público.

NAT Gateways, NAT Instances e Egress IPv6

Para acesso à internet somente de saída (outbound-only) em IPv4 a partir de subnets privadas, os NAT gateways são o primitivo correto. Um NAT gateway gerenciado escala automaticamente para 45–100 Gbps, suporta 55.000 conexões simultâneas por destino único, recebe patches da AWS e é altamente disponível dentro de sua AZ. Os NAT gateways são cobrados por hora e por GB processado.

As NAT instances — instâncias EC2 autogerenciadas com a verificação de origem/destino (source/destination check) desabilitada — são legadas. Elas são limitadas pela vazão (throughput) de uma única instância, precisam de scripts para failover e se tornam um gargalo sob carga sustentada. Elas são apropriadas apenas para necessidades atípicas, como filtragem personalizada, e mesmo nesses casos, um appliance com Gateway Load Balancer geralmente é preferível.

O padrão canônico de alta disponibilidade é um NAT gateway por AZ, cada um na subnet pública daquela AZ, com uma tabela de rotas privada distinta por AZ cuja rota padrão aponta para o NAT gateway local:

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

Implantar um único NAT gateway compartilhado entre AZs é uma armadilha por duas razões. Primeiro, é um ponto único de falha: uma interrupção na AZ derruba o acesso de saída (egress) de todas as subnets privadas. Segundo, cada pacote de instâncias em outras AZs cruza uma fronteira de AZ, incorrendo em cobranças de transferência de dados entre AZs (atualmente $0.01/GB por trecho), além do processamento do NAT gateway. Em cargas de trabalho que geram centenas de TB de tráfego de saída, esse custo supera em muito o custo dos NAT gateways extras. Uma segunda configuração incorreta frequente é colocar o próprio NAT gateway em uma subnet privada — ele então não tem caminho para o IGW e não funciona.

Para IPv6, o NAT não é necessário nem está disponível, pois todo endereço IPv6 é roteável globalmente. Para permitir tráfego IPv6 apenas de saída (outbound-only) e bloquear conexões de entrada não solicitadas, anexe um egress-only internet gateway e roteie ::/0 para ele a partir das subnets privadas. Um IGW regular é bidirecional e exporia as instâncias.

VPC Endpoints: Gateway vs. Interface

VPC endpoints mantêm o tráfego entre sua VPC e os serviços da AWS no backbone da AWS, evitando completamente a internet, NAT gateways e internet gateways. Existem duas implementações fundamentalmente diferentes, e confundi-las é um dos erros de arquitetura mais comuns.

Gateway endpoints existem apenas para o Amazon S3 e o DynamoDB. Eles são uma entrada na tabela de rotas — uma lista de prefixos (prefix list), por exemplo pl-63a5400a para o S3 em us-east-1, que aponta para o próprio endpoint. Não há ENI, nem alteração de DNS, nem custo por hora, e nem security group (o acesso é controlado pela tabela de rotas mais a política do endpoint). Como são baseados em rotas, eles só funcionam para recursos dentro da VPC — redes on-premises que acessam o S3 via Direct Connect não podem usá-los.

Interface endpoints (AWS PrivateLink) são ENIs com IPs privados alocados em suas subnets, cobrados por hora por AZ mais por GB. Eles funcionam para quase todos os outros serviços — SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS e centenas de outros — bem como para serviços de terceiros publicados como endpoint services. Interface endpoints suportam DNS privado (private DNS), que sobrescreve o hostname público do serviço para resolver para o IP privado do endpoint, para que os SDKs e CLIs não precisem de alterações no código. Como são baseados em ENIs, os security groups se aplicam.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

A lógica de custos é importante: qualquer tráfego saindo de uma subnet privada para um serviço público da AWS por padrão atravessa um NAT gateway a um custo de aproximadamente $0,045/GB. Para uma carga de trabalho em contêineres enviando 1 TB por dia para o S3, a diferença entre um caminho via NAT gateway e um gateway endpoint é de milhares de dólares por mês. Interface endpoints valem a pena quando substituem a saída via NAT em grande escala ou quando a conformidade proíbe o roteamento pela internet.

Armadilhas: anexar um security group a um gateway endpoint (eles não têm ENI); assumir que um gateway endpoint é acessível de on-premises (não é — use um interface endpoint ou o padrão híbrido EC2 → gateway endpoint do S3 → caminho separado via DX); desabilitar o DNS privado em um interface endpoint e esperar que chamadas de SDK não modificadas funcionem (elas atingirão o endpoint público pela internet, anulando completamente o propósito do endpoint); criar um gateway endpoint mas esquecer de associar a tabela de rotas da subnet privada (o tráfego continua silenciosamente a usar o caminho público); tentar usar um gateway endpoint para um serviço que não possui um (KMS, por exemplo) — apenas S3 e DynamoDB se qualificam.

Conectividade entre VPCs: Peering vs. Transit Gateway

O VPC peering é uma conexão de Camada 3 (Layer 3) um-para-um e não transitiva entre duas VPCs, na mesma conta ou em contas diferentes, na mesma Região ou em Regiões diferentes. O tráfego atravessa o backbone da AWS, não há gargalo de largura de banda e não há cobrança por hora — você paga apenas pela transferência de dados entre AZs ou entre Regiões. Duas propriedades limitam o peering: (1) ele é não transitivo — se A faz peering com B e B faz peering com C, A não pode alcançar C através de B; e (2) os intervalos CIDR não devem se sobrepor. Conectar N VPCs em malha completa (full-mesh) requer N(N-1)/2 peerings com edições na tabela de rotas em ambas as direções de cada um; com 30 VPCs, isso significa 435 peerings. Esperar que o peering escale para centenas de VPCs é uma armadilha.

O Transit Gateway (TGW) é um roteador de nuvem regional. Cada VPC, VPN ou Direct Connect gateway é um attachment, e as tabelas de rotas do TGW controlam qual attachment pode alcançar qual prefixo. Isso converte uma malha O(n²) em O(n) attachments e possibilita topologias hub-and-spoke, onde uma VPC de segurança hospeda firewalls que inspecionam todo o tráfego entre VPCs. O TGW suporta roteamento transitivo, termina nativamente associações de VPN e Direct Connect gateway, e pode ser compartilhado entre contas da AWS Organizations via Resource Access Manager, para que equipes de rede centralizadas controlem o roteamento enquanto as contas das cargas de trabalho são donas das VPCs. O TGW adiciona uma taxa por hora por attachment e aproximadamente $0,02/GB processado.

Para conectividade entre Regiões, o TGW peering conecta TGWs em diferentes Regiões sobre o backbone global da AWS com tráfego criptografado — um TGW por Região, com peering em um design de malha ou hub. Isso evita o problema N-quadrado entre Regiões que o VPC peering entre Regiões reintroduz.

A higiene da tabela de rotas é o assassino silencioso aqui. Criar uma conexão de peering ou um attachment de TGW não faz nada até que rotas CIDR explícitas sejam adicionadas nas tabelas de rotas das subnets de ambas as VPCs, apontando para o alvo pcx- ou tgw-, e os security groups permitam o tráfego. Falhas de conectividade silenciosas quase sempre se originam de uma rota ausente ou de uma negação implícita (implicit deny) em um security group que referencia o CIDR de origem errado.

Conectividade Híbrida: Site-to-Site VPN vs. Direct Connect

A escolha entre Site-to-Site VPN e Direct Connect é um trade-off entre, de um lado, a velocidade de implantação e a criptografia integrada e, de outro, a baixa latência consistente, a largura de banda dedicada e o throughput previsível.

Site-to-Site VPN estabelece dois túneis IPsec entre um customer gateway (roteador on-premises) e um Virtual Private Gateway ou um Transit Gateway. Cada túnel tem um limite de aproximadamente 1,25 Gbps. O tráfego é criptografado na camada de rede, atendendo aos requisitos de criptografia nas camadas de rede e de sessão quando combinado com TLS. Ele atravessa a internet pública, então a latência e o jitter são variáveis, mas está disponível em minutos e custa centavos por hora. Use-o quando a conectividade for necessária imediatamente, quando a largura de banda for modesta ou como um caminho de backup.

Direct Connect (DX) fornece uma conexão de fibra dedicada (1, 10 ou 100 Gbps) de um roteador on-premises para uma localidade do AWS Direct Connect. Ele contorna a internet pública, resultando em latência consistente e throughput mais alto. O preço de egresso (egress) do DX é substancialmente menor do que o de egresso da internet, o que é importante ao mover centenas de gigabytes por dia. O provisionamento leva semanas — cross-connects, LOAs, configuração de BGP.

Duas armadilhas (traps) se destacam aqui. Primeiro, o Direct Connect por si só não criptografa o tráfego. Um circuito privado não é um canal protegido criptograficamente. Para atender a um requisito de criptografia sobre o DX, adicione uma camada de Site-to-Site VPN por cima ou use MACsec para criptografia de Camada 2 em portas dedicadas compatíveis. Segundo, uma conexão DX bruta não roteia por si só para múltiplas VPCs. Uma VIF privada se conecta a um único Virtual Private Gateway anexado a uma única VPC. Para alcançar muitas VPCs — especialmente entre contas e Regiões — use um Direct Connect Gateway associado a um Transit Gateway por meio de uma transit VIF, e anexe cada VPC ao TGW:

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

O padrão de produção canônico usa duas conexões DX em duas localidades DX terminando em roteadores de cliente separados, com Site-to-Site VPN como failover automático de BGP — o AS-path prepending ou o MED do BGP direciona o tráfego para o DX enquanto ele está ativo; se ele falhar, o BGP retira as rotas do DX e a VPN assume.

Load Balancers: ALB, NLB e GWLB

O ALB é de Camada 7 e entende a semântica HTTP — roteamento por host e por caminho (path), WebSockets, redirecionamentos, sessões sticky baseadas em cookies. É a ferramenta errada para qualquer coisa que não seja HTTP: MQTT, TCP bruto, syslog sobre UDP, SMTP. O ALB usa endereçamento baseado em DNS com IPs que mudam ao longo do tempo; não é possível atribuir Elastic IPs a ele. Quando os clientes precisam adicionar IPs de destino a uma whitelist, um ALB sozinho é inadequado — use um NLB com EIPs, ou coloque o ALB atrás dos dois IPs anycast estáticos do Global Accelerator. “Resolver o DNS do ALB uma vez e fixar os IPs em regras de firewall” é uma armadilha: a AWS os altera sem aviso prévio.

O NLB é de Camada 4 e escala para milhões de fluxos por segundo. Ele preserva o IP de origem real do cliente por padrão (os targets veem o cliente real), suporta a atribuição de um Elastic IP estático por AZ e lida com cargas de trabalho TCP/UDP de alto throughput. Historicamente, o NLB não suportava security groups no próprio load balancer — os CIDRs dos clientes tinham que ser permitidos diretamente no SG do target. A AWS adicionou security groups opcionais para o NLB em 2023, mas muitos projetos ainda assumem o comportamento clássico.

O padrão canônico para aplicações públicas é:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Referenciar o security group do ALB como a origem (source) no backend — em vez de um CIDR — é o padrão de menor privilégio e cobre automaticamente o tráfego de health check, que se origina das ENIs do ALB. O próprio ALB fica em subnets públicas em pelo menos duas AZs (com rotas para o IGW); os targets ficam em subnets privadas. Colocar um ALB voltado para a internet em uma subnet privada é uma configuração incorreta clássica — o registro do target é bem-sucedido, mas os clientes não conseguem alcançá-lo.

O Gateway Load Balancer (GWLB) foi projetado especificamente para a inserção transparente de appliances virtuais de terceiros (firewalls, IDS/IPS, DPI). Ele opera na Camada 3, encaminhando todos os protocolos IP usando encapsulamento GENEVE em UDP 6081. O tráfego chega ao GWLB por meio de um endpoint do GWLB (GWLBe) — um endpoint de interface que fica em uma subnet e aparece nas tabelas de rotas como um target:

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

O endpoint encaminha pacotes via PrivateLink para o GWLB, que faz o balanceamento de carga entre a frota de appliances usando afinidade de fluxo (flow stickiness) para que ambas as direções de um fluxo atinjam o mesmo appliance. Em um design de inspeção hub-and-spoke, as VPCs spoke se conectam a um TGW cujas tabelas de rotas forçam o tráfego leste-oeste (east-west) a passar pela VPC de inspeção (contendo o GWLB e os appliances) antes de chegar às VPCs de destino. A inspeção de entrada (ingress) usa tabelas de rotas de borda (edge route tables) que redirecionam o tráfego do IGW para a camada web (web-tier) através do GWLBe primeiro:

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

Esta é a resposta correta para inspeção centralizada e entre contas (cross-account) — improvisar com EC2, hacks de tabelas de rotas personalizadas e scripts de failover reinventa o que o GWLB oferece nativamente.

PrivateLink para Serviços de Consumidor para Provedor

Além de viabilizar interface endpoints para serviços da AWS, o PrivateLink permite conectividade privada a serviços publicados por terceiros ou outras contas da AWS. O provedor posiciona seu serviço atrás de um NLB e cria um VPC endpoint service. Os consumidores criam interface endpoints em suas próprias VPCs que o acessam.

A regra de direcionalidade crítica é: a conexão é sempre iniciada do consumidor para o provedor. O provedor não pode iniciar conexões para dentro da VPC do consumidor. O tráfego nunca toca a internet, apenas o serviço de destino específico é alcançável (não a VPC inteira do provedor, como no peering), e não surgem problemas de sobreposição de CIDR porque apenas os IPs dos endpoints são expostos em cada lado. Esta é a resposta canônica para um padrão de acesso a SaaS ou banco de dados de fornecedor onde a VPC do consumidor não tem IGW, nem VPN, nem Direct Connect. O VPC peering expõe faixas de CIDR inteiras e exige IPs que não se sobreponham; um attachment de TGW roteia de forma ampla; uma API pública pela internet não é privada.

Global Accelerator e Route 53

O AWS Global Accelerator atribui dois endereços IPv4 estáticos anycast anunciados a partir das localizações de borda (edge locations) da AWS em todo o mundo. O tráfego do cliente entra na borda mais próxima e percorre o backbone da AWS até o endpoint regional saudável mais próximo (ALB, NLB, EIP ou EC2). Isso resolve dois problemas de uma só vez: IPs estáticos na frente de ALBs (corrigindo a lacuna de whitelisting) e jitter/latência reduzidos para usuários distribuídos globalmente, ao encurtar o caminho pela internet pública. Ele acelera o tráfego TCP/UDP não cacheável para origens onde o CloudFront (que armazena conteúdo em cache) não é aplicável.

O Route 53 resolve um problema diferente — o direcionamento de tráfego no nível de DNS. O Global Accelerator afeta o plano de dados (data plane) em si; o Route 53 afeta apenas a resolução de DNS, após a qual a conexão TCP vai para onde quer que o IP resolvido esteja. Os dois são frequentemente combinados: um alias do Route 53 aponta para um Global Accelerator que está na frente de ALBs regionais.

Políticas de roteamento do Route 53:

Latência e geolocalização são frequentemente confundidas: latência minimiza o RTT percebido pelo usuário; geolocalização impõe a residência de dados (data residency) independentemente da latência. O failover multi-região requer health checks no primário. Registros Alias são específicos da AWS, resolvem diretamente para endpoints de ALB, NLB, CloudFront, site S3 e API Gateway sem custo por consulta e — ao contrário dos CNAMEs — funcionam no ápice da zona (zone apex).

O Route 53 Resolver responde a consultas DNS dentro de uma VPC através do endereço .2 (base do CIDR da VPC + 2). Para DNS híbrido, inbound endpoints permitem que resolvers on-premises consultem zonas hospedadas privadas (private hosted zones) na AWS; outbound endpoints com regras de encaminhamento (forwarding rules) permitem que recursos da VPC resolvam nomes on-premises. Sem eles, instâncias EC2 não conseguem resolver corp.internal e servidores on-prem não conseguem resolver db.prod.internal — uma quebra sutil que só aparece quando as aplicações começam a fazer buscas entre ambientes. Interface endpoints exigem a opção Enable Private DNS para que as chamadas do SDK atinjam a ENI do endpoint; sem isso, as chamadas ainda alcançam o endpoint público pela internet, anulando o propósito.

Security Groups, NACLs e Menor Privilégio

Security groups são stateful — o tráfego de retorno é permitido automaticamente — e atuam no nível da ENI. NACLs são stateless e atuam na fronteira da sub-rede (subnet). Qualquer regra TCP em uma NACL requer uma regra explícita de entrada (inbound) e de saída (outbound); como os clientes escolhem uma porta de origem do intervalo efêmero, a regra na direção de retorno deve permitir as portas 1024–65535 (o Linux usa 32768–60999 por padrão; o intervalo mais amplo cobre o Windows e outras pilhas). Esquecer a regra de retorno efêmera é uma causa clássica de conexões que completam o SYN, mas travam ao esperar a resposta.

Para o menor privilégio (least privilege) entre camadas (tiers), as regras de security group devem referenciar outros IDs de security groups, e não CIDRs. Isso escala com o Auto Scaling e evita whitelists de IP frágeis:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACLs são um controle de raio de alcance (blast radius) grosseiro, não um substituto para security groups. Restringir NACLs “para defesa em profundidade” sem alterações correspondentes nos security groups comumente quebra fluxos iniciados de saída, como atualizações yum/apt através de um NAT gateway, porque o tráfego de retorno stateless é descartado silenciosamente. As tabelas de rotas (route tables) determinam, em última análise, a alcançabilidade: mesmo um security group permissivo não pode entregar tráfego se a tabela de rotas não tiver uma entrada para o destino e, inversamente, um gateway endpoint só é eficaz quando a rota da lista de prefixos (prefix list) do S3 está de fato instalada nas tabelas de rotas das sub-redes que hospedam a carga de trabalho.

Referência de Decisão

← Transferência e Migração de Dados · Todos os domínios · Entrega de Conteúdo →

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

Navegar Amazon →