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

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Visão Geral

As redes e a entrega de conteúdo na AWS abrangem construções fundamentais de VPC, opções de interconexão para topologias multi-account e híbridas, e serviços de borda que ficam à frente, protegem e aceleram aplicações globalmente. Para dominar o assunto, é preciso entender como os pacotes se movem em uma VPC (sub-redes, tabelas de rotas, gateways e filtragem), como interconectar VPCs e redes on-premises (peering, Transit Gateway, PrivateLink, Direct Connect, VPN) e como distribuir e proteger o tráfego na borda (CloudFront, AWS WAF, AWS Global Accelerator). Pontos de entrada de aplicações, como o Amazon API Gateway, integram-se com esses primitivos por meio de domínios personalizados, certificados e tipos de endpoint.

Arquitetura de VPC e Controles de Segurança

Uma VPC é uma rede regional e logicamente isolada com uma ou mais sub-redes em cada Zona de Disponibilidade. Projete as sub-redes de acordo com os domínios de falha e as funções: sub-redes públicas para load balancers voltados para a internet e gateways NAT; sub-redes privadas de aplicação para nós EC2/ECS/EKS; e sub-redes privadas de dados para bancos de dados. Atribua tabelas de rotas distintas por tipo de sub-rede para manter a intenção explícita e para suportar um design de egresso zonal.

A conectividade com a internet é fornecida por um internet gateway (IGW) anexado no nível da VPC. Uma sub-rede se torna “pública” quando sua tabela de rotas tem uma rota padrão para o IGW e os recursos têm IPs públicos ou Elastic IPs. Para acesso à internet somente de saída a partir de sub-redes privadas, use gateways NAT. Posicione um gateway NAT por Zona de Disponibilidade, roteie cada sub-rede privada para o gateway NAT na mesma AZ e desabilite o NAT entre AZs para evitar pontos únicos de falha e reduzir as cobranças de processamento de dados entre AZs. Para IPv6, os egress-only internet gateways fornecem conectividade somente de saída sem NAT.

As tabelas de rotas determinam os próximos saltos (next hops) para os prefixos de destino. Alvos comuns incluem IGW, gateway NAT, anexos (attachments) de VPC peering, anexos do Transit Gateway e local. Mantenha as tabelas de rotas simples: uma rota padrão para egresso e rotas explícitas para interconexões privadas. Prefira usar prefix lists para referenciar destinos compartilhados entre contas e para reduzir erros humanos.

Security groups e network ACLs fornecem filtragem de rede, mas com mecânicas diferentes:

Security groups são stateful, anexados a ENIs e avaliados apenas por regras de permissão (allow). O tráfego de retorno é permitido automaticamente. Eles suportam referências a outros security groups para expressar a topologia da aplicação de forma segura.
Network ACLs são stateless, aplicadas no limite da sub-rede, avaliadas pela ordem das regras com permissão/negação (allow/deny) explícita para entrada e saída. O tráfego de retorno deve ser permitido explicitamente. Use NACLs com moderação para regras de negação mais amplas no nível da sub-rede ou para padrões de conformidade; mantenha os intervalos de portas efêmeras exigidos por seus sistemas operacionais e load balancers.

A diferença entre filtragem stateful e stateless é importante para o troubleshooting. Se ambos forem usados, ambos devem permitir o fluxo. Habilite os VPC Flow Logs para o CloudWatch Logs ou S3 para analisar o tráfego aceito/negado e para validar a postura de segurança.

Conectividade Híbrida e entre VPCs

O VPC peering conecta duas VPCs de forma privada, sem ponto único de falha e sem gargalo de largura de banda, mas não é transitivo e exige CIDRs que não se sobreponham. Cada VPC deve adicionar rotas estáticas para o peer por meio do anexo de peering (peering attachment). Referências a security groups entre VPCs em peering não são suportadas; filtre com CIDRs. O peering entre Regiões está disponível e é criptografado por padrão.

O AWS Transit Gateway (TGW) simplifica a escala e a segmentação da rede. Ele atua como um hub regional para VPCs e anexos (attachments) híbridos, suporta roteamento transitivo e escala para dezenas de Gbps por anexo. Use as tabelas de rotas do TGW para implementar a segmentação (ex: dev vs. prod vs. serviços compartilhados) e para controlar a propagação e a associação. Os anexos incluem VPCs, Site-to-Site VPNs e Direct Connect por meio de uma Transit VIF e um Direct Connect Gateway. Para egresso centralizado, anexe uma VPC de egresso e propague/compartilhe rotas seletivamente. Planeje para multi-Região conectando TGWs com peering entre Regiões.

O AWS PrivateLink fornece acesso privado de camada 4 (L4), iniciado pelo consumidor, a serviços através das fronteiras de VPC/conta/Região, sem expor as sub-redes do provedor ou exigir roteamento. O provedor de serviço posiciona um NLB na frente dos endpoints; os consumidores criam endpoints de VPC de interface em suas VPCs com IPs privados e nomes DNS atribuídos. O PrivateLink não é transitivo e suporta apenas TCP. Use o PrivateLink para publicar serviços internos ou para consumir serviços da AWS de forma privada. Prefira o PrivateLink em vez de peering/TGW quando precisar de exposição no nível do serviço, consumo baseado em DNS ou um isolamento mais rígido do produtor.

A conectividade híbrida geralmente combina Direct Connect (DX) e Site-to-Site VPN. O Direct Connect fornece largura de banda dedicada, privada e consistente com portas de 1/10 Gbps (e capacidades hospedadas). Use BGP para roteamento dinâmico e failover. Tipos de interface virtual (VIF):

Private VIF: alcançabilidade de IP privado para VPCs por meio de um virtual private gateway (VGW) ou de um Transit Gateway com uma Transit VIF.
Public VIF: alcançabilidade de IP público para serviços públicos da AWS; anuncie seus prefixos públicos; a AWS anuncia seus prefixos públicos globais.
Transit VIF: conecta um Direct Connect gateway a um ou mais TGWs para conectividade escalável multi-VPC/multi-Região. Projete a redundância usando duas conexões DX físicas em locais e dispositivos DX separados, com LAGs separados se necessário, e roteadores duplos on-premises. Adicione uma VPN como backup (VPN pela internet para o VGW ou TGW) com BGP para que as rotas façam failover automaticamente quando as sessões BGP do DX caírem. Para VPN, use dois túneis por conexão para alta disponibilidade (HA); prefira BGP a rotas estáticas; valide os CIDRs do túnel interno e a segurança.

Rede de Borda, Segurança e Aceleração

O Amazon CloudFront é uma CDN global que acelera conteúdo estático e dinâmico com cache de borda e caminhos de rede otimizados. Uma distribuição define:

Origens: S3, origens personalizadas (ALB/NLB/EC2/API Gateway) ou grupos de origem para failover. Habilite o Origin Shield para um cache extra de camada intermediária para reduzir a carga na origem.
Comportamentos: roteamento para origens com base em caminho e método, políticas de cache e de solicitação de origem (encaminhamento de headers/cookies/queries), políticas de protocolo do visualizador (HTTP→HTTPS), compressão, URLs/cookies assinados e hooks de função (CloudFront Functions para solicitações leves do visualizador; Lambda@Edge para manipulação de solicitações/respostas).
Cache: ajuste os TTLs por meio de políticas de cache, varie as chaves apenas nas dimensões necessárias e use políticas de solicitação de origem para minimizar a fragmentação do cache. Para APIs, evite encaminhar headers/cookies/queries desnecessários. Use criptografia em nível de campo onde necessário.
Invalidação: emita invalidações para caminhos alterados ou use chaves de objeto versionadas para atualizações de cache sem tempo de inatividade (zero-downtime). Automatize as invalidações pós-implantação para ativos não versionados.

O AWS WAF protege aplicações na camada L7. Uma web ACL contém regras e grupos de regras avaliados em ordem, com uma ação padrão. Use as AWS Managed Rules para proteções de base (ex: CommonRuleSet, WordPress, SQLi/XSS) e grupos de regras de parceiros selecionados quando necessário. Adicione regras personalizadas usando declarações de correspondência (conjunto de IPs, header, URI, corpo JSON, correspondência de rótulo) e combine-as com operadores lógicos. Regras baseadas em taxa (rate-based) limitam clientes que excedem uma taxa de solicitações configurada em uma janela de tempo, opcionalmente com declarações de escopo reduzido (scope-down) para visar caminhos ou headers específicos. Associe as web ACLs a distribuições do CloudFront, Application Load Balancers, API Gateway (REST/HTTP) e AppSync. Monitore a capacidade (WCU), habilite logs de amostra para o CloudWatch Logs ou Kinesis Data Firehose e use ações de CAPTCHA/Challenge para mitigar bots sem bloquear o tráfego legítimo.

O AWS Global Accelerator fornece IPs anycast estáticos que servem de fachada para endpoints regionais e acelera o tráfego TCP/UDP pela rede global da AWS. Ele opera nas camadas L4/7 com roteamento baseado em verificação de saúde e failover rápido. Configure:

Grupos de endpoints por Região com verificações de saúde e pesos.
Controles de tráfego (traffic dials) para controlar a porcentagem de tráfego enviada para uma Região (ex: 1% para canary ou 0% durante a manutenção), independentemente dos pesos dos endpoints. Os endpoints suportados incluem instâncias ALB, NLB, EC2 e Elastic IPs. Use o Global Accelerator para protocolos não-HTTP, sensíveis à latência, stateful, ou quando IPs estáticos e failover determinístico são necessários. O CloudFront continua sendo a escolha principal para cache de HTTP/S e execução de funções na borda; os dois são complementares.

Portas de Entrada de APIs: Domínios, Certificados e Estratégia de Endpoint

O Amazon API Gateway oferece APIs REST e HTTP com três tipos de endpoint:

Otimizado para a borda (somente APIs REST): O API Gateway cria e gerencia uma distribuição do CloudFront; ideal para clientes globais com terminação TLS nos pontos de presença (edge locations). Certificados de domínio personalizado devem estar em us-east-1 (N. Virginia) via ACM.
Regional: para clientes na mesma Região ou quando você deseja usar sua própria distribuição do CloudFront ou o Global Accelerator na frente do API Gateway. Certificados de domínio personalizado devem estar na mesma Região da API.
Privado: acessível apenas dentro de suas VPCs por meio de endpoints de VPC de interface; sem caminho pela internet pública.

Domínios personalizados unificam o roteamento e o TLS entre estágios e APIs. Use mapeamentos de caminho base para mapear caminhos para estágios. Armazene certificados no ACM; escolha RSA/ECDSA conforme o suporte do cliente. Para otimizado para a borda, solicite/importe o certificado em us-east-1. Para Regional, solicite/importe na Região. Aplique políticas de TLS que correspondam à sua postura de conformidade. Integre com o WAF associando uma web ACL diretamente a APIs Regionais ou protegendo a distribuição do CloudFront que está na frente da API. Para APIs globais de latência mais baixa com cache avançado e normalização de cabeçalhos, posicione uma distribuição do CloudFront na frente de uma API Regional, use o controle de acesso à origem (origin access control) e solicitações assinadas se necessário, e ajuste as políticas de cache e de solicitação de origem para evitar o inchaço do cache (cache bloat). Combine com autorizadores Lambda ou Amazon Cognito para autenticação e utilize planos de uso e limitação (throttling) para proteger os back-ends, além das regras baseadas em taxa do WAF.

Cenário de Problema Prático

A Shopify está lançando um novo microsserviço de checkout global para atender comerciantes em todo o mundo. Requisitos: tráfego leste-oeste (east–west) privado entre microsserviços em mais de 20 contas, exposição pública zero para APIs internas, latência baixa e determinística para usuários finais no checkout, proteções L7 robustas com limitação de taxa adaptativa e conectividade híbrida resiliente com motores de risco on-premises.

Abordagem passo a passo:

Segmente a rede com um design hub-and-spoke usando o Transit Gateway

Crie uma conta de rede centralizada com um AWS Transit Gateway regional. Anexe todas as VPCs de carga de trabalho (spokes) de cada conta por meio de anexos de TGW compartilhados via RAM. Use várias tabelas de rotas do TGW para impor a segmentação (produção vs. serviços compartilhados vs. desenvolvimento) e propague apenas as rotas necessárias.
Por que o TGW: Escala o roteamento transitivo e simplifica o gerenciamento de rotas em comparação com uma malha completa de peerings; suporta anexos híbridos.

Publique microsserviços internos com o AWS PrivateLink

Em cada VPC produtora, posicione um NLB na frente dos grupos de destino (target groups) do microsserviço interno e crie um serviço de endpoint de VPC. Nas VPCs consumidoras, crie endpoints de interface para esses serviços e habilite o DNS privado específico do endpoint.
Por que o PrivateLink: Conectividade no nível de serviço, somente TCP, não transitiva e sem exposição de rotas; os produtores permanecem isolados e não precisam de permissões de entrada nos SGs para blocos CIDR inteiros.

Estabeleça conectividade híbrida redundante com Direct Connect e VPN

Provisione duas conexões Direct Connect de 10 Gbps em locais de DX separados, terminando em roteadores on-premises distintos. Crie um Direct Connect Gateway com uma VIF de trânsito (Transit VIF) para o TGW. Configure o BGP em ambos os lados com ASNs distintos e políticas de MED/local-pref. Adicione um anexo de Site-to-Site VPN ao TGW como backup, com dois túneis e BGP habilitado.
Por que essa combinação: O DX fornece largura de banda determinística e menor jitter; o BGP mais o backup de VPN oferece failover automático e alta disponibilidade.

Use o AWS Global Accelerator na frente do checkout público

Crie um acelerador com dois listeners (80/443 → 443). Defina grupos de endpoints em us-east-1 e eu-west-1, cada um apontando para ALBs do serviço de checkout. Configure os seletores de tráfego (traffic dials) para 50/50 em estado normal e habilite as verificações de saúde nos endpoints de saúde do ALB. Habilite a afinidade de cliente (client affinity) se a fixação de sessão (session pinning) for necessária.
Por que o Global Accelerator: IPs estáticos Anycast, failover regional rápido e otimização de TCP para fluxos de checkout stateful e de baixa latência.

Proteja na borda com CloudFront e AWS WAF

Posicione o CloudFront na frente do API Gateway Regional (para GETs idempotentes e ativos estáticos) e diretamente na frente dos ALBs que servem conteúdo dinâmico que pode se beneficiar da normalização de cabeçalhos e do descarregamento de TLS (TLS offload). Configure políticas de cache para restringir a variação aos cabeçalhos/consultas necessários, habilite o Origin Shield para reduzir a carga na origem e automatize as invalidações para ativos não versionados.
Anexe uma web ACL do AWS WAF ao CloudFront com as Regras Gerenciadas da AWS (AWS Managed Rules), um grupo de regras personalizado para filtragem de lógica de negócios e uma regra baseada em taxa com uma declaração de escopo reduzido (scope-down statement) nos caminhos de checkout. Habilite o CAPTCHA para picos suspeitos e registre os logs no Kinesis Data Firehose para análise.
Por que CloudFront + WAF: Terminação TLS global, cache onde for seguro, controles L7 baseados na borda e absorção de DDoS via AWS Shield.

Exponha as APIs com domínios personalizados e TLS robusto

Use endpoints Regionais do API Gateway para métodos de API com uso intensivo de escrita, protegidos atrás do CloudFront. Crie domínios personalizados no ACM por Região, aplique políticas de TLS rigorosas e mapeie os caminhos base para os estágios. Para APIs de administração internas, implante APIs Privadas e acesse-as por meio de endpoints de VPC de interface; associe security groups de privilégio mínimo.
Por que essa divisão: Endpoints regionais mais o CloudFront oferecem flexibilidade com controles de borda; APIs Privadas mantêm as superfícies internas fora da internet.

Proteja as VPCs com controles em camadas

Aplique security groups stateful de privilégio mínimo, referenciando SGs de produtor/consumidor sempre que possível. Mantenha as NACLs simples (permitir tudo), exceto para negações de sub-rede direcionadas necessárias para conformidade. Habilite os VPC Flow Logs com filtros de métrica do CloudWatch para detectar fontes anômalas. Posicione um NAT gateway por AZ e roteie as sub-redes privadas para o NAT local para evitar dependências entre AZs.
Por que controles em camadas: Os SGs lidam com a maior parte da intenção com rastreamento de conexão; as NACLs fornecem barreiras de segurança mais amplas; o NAT zonal melhora a resiliência e o custo.

Este design oferece conectividade leste-oeste (east–west) privada e segmentada (Transit Gateway + PrivateLink), caminhos híbridos norte-sul (north–south) resilientes (DX + VPN com BGP), entrada pública globalmente acelerada e protegida (Global Accelerator + CloudFront + WAF) e controles operacionais alinhados com as melhores práticas da AWS para roteamento, gateways e filtragem de VPC.

← Armazenamento · Todos os domínios · Systems Manager →

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