Amazon SOA-C02: Redes e Entrega de Conteúdo — Guia de estudos

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Faz parte do AWS SysOps Administrator Associate SOA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Redes e Entrega de Conteúdo (Networking and Content Delivery) abrange os fundamentos de VPC, conexões híbridas, DNS e roteamento global, cache de borda com o CloudFront e o ciclo de vida de certificados TLS — todos críticos para disponibilidade, segurança e desempenho. O domínio operacional garante que as cargas de trabalho estejam acessíveis, resilientes a falhas e seguras tanto no ambiente on-premises quanto na nuvem. Esta seção foca em padrões de configuração práticos, exemplos de CLI/console e critérios de decisão que você usará como administrador SysOps dando suporte a sistemas de produção.

Projeto de VPC, sub-redes, roteamento e conectividade

Projete o espaço CIDR da VPC com o crescimento futuro em mente: aloque uma VPC suficientemente grande (por exemplo, /16 ou /20, dependendo da escala) e divida-a em sub-redes locais por AZ (10.0.0.0/24, 10.0.1.0/24 por AZ) para evitar dependências entre AZs. Crie tabelas de rotas explícitas por tipo de sub-rede: sub-redes públicas usam uma rota para o Internet Gateway (IGW) — ex.:

undefined

; sub-redes privadas roteiam 0.0.0.0/0 para um NAT Gateway na mesma AZ para custos de egresso previsíveis e menor latência.

Entenda o comportamento do NAT e as nuances de roteamento: o NAT Gateway/Instance realiza NAT de origem (source NAT) para conexões IPv4 de saída e exige que o tráfego de retorno siga a tabela de rotas da sub-rede de volta pelo NAT. Para IPv6, use um egress-only internet gateway. Use a AWS CLI para criar um NAT Gateway e associar um Elastic IP:

undefined

. Use a propagação de rotas com anexos do Transit Gateway ou VPN para gerenciar rotas dinâmicas automaticamente.

A configuração de security groups vs. NACLs e o fluxo de tráfego devem ser deliberados: security groups são stateful (você permite a entrada, o retorno é automático) e são anexados a ENIs; NACLs são stateless e avaliadas por sub-rede com regras ordenadas, então você deve permitir tanto as portas efêmeras de entrada quanto as de saída. Comandos de exemplo:

undefined

;

undefined

. Critérios de decisão: use security groups para controle de acesso no nível da instância e NACLs para perímetro, filtragem de alto desempenho e isolamento entre contas.

VPN, Direct Connect e redes híbridas

Selecione a conectividade com base nas necessidades de largura de banda, latência e resiliência. A Site-to-Site VPN fornece túneis IPsec criptografados pela internet e é rápida de implantar usando

undefined

. Configure dois túneis VPN para alta disponibilidade (HA); use BGP para roteamento dinâmico e propagação de rotas via Virtual Private Gateway ou Transit Gateway. Use a AWS Managed VPN para uma implementação rápida e como failover para o Direct Connect.

O Direct Connect oferece conectividade privada, de alta largura de banda e baixa latência. Provisione uma conexão (ou LAG) com o console do Direct Connect e crie interfaces virtuais privadas (VIFs) para VPCs através de um Direct Connect Gateway para acesso multirregional. Use BGP com o ASN apropriado e prefira uma abordagem híbrida de DX + VPN: anuncie prefixos críticos pelo DX com a VPN como backup automático. Critérios de decisão:

Use VPN para necessidades de curto prazo, largura de banda de baixa a média ou como backup criptografado baseado na internet.
Use o Direct Connect quando a alta taxa de transferência sustentada e a latência previsível justificarem os custos de porta e cross-connect.
Use o Transit Gateway para centralizar muitas conexões de VPC e on-premises se você precisar de escala hub-and-spoke e gerenciamento de rotas simplificado.

Checklist operacional: confirme se as sessões BGP estão ativas, garanta a propagação da tabela de rotas (para TGW, use

undefined

) e teste o failover desativando um túnel ou alterando os caminhos BGP.

DNS do Route 53, health checks e políticas de roteamento

O Route 53 é tanto um DNS autoritativo quanto um plano de controle de roteamento. Implemente health checks para endpoints (HTTP/HTTPS/TCP) e combine-os com registros de failover ou ponderados. Exemplo: crie um registro de failover com tipos de registro primário/secundário no console do Route 53 ou use

undefined

com uma política de roteamento de Failover e um HealthCheckId. Ajuste o TTL com base no SLA de failover esperado — TTL baixo (30-60s) para failover ativo, mais longo (300s+) para endpoints estáveis.

Escolha a política de roteamento por objetivo:

Simples (Simple): retorna um único valor; use para endpoints não críticos ou únicos.
Failover: primário/secundário com health checks para gerenciamento de desastres.
Ponderada (Weighted): desvio gradual de tráfego para implantações blue/green ou canary.
Baseada em latência (Latency-based): roteia os usuários para a região com a menor latência.
Geolocalização/Geoproximidade (Geolocation/geoproximity): para cumprir com a residência de dados ou para conteúdo direcionado.

Pontos para tomada de decisão:

Para aplicações globais com regiões ativo-ativo e ELB: use registros Alias apontando para o ALB/ELB para evitar cobranças extras e aproveitar a saúde do endpoint.
Para migrações planejadas ou modelagem de tráfego: use registros Ponderados (Weighted) e altere os pesos incrementalmente via CLI (

undefined