Amazon SAA-C03: Entrega de Conteúdo, Edge e Otimização de Desempenho — 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.

Amazon CloudFront: O que é e por que ajuda

O Amazon CloudFront é uma rede de entrega de conteúdo (CDN) distribuída globalmente, construída sobre mais de 600 pontos de presença. Sua função é encerrar o TLS do visualizador na borda mais próxima e servir respostas em cache imediatamente ou encaminhar os erros de cache (cache misses) por proxy através do backbone privado da AWS até a origem. O benefício de desempenho é duplo: os acertos de cache (cache hits) reduzem o tempo de ida e volta para milissegundos de um dígito e desoneram completamente a origem, enquanto os erros de cache ainda se beneficiam da terminação TLS/TCP otimizada na borda, suporte a HTTP/2 e HTTP/3, reutilização de conexões keep-alive para a origem e trânsito pelo backbone que evita a ruidosa internet pública.

Um equívoco comum é que o CloudFront acelera apenas ativos estáticos. Colocar um ALB atrás do CloudFront com uma política CachingDisabled ainda melhora o desempenho de APIs dinâmicas, porque o handshake do visualizador é concluído no PoP local, em vez de atravessar a internet até a Região de origem. Combine isso com uma carga de trabalho mista — por exemplo, /static/* servido a partir do S3 e /api/* servido a partir de um ALB — e uma única distribuição pode lidar com ambos:

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

Os registros alias do Route 53 então apontam www.example.com para o d123.cloudfront.net da distribuição — registros alias são gratuitos e resolvem diretamente para os IPs anycast do CloudFront.

Certificados Ficam em us-east-1

Para qualquer distribuição do CloudFront servida em um domínio personalizado, o certificado TLS voltado para o visualizador no AWS Certificate Manager deve ser emitido em us-east-1 (N. Virginia), independentemente de onde o bucket de origem, o ALB ou os usuários estejam. O CloudFront é um serviço global cujo plano de controle está ancorado em us-east-1; as localizações de borda (edge locations) puxam o certificado dessa Região. Solicitar um certificado ACM em eu-west-1 porque seu bucket S3 está lá é um padrão que não funciona — a distribuição nunca o verá.

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

Se você encerrar o TLS uma segunda vez entre o CloudFront e uma origem de ALB, esse certificado voltado para a origem fica na Região do ALB. Apenas o certificado do visualizador está travado em us-east-1. A mesma regra se aplica a domínios personalizados otimizados para a borda (edge-optimized) do API Gateway (que usam uma distribuição do CloudFront gerenciada pela AWS internamente): o certificado deve estar em us-east-1. Endpoints regionais do API Gateway, em contraste, usam um certificado da própria Região da API.

Origin Access Control para Origens S3

Colocar um bucket S3 atrás do CloudFront e deixar o bucket público anula o propósito: os visualizadores contornam o CloudFront ao acessar o endpoint REST do S3 diretamente, ignorando o WAF, restrições geográficas, URLs assinadas e os benefícios do cache — e potencialmente expondo dados.

A solução moderna é o Origin Access Control (OAC), que substitui o antigo Origin Access Identity (OAI). O OAC usa assinatura SigV4, suporta SSE-KMS, funciona em todas as Regiões do S3 (incluindo as lançadas após 2022) e suporta solicitações dinâmicas. O Bloqueio de Acesso Público (Block Public Access) permanece ativado, não são necessárias ACLs, e a política do bucket concede acesso de leitura apenas ao principal de serviço (service principal) do CloudFront, restringido ainda mais pelo ARN específico da distribuição:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

O OAI ainda funciona, mas deve ser considerado legado — sempre escolha o OAC para novos projetos.

Correção do Cache

A eficácia do cache depende dos cabeçalhos Cache-Control e Expires que a origem retorna, combinados com os TTLs mínimo/padrão/máximo da política de cache do CloudFront. Ativos imutáveis e com fingerprint devem ser cacheados agressivamente; as estruturas HTML que os referenciam devem ter vida curta para que as implantações se propaguem; JSON autenticado não deve ser cacheado de forma alguma no CDN compartilhado:

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

Duas armadilhas simétricas são comuns. Primeiro, se a origem não emite cabeçalhos de cache, o CloudFront recorre ao TTL padrão da distribuição e pode silenciosamente cachear respostas dinâmicas por horas. Segundo, um Cache-Control: no-cache indiscriminado em ativos que deveriam ser cacheados força cada solicitação a voltar para a origem e anula o propósito do CDN.

A armadilha mais perigosa é cachear respostas personalizadas sem os cabeçalhos adequados. Se /account/dashboard retorna um HTML específico para o usuário A, mas a origem omite no-store e a política de cache não inclui um cabeçalho de autenticação ou cookie na chave de cache, a borda servirá alegremente a página do usuário A para o usuário B. Ou marque tais respostas como private, no-store, ou inclua o identificador da sessão na chave de cache e aceite a menor taxa de acerto.

Para um cenário de otimização de custos onde um grupo de Auto Scaling de instâncias EC2 On-Demand serve conteúdo estático, o redesenho correto é mover os ativos para o S3, colocar o CloudFront na frente com OAC e eliminar ou encolher o ASG. Isso desloca o custo de computação por hora para entrega por solicitação, que é ordens de magnitude mais barato para cargas de trabalho estáticas.

URLs Assinadas, Cookies Assinados e Restrição Geográfica

O CloudFront suporta URLs assinadas (acesso com tempo limitado, opcionalmente restrito por IP, a um único objeto — o download de um vídeo comprado, um link único para um PDF) e cookies assinados (acesso a muitos objetos que correspondem a um padrão de caminho — um assinante autenticado navegando em um catálogo). Ambos usam um grupo de chaves confiável (trusted key group) cuja chave pública é carregada no CloudFront; a chave privada assina uma política que especifica a expiração, o intervalo de IPs de origem ou o padrão de URL.

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

Isso é diferente de uma URL pré-assinada (presigned URL) do S3, que contorna o CloudFront e concede acesso direto ao bucket. Combine as URLs assinadas do CloudFront com o OAC e o bucket permanecerá privado de ponta a ponta.

A restrição geográfica (Geo-restriction) impõe listas de permissão (allow-lists) ou de bloqueio (block-lists) no nível do país, na camada da distribuição, antes que as solicitações atinjam o cache ou a origem. Ela usa o banco de dados GeoIP mantido pelo CloudFront e é o mecanismo barato e à prova de desvio de cache para impor embargos de licenciamento. Para uma lógica mais refinada (nível de estado, combinações de cabeçalhos), recorra a uma CloudFront Function ou Lambda@Edge; para um mecanismo de regras completo, use o WAF.

AWS Global Accelerator

O Global Accelerator não é uma CDN e não faz cache. Ele provisiona dois endereços IPv4 anycast estáticos (ou BYOIP) anunciados a partir das localizações de borda (edge locations) da AWS globalmente. As conexões TCP ou UDP do cliente entram no backbone da AWS na borda mais próxima e são roteadas pela rede privada da AWS até o endpoint mais saudável (ALB, NLB, EC2 ou Elastic IP) em uma ou mais Regiões, agrupadas em grupos de endpoints (endpoint groups) com seletores de tráfego (traffic dials) e pesos (weights).

Os IPs estáticos oferecem três benefícios concretos: as listas de permissão (allowlists) de clientes e firewalls nunca mudam, mesmo que o backend seja re-arquitetado; o failover regional é concluído em segundos, deslocando o tráfego entre os grupos de endpoints com base em mudanças nas verificações de saúde (health-checks), evitando completamente a propagação de TTL do DNS; e o handshake TCP termina na borda, com o trecho de longa distância (long haul) sendo executado no backbone da AWS.

Escolha o Global Accelerator quando:

• O protocolo não for HTTP: UDP para jogos ou VoIP, MQTT, SIP, SFTP, TCP personalizado.
• Você precisar de IPs estáticos para listas de permissão corporativas ou aplicativos móveis que codificam endereços de forma fixa (hardcode).
• Você precisar de failover regional em menos de um minuto para implantações ativas-ativas com estado (stateful).
• A carga de trabalho for dinâmica e não armazenável em cache (non-cacheable), de modo que uma CDN oferece pouco valor.

Escolha o CloudFront quando:

• O conteúdo for armazenável em cache (imagens, segmentos de vídeo, HTML estático, respostas de API com TTLs).
• Você quiser computação de borda via Lambda@Edge ou CloudFront Functions.
• Você precisar de WAF, URLs/cookies assinados ou criptografia em nível de campo (field-level encryption) na borda.

Duas armadilhas a serem evitadas. Escolher o CloudFront para “tornar nossos servidores de jogos mais rápidos globalmente” falha porque jogos usam UDP e não são armazenáveis em cache — o Global Accelerator é necessário. Por outro lado, escolher o Global Accelerator para um site estático é caro (taxa fixa por hora mais por GB) e perde os benefícios do cache — o CloudFront reduziria drasticamente a saída de dados (egress) da origem. Para uma API HTTP distribuída globalmente, mas em uma única Região, onde os usuários toleram a latência, o roteamento simples baseado em latência do Route 53 pode ser suficiente e mais barato do que qualquer um dos dois.

Políticas de Roteamento do Route 53 para Tráfego Global

O Route 53 escolhe para qual endpoint um cliente resolve o nome; o CloudFront ou o Global Accelerator então gerenciam a conexão. Três políticas dominam as arquiteturas globais.

Roteamento baseado em latência (Latency-based routing) mede a latência de rede real da localização do resolvedor (resolver) para cada Região e retorna a mais rápida. Use-o para stacks idênticos em várias Regiões, quando você quer que os usuários sejam direcionados para a Região que for mais rápida no momento.

Roteamento por geoproximidade (Geoproximity routing) é baseado em coordenadas em vez de latência: você declara a localização (ou a Região da AWS) de cada endpoint, e o Route 53 envia os usuários para o geograficamente mais próximo. Sua característica distintiva é um valor de bias (viés) (−99 a +99) que expande ou contrai a área de serviço efetiva — útil para deslocar o tráfego gradualmente durante o lançamento de uma Região ou para drenar uma Região para manutenção. O roteamento por geoproximidade requer o Route 53 traffic flow (políticas de tráfego) e é geralmente combinado com um NLB ou ALB regional em cada Região.

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

Roteamento de failover (Failover routing) usa um par primário/secundário vinculado a verificações de saúde (health checks). É um failover no nível do DNS, sujeito ao TTL e ao cache do resolvedor, por isso é mais lento que o failover no plano de dados (data-plane) do Global Accelerator — escolha o roteamento de failover para cenários ativo-passivo simples, onde um minuto de propagação de DNS é tolerável, e o Global Accelerator quando você precisa de segundos.

Essas políticas podem ser combinadas. Um padrão global comum: registros de latência ou geoproximidade do Route 53 apontam para o Global Accelerator (para TCP/UDP) ou para o CloudFront (para HTTPS armazenável em cache), com registros de failover com verificação de saúde por baixo como uma rede de segurança. A sobreposição de camadas é deliberada: o Route 53 escolhe a Região, o Global Accelerator ou o CloudFront escolhe a borda e o caminho através do backbone, e um load balancer regional escolhe o alvo (target) dentro da Região.

Tipos de Endpoint e Domínios Personalizados do API Gateway

O API Gateway oferece três tipos de endpoint com topologias distintas:

Endpoints otimizados para a borda (edge-optimized) envolvem a API em uma distribuição CloudFront gerenciada pela AWS que você não pode configurar diretamente. Isso é conveniente para um alcance global rápido, mas limitador quando você deseja seus próprios comportamentos de cache (cache behaviors), regras de WAF ou políticas de solicitação de origem (origin request policies). O padrão idiomático para controle máximo é um endpoint Regional com uma distribuição CloudFront gerenciada pelo cliente na frente.

A alocação de certificados segue a regra do CloudFront: domínios personalizados otimizados para a borda exigem um certificado ACM em us-east-1; endpoints Regionais exigem o certificado na mesma Região da API. HTTP APIs impõem um mínimo de TLS 1.2; REST APIs suportam políticas de segurança até TLS 1.3.

Certificados ACM: Emitidos, Validados, Importados

O ACM emite e renova automaticamente certificados TLS públicos sem custo e se integra diretamente com CloudFront, API Gateway, ALB, NLB e outros serviços da AWS. A validação é feita por validação de DNS (o ACM fornece um CNAME para ser colocado no Route 53 ou em qualquer provedor de DNS; enquanto o registro persistir, o ACM renova automaticamente para sempre) ou por validação por e-mail (requer um clique manual a cada renovação, frágil para automação). A validação de DNS é o padrão correto para qualquer ambiente de produção.

Certificados emitidos pelo ACM não podem ser exportados e não podem ser usados fora dos serviços integrados da AWS. Quando um requisito regulatório ou de negócio exige uma CA de terceiros específica — por exemplo, uma API REST que deve ter uma cadeia de confiança até um emissor comercial particular e impor o TLS 1.3 — você não pode usar um certificado emitido pelo ACM. Obtenha o certificado da CA exigida e importe-o para o ACM, depois anexe-o a um domínio personalizado do API Gateway Regional com uma política de segurança TLS 1.3.

A armadilha com as importações é dupla: certificados importados não são renovados automaticamente (reimporte antes de expirar ou o endpoint falhará drasticamente), e o ACM não valida a cadeia na importação — um certificado intermediário quebrado só aparecerá no momento do handshake com clientes reais. Teste a cadeia completa com um cliente rigoroso antes da implantação.

S3 Transfer Acceleration vs. CloudFront

O CloudFront otimiza downloads; o S3 Transfer Acceleration otimiza uploads. O Transfer Acceleration usa a mesma rede de borda do CloudFront ao contrário: os PUTs entram na borda mais próxima e percorrem o backbone da AWS até a Região do bucket de destino. Ele se destaca quando um conjunto de usuários globalmente disperso faz upload de objetos grandes para um bucket em uma única Região — por exemplo, engenheiros de campo em todo o mundo fazendo upload de desenhos de vários gigabytes para us-east-1.

Os dois recursos coexistem no mesmo bucket: habilite o Transfer Acceleration e exponha uma distribuição CloudFront com OAC para downloads. Para objetos pequenos ou clientes que já estão perto da Região do bucket, o Transfer Acceleration adiciona custo sem benefício — use a ferramenta de comparação de velocidade do S3 Transfer Acceleration para medir antes de se comprometer. Os clientes devem usar o endpoint s3-accelerate para que a aceleração seja ativada.

AWS WAF para Proteção da Camada 7

O AWS WAF inspeciona requisições HTTP(S) antes que elas cheguem ao recurso protegido. Ele se anexa a distribuições CloudFront, ALBs, estágios do API Gateway, APIs do AppSync, user pools do Cognito, serviços do App Runner e instâncias do Verified Access. Uma web ACL contém regras que correspondem a URI, cabeçalhos, query strings, corpo (até 8 KB por padrão, expansível para 64 KB no ALB/API Gateway), conjuntos de IPs e geolocalização.

Os blocos de construção mais comuns são as AWS Managed Rules: AWSManagedRulesCommonRuleSet e AWSManagedRulesKnownBadInputsRuleSet cobrem os principais exploits do OWASP; AWSManagedRulesSQLiRuleSet e declarações de correspondência de XSS lidam com injeção. Regras personalizadas adicionam correspondência geográfica (listas de permissão/bloqueio de países para conformidade), correspondências de conjuntos de IPs e regras baseadas em taxa (rate-based rules) — que contam as requisições por IP de origem em uma janela contínua de cinco minutos e bloqueiam quando um limite é excedido. As regras baseadas em taxa são a primeira linha de defesa contra inundações HTTP (HTTP floods) e credential stuffing:

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

As regras de Região são importantes. As web ACLs para o CloudFront são globais e devem ser criadas em us-east-1. As web ACLs para recursos Regionais (ALB, API Gateway, etc.) são criadas na própria Região do recurso.

Para proteger um site estático no S3, você não pode anexar o WAF ao bucket — o S3 não é um recurso compatível com o WAF. O padrão correto é CloudFront + OAC na frente do bucket com a web ACL anexada à distribuição. O fato de o bucket ser inacessível, exceto através do CloudFront, é o que torna a inspeção de todo o tráfego verdadeira.

Firewall Manager para Governança de WAF Multi-Contas

Gerenciar o WAF uma conta de cada vez não escala. Em uma Organization, uma equipe pode criar um novo ALB sem anexar a linha de base corporativa, e a postura de conformidade regride silenciosamente. O AWS Firewall Manager resolve isso com políticas para toda a organização aplicadas às contas e recursos no escopo.

Pré-requisitos: AWS Organizations com todos os recursos (all-features) habilitados, uma conta de administrador designada para o Firewall Manager e o AWS Config habilitado em cada conta-membro. Os tipos de política cobrem AWS WAF, AWS Shield Advanced, security groups (auditoria e uso), Network Firewall, Route 53 Resolver DNS Firewall e firewalls de terceiros.

Uma política do WAF pode impor um grupo de regras “primeiro” (avaliado antes das regras da aplicação), um grupo de regras “último” (avaliado depois), ou substituir a web ACL completamente. Novos ALBs ou distribuições CloudFront que correspondem ao escopo do recurso recebem automaticamente o conjunto de regras corporativas, e os recursos não conformes são sinalizados e — dependendo das configurações de remediação — corrigidos automaticamente. Sempre que um cenário mencionar “múltiplas contas”, “gerenciar centralmente” ou “regras de WAF consistentes em toda a organização”, a resposta é o Firewall Manager, e não o WAF por conta.

Shield Standard vs. Shield Advanced

Assumir que o WAF sozinho impede ataques DDoS é um erro crítico. O WAF opera nas requisições que chegam até ele — é excelente contra inundações na camada de aplicação, credential stuffing e assinaturas de exploits conhecidos — mas ataques volumétricos de grande escala nas Camadas 3/4 (SYN floods, reflexão UDP) são absorvidos pelo AWS Shield.

O Shield Standard está ativo por padrão, sem custo. Ele defende automaticamente contra ataques comuns de L3/L4 e se aplica ao CloudFront, Route 53 e Global Accelerator, com proteção básica para ELB, EC2 e outros recursos. Ele não fornece visibilidade específica do ataque, engajamento com o Shield Response Team ou proteção de custos.

O Shield Advanced (US$ 3.000/mês por organização, com um compromisso de um ano) adiciona:

Assumir que o Shield Standard é suficiente para “DDoS em grande escala com proteção de custos e resposta de especialistas” está errado precisamente porque o Standard não possui visibilidade, proteção de custos e acesso ao SRT. Quando a origem é uma instância EC2 atrás de um ELB e o DNS está com um terceiro (de modo que os truques de alias do Route 53 não são uma opção), o padrão recomendado é habilitar o Shield Advanced no ELB e colocar o CloudFront na frente da aplicação (também protegido pelo Shield Advanced) para mover o perímetro de mitigação para a borda e diminuir a superfície de ataque que chega à Região.

A postura correta em camadas é: Shield para ataques volumétricos de L3/L4, WAF para filtragem de L7, CloudFront ou Global Accelerator como o ponto de entrada na borda ao qual ambos os serviços se anexam, e Firewall Manager para aplicar a política em todas as contas.

← Redes e Conectividade · Todos os domínios · Bancos de Dados e Caching →

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

Navegar Amazon →