APRENDER. PRATICAR. EVOLUIR.Descrever o que torna uma resposta diferente
Uma cache key identifica representações que podem ser reutilizadas. Numa página pública que varia pelo idioma, o idioma relevante precisa de separar as representações em cache. Encaminhar um cabeçalho à origem não o inclui automaticamente na chave: o origin request policy e o cache policy têm funções diferentes. Nos hits, a origem pode nem ser consultada. Desenha dois pedidos com o mesmo path e valores diferentes; se a resposta deve mudar, confirma como a chave ou o desenho sem cache respeita essa diferença.
Tratar conteúdo pessoal antes de otimizar hits
Num portal fictício, /extrato devolve dados diferentes conforme a sessão. Retirar o cookie da chave para aumentar hits pode fazer reutilizar um extrato noutra sessão. Encaminhar o cookie apenas nos misses não resolve o hit já existente. Para estes exercícios, impede cache partilhada de extratos pessoais e revê autorização. Se houve exposição, considera também cópias existentes e alcance do incidente. Uma arquitetura que opte por cache privada exige demonstração própria de autorização e isolamento; não resulta de acrescentar apenas um cabeçalho.
Ler o mínimo TTL da política
Com minimum TTL superior a zero, CloudFront pode manter conteúdo durante esse mínimo mesmo quando a origem envia Cache-Control: no-cache, no-store ou private. Por isso, uma revisão precisa de examinar o behavior e a política efetiva, não apenas os cabeçalhos observados na origem. No cenário com minimum TTL=60, repetir no-store não remove esse mínimo. Para impedir a cache do conteúdo em causa, aplica uma configuração adequada e verifica o caminho real. Uma mudança de política também não apaga dados que já tenham sido expostos a um cliente.
Separar acesso do viewer e acesso à origem
OAC trata o caminho CloudFront para S3 com as permissões adequadas. Não autentica automaticamente cada viewer. URLs ou cookies assinados podem controlar a entrega pela distribuição, mas um bucket público continua a oferecer um caminho direto. Define as duas fronteiras e ensaia acesso autorizado, viewer sem autorização e acesso direto à origem. OAC não suporta S3 website endpoints; estes são origens personalizadas. Se a aplicação depende de funcionalidades de website hosting, avalia essa dependência ao mudar para uma origem S3 compatível.
Atualizar conteúdo sem prometer simultaneidade
Substituir um objeto na origem não invalida automaticamente uma cópia CloudFront ainda válida. Para publicar uma correção, considera invalidar os paths necessários ou usar nomes versionados e atualizar referências. Com nomes versionados, uma página que ainda referencia o nome antigo continua a pedi-lo. Com invalidação, considera propagação e caches adicionais, incluindo browsers. No plano de release, define como observar a versão entregue e recuperar de referências inconsistentes. O exercício não assume que todos os clientes mudam de versão no mesmo instante.
Calcular eficiência com as premissas à vista
Num exemplo público, 100 paths e dois idiomas dão 200 combinações. Acrescentar 1000 identificadores de sessão irrelevantes pode produzir 200000 chaves possíveis, se todas as combinações existirem. Isso é cardinalidade potencial, não ocupação garantida. Noutro modelo, 10000 pedidos com 9000 hits fazem 1000 consultas à origem; 9500 hits deixam 500 consultas, uma redução de 50%. A conta assume um pedido à origem por miss, sem revalidação nem retries. Nunca removas uma dimensão que realmente separa dados pessoais só para melhorar esta métrica.
100 paths × 2 idiomas × 1000 IDs irrelevantes = 200000 combinações potenciais; sem os IDs são 200.
Armadilhas comuns
Confundir forwarding com chave, no-store com garantia absoluta, OAC com login ou atualização na origem com invalidação.
Tópicos relacionados: Segurança de dados · Entrega de conteúdo e custos
Otimiza a reutilização apenas depois de garantir que a resposta certa chega ao utilizador autorizado.
Referência: CloudFront cache policies · SAA-C03