Amazon ANS-C01: Entrega de Conteúdo e Redes de Borda — Guia de estudos
Faz parte do AWS Advanced Networking Specialty ANS-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.
Conceitos principais
A entrega de conteúdo e a rede de borda separam duas responsabilidades relacionadas: transportar o tráfego do cliente com baixa latência e atuar como uma camada distribuída de cache/computação próxima aos usuários finais. O CloudFront é uma CDN HTTP(S) e plataforma de computação de borda que armazena respostas HTTP em cache, encerra o TLS na borda e pode executar código em edge locations usando o Lambda@Edge (runtime completo do Lambda replicado para as regiões) ou o CloudFront Functions para JavaScript leve na requisição/resposta do visualizador. O comportamento do CloudFront é controlado por objetos de configuração da distribuição, criados com CreateDistribution e ajustados usando objetos CachePolicy e OriginRequestPolicy. Campos da política de cache, como DefaultTTL, MinTTL e MaxTTL, e o conjunto de cabeçalhos, cookies e query strings incluídos na chave de cache (cache key) determinam a taxa de acertos do cache (cache hit ratio) e a carga na origem (origin load). Os controles de origem incluem S3 OAC/OAI para origens S3 privadas (CreateCloudFrontOriginAccessControl) e URLs assinadas (signed URLs) ou cookies assinados (signed cookies) (CreateKeyGroup, CreatePublicKey e o processo de assinatura de URL) para proteger conteúdo privado.
O Global Accelerator e o Anycast operam abaixo da camada HTTP. O Global Accelerator anuncia dois endereços IP anycast estáticos da rede de borda da AWS e roteia fluxos TCP/UDP para endpoints regionais íntegros (Network Load Balancers, Application Load Balancers, instâncias EC2 ou Elastic IPs). Como o Global Accelerator opera em L3/L4, ele preserva o TLS de ponta a ponta (end-to-end) quando configurado para TCP pass-through e melhora o roteamento global usando o backbone interno da AWS para a “última milha” (last mile) até os endpoints regionais. Para protocolos não HTTP ou quando a criptografia de ponta a ponta real e o TLS mútuo (mTLS) devem ser preservados entre o cliente e o backend, um caminho de TCP pass-through usando o Global Accelerator à frente de um Network Load Balancer (NLB) é o padrão canônico: os NLBs operam em L4, escalam para milhões de conexões e podem registrar alvos de IP (IP targets) para pods ou nodes no Amazon EKS.
As funções Lambda@Edge são associadas a comportamentos (behaviors) do CloudFront e devem ser implantadas (CreateFunction com Publish) e associadas nas LambdaFunctionAssociations da distribuição para os gatilhos (triggers) de viewer-request, origin-request, origin-response e viewer-response. Como o Lambda@Edge se replica para múltiplas regiões de borda, as versões e a semântica de publicação são importantes; use objetos Lambda versionados e gerencie as implantações com cuidado para evitar comportamento inconsistente durante as atualizações.
Principais serviços e configuração
A configuração da distribuição do CloudFront depende de três objetos fortemente acoplados: a própria distribuição (CreateDistribution / UpdateDistribution), objetos CachePolicy que determinam a chave de cache e os TTLs (CreateCachePolicy), e objetos OriginRequestPolicy que determinam quais cabeçalhos/cookies/query strings são enviados para a origem (CreateOriginRequestPolicy). Para conteúdo S3 privado, use o CreateCloudFrontOriginAccessControl ou a antiga origin access identity, e proteja ainda mais os acessos com signed URLs / signed cookies usando CreateKeyGroup e CreatePublicKey; o SDK ou os utilitários cloudfront-signing geram a URL assinada ou o documento de política (policy document) e a assinatura RSA. As operações de invalidação são realizadas com CreateInvalidation para purgar objetos em cache seletivamente.
A configuração do Global Accelerator é criada por meio das chamadas de API create-accelerator, create-listener e create-endpoint-group. O listener pode ser TCP:443 para gRPC ou qualquer porta TCP e encaminhará os fluxos para grupos de endpoints (endpoint groups) que apontam para um NLB ou ALB regional. Quando o Global Accelerator é usado para TCP pass-through para preservar o TLS de ponta a ponta e o mTLS, combine-o com um Network Load Balancer que tenha listeners TCP na porta 443 e grupos de destino (target groups) que registrem IPs de pods (target type ip) ou portas de nós (node ports). No Kubernetes EKS, isso geralmente é alcançado criando um Service do tipo LoadBalancer com anotações como service.beta.kubernetes.io/aws-load-balancer-type: “nlb” e service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”, ou usando o AWS Load Balancer Controller para criar um NLB com o tipo de destino (target type) ip. Preserve o IP de origem do cliente para fins de log definindo externalTrafficPolicy: Local no Service ou usando o passthrough do NLB, que mantém o IP de origem original.
A aplicação de regras em nível de rede entre o Global Accelerator e os endpoints regionais usa listas de prefixos gerenciadas pela AWS (AWS-managed prefix lists) para reduzir a sobrecarga administrativa. A chamada da AWS CLI aws ec2 describe-managed-prefix-lists lista as managed prefix lists; a chamada com.amazonaws.globalaccelerator pode ser referenciada em regras de security group (AuthorizeSecurityGroupIngress com –source-prefix-list) para permitir apenas o tráfego originado do acelerador para um ALB/NLB. Onde o ALB encerra o TLS, use os cabeçalhos X-Forwarded-For para o log do IP do cliente; ao usar o passthrough do NLB com o Global Accelerator, os IPs do cliente são preservados nativamente e os backends devem lidar com o encerramento do TLS/mTLS.
Padrões de design e trade-offs
Quando o requisito é cache de conteúdo, computação na borda e respostas HTTP de baixa latência, o CloudFront é a ferramenta certa. O CloudFront deve terminar o TLS na borda quando a confidencialidade da origem não for necessária; use CachePolicy e OriginRequestPolicy para minimizar as solicitações à origem, excluindo cabeçalhos e cookies da chave de cache onde for seguro. Para personalização dinâmica que ainda se beneficia do cache, use a normalização da chave de cache (variando em um conjunto mínimo de cabeçalhos ou cookies assinados) e projete a invalidação de cache por meio de chaves de objeto versionadas em vez de chamadas frequentes de CreateInvalidation.
Para protocolos que exigem TLS de ponta a ponta, fluxos HTTP/2 e gRPC que não devem ser descriptografados até o backend (para mTLS), coloque um caminho TCP/L4 na frente usando o Global Accelerator + NLB com passthrough de TLS. O trade-off é a perda das capacidades de cache HTTP e computação na borda do CloudFront; no entanto, o Global Accelerator oferece IPs estáticos anycast, roteamento aprimorado e failover regional. O ALB suporta HTTP/2 e gRPC quando o ALB termina o TLS, o que permite o roteamento na camada de aplicação (baseado em host/caminho) e a integração com o WAF, mas a terminação no ALB quebra o mTLS de ponta a ponta e coloca o gerenciamento de certificados no load balancer. Para um número massivo de conexões simultâneas, os NLBs escalam melhor em L4 — os NLBs são otimizados para a taxa de conexão e preservam o IP de origem, enquanto os ALBs são projetados para roteamento no nível HTTP e recursos como regras de listener para roteamento no nível de host/caminho e integração com Cognito/OIDC.
Controles de segurança e padrões de isolamento regional exigem uma seleção cuidadosa entre VPC peering compartilhado, Transit Gateway, PrivateLink e endpoints de Load Balancer. O PrivateLink fornece controles de acesso granulares no nível de serviço e escala bem para muitos consumidores, porque cada consumidor cria um endpoint de interface em sua própria VPC. O Transit Gateway é apropriado para a centralização de alta largura de banda, mas carece dos controles granulares por serviço e da visibilidade no nível de SNI/host que um endpoint do PrivateLink oferece. O design deve considerar os limites de roteamento, as permissões entre contas e a capacidade de aplicar security groups na fronteira do serviço.
Armadilhas comuns e critérios de decisão
Um erro frequente é misturar os controles de cache incorretamente: permitir que os cabeçalhos Cache-Control definidos na origem controlem o cache na borda enquanto as políticas de cache do CloudFront também se aplicam pode criar TTLs inesperados; prefira objetos CachePolicy explícitos e não dependa apenas dos cabeçalhos da origem, a menos que seja deliberado. Outra armadilha é selecionar um ALB quando são necessários TLS de ponta a ponta ou milhões de conexões TCP simultâneas; o TLS terminado no ALB impede o mTLS e pode se tornar o gargalo para uma simultaneidade de conexões muito alta. Configurações de segurança que tentam restringir o acesso a um ALB voltado para a internet muitas vezes esquecem de bloquear o acesso usando a lista de prefixos do Global Accelerator ou uma regra do WAF; sem regras de permissão (allow) explícitas, o ALB permanecerá acessível através de seu DNS público. Finalmente, implantações do Lambda@Edge que não usam funções Lambda versionadas podem causar comportamento inconsistente durante os rollouts, porque a associação na distribuição está vinculada a uma versão publicada específica.
Problema Prático: Cenário de Caso de Uso
Empresa: AcmeTelemetrics — desafio: uma frota global de máquinas de venda automática de IoT usa gRPC sobre TCP:443 para um backend em us-east-1 rodando no Amazon EKS; o requisito é TLS mútuo (mTLS) de ponta a ponta para que o tráfego nunca seja descriptografado em trânsito, suporte a milhares de conexões simultâneas e IPs estáticos que devem ser programados nas máquinas.
Abordagem:
- Crie um Global Accelerator (aws globalaccelerator create-accelerator) com dois IPs estáticos anycast e um listener TCP na porta 443 (create-listener). Configure um grupo de endpoints (endpoint group) que aponte para um Network Load Balancer regional em us-east-1 (create-endpoint-group).
- Provisione um NLB em us-east-1 com um listener TCP na porta 443 e um target group do tipo ip. No Kubernetes, crie um Service do tipo LoadBalancer com as anotações service.beta.kubernetes.io/aws-load-balancer-type: “nlb” e service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”, defina externalTrafficPolicy: Local e registre os IPs dos pods como targets para que o TLS seja passado diretamente para os pods.
- Implante os servidores gRPC no EKS e termine o TLS/mTLS nos processos do pod. Armazene os certificados e o material de confiança (trust material) nos Kubernetes Secrets; configure o servidor para exigir a verificação do certificado do cliente para o TLS mútuo.
- Bloqueie o acesso direto ao NLB para que apenas o Global Accelerator possa alcançá-lo, atualizando o security group do NLB para permitir entrada (ingress) apenas da lista de prefixos gerenciada pela AWS para o Global Accelerator (descubra via aws ec2 describe-managed-prefix-lists e referencie essa lista de prefixos nas regras do security group), impedindo que as máquinas contornem o acelerador e acessem o NLB diretamente.
- Monitore a simultaneidade de conexões e o escalonamento configurando o HorizontalPodAutoscaler e o Cluster Autoscaler do Kubernetes, e garanta que o slow start e o atraso de cancelamento de registro (deregistration delay) do target group do NLB estejam ajustados para um scale-in gradual (modify-target-group-attributes). Use as métricas do CloudWatch do Global Accelerator, NLB e EKS para observar as contagens de conexão e a saúde (health).
Justificativa da AWS: O Global Accelerator fornece os IPs estáticos anycast exigidos pelas máquinas de venda automática e roteia os fluxos TCP pelo backbone da AWS até o NLB regional, melhorando a confiabilidade e a latência. O NLB preserva a conexão TCP original do cliente e o IP de origem, e suporta um número massivo de conexões simultâneas, permitindo que os pods realizem a terminação do mTLS sem uma terminação de TLS intermediária. O uso da lista de prefixos gerenciada do Global Accelerator nas regras do security group impede o desvio direto do acelerador e garante que o tráfego chegue apenas através dos IPs anycast. Essa combinação satisfaz os requisitos de criptografia de ponta a ponta, mTLS, alta simultaneidade, IPs estáticos e autoscaling no EKS.
← Segurança de Rede e Conformidade · Todos os domínios · Desempenho de Rede e Monitoramento →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →