Amazon CloudFront é a CDN da AWS para distribuir conteúdo com baixa latência globalmente; frequentemente usada com S3 como origem.

🎯 Para a certificação

Questões sobre CloudFront cobrem padrões de origem (S3/ALB), comportamento de cache, invalidações, distribuição de conteúdo privado (Signed URLs/Cookies), failover de origem e customização de requisições na borda (Lambda@Edge/CloudFront Functions).

---

Resumo

Imagine uma rede de padarias franqueadas em cada bairro de uma cidade, todas vendendo o mesmo pão da matriz. Sem elas, todo cliente teria que ir até a fábrica central para comprar pão — trajeto longo, fila enorme. Com as filiais, o pão "mais pedido" já fica pronto perto de cada cliente, e só quando algo muito específico não está disponível na filial é que alguém precisa ir até a fábrica buscar.

CloudFront é essa rede de filiais para conteúdo digital: uma CDN (Content Delivery Network) com centenas de edge locations espalhadas pelo mundo, que guardam cópias em cache do seu conteúdo perto de cada usuário — reduzindo drasticamente a latência, comparado a todo mundo buscar direto na origem (seu bucket S3, seu servidor, sua API).

• Edge Locations: os pontos de presença físicos ao redor do mundo onde o CloudFront guarda cache e atende requisições.
• Origem: de onde o conteúdo "de verdade" vem (S3, ALB, EC2, qualquer servidor HTTP).
• TTL: por quanto tempo o CloudFront pode responder do cache sem perguntar de novo à origem.
• Invalidação: forçar o CloudFront a descartar uma cópia em cache antes do TTL expirar.

---

1. Por que uma CDN reduz latência

Sem CDN, toda requisição de um usuário no Japão para um site hospedado nos EUA precisa atravessar o mundo fisicamente — o tempo de ida e volta (RTT) é dominado pela distância. Com CloudFront, a primeira requisição de uma edge location ainda busca na origem, mas fica em cache lá — as requisições seguintes de usuários próximos daquela edge location são atendidas localmente, sem cruzar o planeta.

---

2. Anatomia de uma Distribution

Uma distribution do CloudFront é composta por peças que se conectam assim:

Cliente → Edge Location → Behavior (regra de path) → Cache Policy → Origin

• Origin: a fonte real do conteúdo — pode ser um bucket S3, um ALB, uma instância EC2, ou qualquer servidor HTTP acessível. Uma distribution pode ter múltiplas origens.
• Behavior: uma regra que diz "para requisições que casam com este padrão de path (ex: /api/*), use esta origem e esta cache policy" — permite que a mesma distribution sirva conteúdo estático de um S3 e conteúdo dinâmico de uma API, com regras diferentes para cada um.
• Cache Policy: define o que compõe a "chave de cache" — quais headers, cookies e query strings o CloudFront deve considerar ao decidir se duas requisições são "a mesma coisa" (e por isso podem compartilhar a mesma resposta em cache) ou coisas diferentes.
• Origin Request Policy: define o que é encaminhado para a origem quando o CloudFront precisa buscar algo (nem tudo que chega do cliente precisa necessariamente ir até a origem).

💡 Separar Cache Policy de Origin Request Policy é a arquitetura mais moderna do CloudFront (substituindo o modelo antigo de configurar TTL/forwarding tudo junto no behavior) — permite, por exemplo, cachear ignorando um header, mas ainda encaminhar esse header para a origem quando necessário.

---

3. TTLs e invalidações

• TTL curto acelera atualizações, mas aumenta o número de vezes que o CloudFront precisa perguntar à origem (origin hits) — mais custo e carga na origem.
• TTL longo reduz custo e carga, mas atrasa a propagação de mudanças.
• Invalidação (Invalidation) remove objetos do cache imediatamente em todas as edge locations, mas tem custo quando ultrapassa a cota gratuita mensal — para arquivos que mudam com frequência, geralmente é mais barato usar cache-busting (mudar o nome/versão do arquivo, ex: app.v2.js) do que invalidar toda vez.

Explicação didática: o TTL é basicamente "por quanto tempo o CloudFront pode responder sem perguntar de novo à origem". Se você definir TTL de 1 hora para app.js, uma alteração no S3 só chega aos usuários depois de até 1 hora (ou até você invalidar manualmente). Invalidação força o CloudFront a esquecer a cópia antiga imediatamente.

💡 Regra de prova: "atualizações frequentes de conteúdo estático, minimizando custo" → cache-busting (versionar nome do arquivo), não invalidação massiva repetida.

---

4. Distribuindo conteúdo privado: Signed URLs e Signed Cookies

Por padrão, qualquer objeto servido por uma distribution é acessível a quem tiver a URL. Quando você precisa restringir acesso (ex: vídeos de um curso pago, documentos privados), o CloudFront oferece dois mecanismos, usando um par de chaves (uma chave privada assina, o CloudFront verifica com a chave pública associada):

• Signed URL: cada URL gerada é válida só até uma data de expiração configurada (e pode ter restrições de IP). Ideal para dar acesso a um único arquivo por vez, ou quando o cliente que consome não suporta cookies (ex: um player de vídeo embutido chamando URLs diretas).
• Signed Cookie: em vez de assinar cada URL individualmente, você gera um cookie assinado que dá acesso a múltiplos arquivos (ex: todos os vídeos de um curso) sem precisar assinar URL por URL. Ideal quando o usuário vai acessar vários recursos protegidos numa mesma sessão de navegador.

💡 Regra para a prova: "acesso a um arquivo específico, com expiração, sem depender de cookie" → Signed URL. "acesso a múltiplos arquivos/pastas numa mesma sessão de navegador" → Signed Cookie.

---

5. Protegendo a origem: OAI e OAC

Quando a origem é um bucket S3, você normalmente não quer que o bucket seja acessível diretamente pela Internet — só através do CloudFront (para forçar todo o tráfego a passar pelas regras de cache, segurança e possivelmente Signed URLs).

• Origin Access Identity (OAI): mecanismo mais antigo — uma identidade especial que o CloudFront usa para se autenticar no S3, permitindo que a bucket policy conceda acesso só a essa identidade.
• Origin Access Control (OAC): substituto mais moderno e recomendado do OAI, com suporte mais completo (ex: funciona com todos os métodos de assinatura SigV4, incluindo PUT/DELETE, não só leitura).

Nos dois casos, o bucket S3 permanece privado — só o CloudFront (autenticado via OAI/OAC) consegue ler os objetos diretamente.

---

6. Origin Failover (Origin Groups)

Para alta disponibilidade, o CloudFront permite configurar um Origin Group: uma origem primária e uma secundária. Se a origem primária retornar um erro configurado (ex: 5xx), o CloudFront tenta automaticamente a origem secundária — sem o cliente perceber a troca.

Uso típico: origem primária num bucket S3 numa região, secundária num bucket S3 réplica em outra região (via replicação entre buckets), garantindo que uma falha regional não derrube o site.

---

7. Customizando requisições na borda: Lambda@Edge e CloudFront Functions

Às vezes você precisa manipular a requisição ou a resposta antes dela seguir seu caminho normal — sem envolver a origem. O CloudFront tem dois mecanismos, com propósitos e limites diferentes:

• CloudFront Functions: para lógica leve e de altíssima performance (sub-milissegundo), escrita em JavaScript, executada em qualquer edge location — ex: reescrever uma URL, normalizar headers, redirecionar com base num cookie simples. Ideal para volume altíssimo de requisições com lógica simples.
• Lambda@Edge: para lógica mais pesada (acesso a rede externa, mais tempo de execução, mais linguagens suportadas), executada num subconjunto menor de edge locations (regional edge caches) — ex: personalizar conteúdo com base em chamada a outro serviço, manipulação mais complexa de A/B testing, geração de imagem sob demanda.

Ambos podem atuar em 4 pontos do ciclo de vida da requisição: viewer request (chega do cliente), origin request (vai para a origem), origin response (volta da origem), viewer response (vai de volta pro cliente).

💡 Regra para a prova: "lógica simples, altíssimo volume, baixíssima latência" → CloudFront Functions. "lógica mais complexa, precisa de mais recursos/tempo" → Lambda@Edge.

---

8. Geo-restriction

Permite bloquear ou permitir acesso ao conteúdo da distribution com base no país de origem da requisição (allowlist ou denylist), sem precisar de lógica customizada — útil para restrições de licenciamento de conteúdo por região, ou conformidade regulatória simples. É uma configuração nativa da distribution, diferente do Geolocation routing do Route 53 (que decide para onde uma consulta DNS aponta, não se o acesso é permitido).

---

9. HTTPS e políticas de protocolo

• Viewer Protocol Policy: controla como o CloudFront trata requisições do cliente — permitir só HTTPS, permitir HTTP e HTTPS, ou redirecionar HTTP para HTTPS automaticamente.
• Origin Protocol Policy: controla como o CloudFront se comunica com a origem — HTTP, HTTPS, ou "match viewer" (usa o mesmo protocolo que o cliente usou).
• Certificados TLS são gerenciados via ACM (deve estar na região us-east-1 para uso com CloudFront, independente de onde a origem está).

---

10. Price Classes

Permite restringir quais edge locations são usadas para servir sua distribution, como forma de controlar custo — por exemplo, "Price Class 100" usa só edge locations em regiões mais baratas (América do Norte e Europa), deixando de usar as mais caras (ex: parte da Ásia/Oceania/América do Sul). Trade-off: menor custo, mas usuários fora das regiões escolhidas terão latência maior (indo até uma edge location mais distante ou até a origem).

---

11. Integração com WAF

Assim como o ALB, o CloudFront pode ser protegido por AWS WAF, filtrando requisições maliciosas (SQL injection, XSS, regras de rate limiting) na borda, antes mesmo delas chegarem perto da origem ou do restante da infraestrutura.

---

12. Origin Shield

Uma camada adicional e opcional de cache regional, posicionada entre as edge locations e a origem. Quando múltiplas edge locations pedem o mesmo objeto que não está em cache, sem Origin Shield cada uma bateria na origem separadamente; com Origin Shield, essas requisições convergem para um único ponto regional antes de ir à origem, reduzindo a carga origin-side em cenários de tráfego global intenso.

---

13. Boas práticas

• Prefira versionamento de nomes de objetos em vez de invalidações massivas repetidas.
• Configure Cache-Control na origem e cache policies específicas por behavior/path.
• Use Origin Shield quando a origem estiver sobrecarregada por múltiplas edge locations pedindo o mesmo conteúdo.
• Use OAC (não OAI) para novos projetos que restringem acesso direto ao S3.
• Use Signed Cookies para sessões de acesso a múltiplos arquivos privados; Signed URLs para acesso pontual.
• Prefira CloudFront Functions a Lambda@Edge quando a lógica for simples — menor custo e latência.

---

14. Como cai na certificação

• Cenário "atualizações frequentes de conteúdo estático, minimizar custo" → cache-busting, não invalidação massiva.
• Cenário "proteger origem S3 para que só o CloudFront acesse" → OAC (ou OAI legado).
• Cenário "reduzir chamadas repetidas à origem em picos globais" → Origin Shield.
• Cenário "conteúdo privado, um único arquivo, com expiração" → Signed URL.
• Cenário "conteúdo privado, múltiplos arquivos, mesma sessão" → Signed Cookie.
• Cenário "alta disponibilidade caso a origem principal falhe" → Origin Group (failover).
• Cenário "lógica simples e de altíssimo volume na borda" → CloudFront Functions; "lógica mais pesada" → Lambda@Edge.
• Cenário "bloquear acesso por país por licenciamento" → Geo-restriction (não confundir com Route 53 Geolocation).
• Cenário "reduzir custo aceitando latência maior em certas regiões" → Price Class.

---

15. Exercícios práticos conceituais

1. Explique como projetar a distribuição CloudFront para um site estático com deploys frequentes minimizando custo.
2. Compare invalidation vs cache-busting e proponha quando usar cada um.
3. Desenhe uma estratégia de TTL para assets estáticos e assets com atualização diária.
4. Avalie benefícios de usar Origin Shield em frente à origem S3.
5. Descreva um cenário de conteúdo privado onde Signed Cookie é claramente melhor que Signed URL, e outro onde é o oposto.
6. Explique quando escolher CloudFront Functions em vez de Lambda@Edge, com um exemplo de cada.
7. Desenhe uma arquitetura de origin failover entre duas regiões para um site estático hospedado em S3.

---

16. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Laboratório Prático

Objetivo: criar uma distribution CloudFront com S3 protegido via OAC, testar cache-busting, e configurar uma Signed URL para um objeto privado.

Pré-requisitos: um bucket S3 com pelo menos dois objetos de teste (um público, um que será restrito).

Tempo estimado: 30 minutos

Possíveis custos: praticamente nulo para poucas requisições de teste; atenção a cobrança se gerar muitas invalidações.

Passos:

1. Crie uma distribution CloudFront com origem no bucket S3, usando Origin Access Control (OAC) — a distribution deve atualizar automaticamente a bucket policy para permitir acesso só via CloudFront.
2. Tente acessar um objeto diretamente pela URL do S3 — deve falhar (acesso negado). Acesse o mesmo objeto pela URL do CloudFront — deve funcionar.
3. Faça upload de um app.js de teste, acesse via CloudFront, depois modifique o conteúdo no S3 e acesse de novo sem esperar o TTL — observe que ainda vem a versão antiga (cache).
4. Renomeie o objeto para app.v2.js, faça upload, e atualize a referência — confirme que a nova versão aparece imediatamente, sem invalidação.
5. Configure um par de chaves para assinatura e gere uma Signed URL com expiração de 5 minutos para o segundo objeto (marcado como restrito via behavior "Restrict Viewer Access").
6. Acesse o objeto restrito sem a assinatura — deve falhar. Acesse com a Signed URL gerada — deve funcionar até expirar.

Resultado esperado: o bucket permanece privado, o cache-busting evita invalidação, e o acesso restrito só funciona com a URL assinada dentro da janela de validade.

Limpeza dos recursos: desative e delete a distribution CloudFront, remova o par de chaves de assinatura, e esvazie/delete o bucket S3 de teste.

---

Referências:

• CloudFront Developer Guide: https://docs.aws.amazon.com/cloudfront/
• Hospedagem de site estático com CloudFront: https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-working-with-cloudfront.html
• Signed URLs e Signed Cookies: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
• Lambda@Edge: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html
• CloudFront Functions: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html