APRENDER. PRATICAR. EVOLUIR.Identidade da representação
Desenha a chave de cache a partir do que muda o conteúdo. Um factsheet pode variar por idioma e mercado, enquanto um identificador de campanha serve apenas análise. Se a origem escolhe idioma por cookie, enviar esse cookie não basta para separar objetos já guardados: a cache precisa de distinguir a variante. Valores na cache policy entram na chave e seguem para a origem; uma origin request policy pode encaminhar valores adicionais sem fragmentar a cache. Valida também a combinação das políticas: uma block list na origin request policy não remove um valor incluído na chave. No contrato com a aplicação, lista cada dimensão, a razão para a incluir e um par de pedidos que prove a separação pretendida.
Autorização e duração
Uma resposta personalizada não pode ser partilhada só porque o primeiro pedido passou autenticação. Se Authorization chega apenas à origem, um hit pode evitar esse controlo. Quando o requisito exige autorização na origem em cada acesso, desativa cache no comportamento correspondente. Para outras estratégias, identidade, revogação e tempo de vida precisam de desenho próprio. Minimum TTL positivo pode impor cache apesar de private, no-store ou no-cache. Por outro lado, mínimo zero não significa cache desligada se default e máximo continuam positivos. Revê a política efetiva, os headers da origem e a ordem de comportamentos. Um padrão geral antes de um restritivo pode absorver o pedido e aplicar regras de acesso diferentes das que a equipa esperava.
Origem privada e transporte
Para uma origem S3 regular, OAC com always sign associa assinatura e o comportamento documentado de HTTPS até S3. A autorização continua a exigir bucket policy com âmbito da distribuição; objetos SSE-KMS também exigem permissões adequadas na key policy. Não uses uma permissão ampla como substituto de investigar qual dos controlos está em falta. Um website endpoint S3 é custom origin e não suporta OAC nem OAI: migrar exige rever também as funcionalidades de website usadas. Numa origem HTTPS customizada, valida nome esperado, certificado e cadeia. Um certificado dentro da validade para outro nome não resolve o contrato de identidade. Mantém separado o segmento viewer-CloudFront do segmento CloudFront-origem ao recolher evidência de cifragem.
Failover com âmbito definido
Um origin group não representa recuperação universal da aplicação. No modo Default, um miss começa no primário, mesmo depois de outro pedido ter recorrido ao secundário. Os critérios de status, falha de ligação, timeouts e métodos elegíveis determinam a tentativa seguinte. POST não recebe este failover automático; GET bem-sucedido não prova resiliência das escritas. OPTIONS também exige a configuração de cached methods documentada. Define o teste pelo método real e pelo resultado funcional: confirmação de instrução, leitura da versão correta ou recuperação de um ficheiro. Para escritas com timeout, considera processamento parcial e idempotência antes de repetir. O relatório deve explicar quais as operações demonstradas e quais precisam de uma estratégia adicional de recuperação.
Erros que sobrevivem à correção
Depois de corrigir um objeto ausente, o viewer pode continuar a receber um erro guardado. Compara a origem atual com o caminho de cache e o Error Caching Minimum TTL relevante. Um header de duração numa resposta de erro pode aumentar a retenção até ao limite aplicável; os valores não são somados. Há exceções: 416 não é guardado, e uma origem S3 com cache ativa mantém um mínimo de um segundo mesmo quando o mínimo de erro foi configurado a zero. Não transformes uma regra específica num princípio para todos os códigos. O operador deve registar status, URL, headers e instante, para distinguir recuperação da origem, expiração de cache e uma falha que ainda continua ativa.
Atualizar e aceitar uma release
Um GET do viewer com Cache-Control ou Pragma no-cache não força CloudFront a consultar a origem. Define uma estratégia de atualização por versões ou invalidação e verifica o conteúdo recebido. Se a chave distingue query strings, enumera as variantes ou usa um wildcard final com âmbito revisto. Caminhos distinguem maiúsculas, e um wildcard mal colocado pode ser literal. A invalidação não pode ser cancelada após submissão; avalia carga de misses e capacidade da origem antes de a iniciar. Para um incidente de conteúdo personalizado, corrigir a política e retirar entradas afetadas são passos complementares. Usa dados fictícios, duas identidades e testes negativos na aceitação, preservando evidência suficiente sem registar tokens ou extratos reais.
def cache_key(path, request, dimensions):
return path, tuple((name, request.get(name)) for name in dimensions)
pt = {"language": "pt", "campaign": "a"}
en = {"language": "en", "campaign": "a"}
assert cache_key("/factsheet", pt, []) == cache_key("/factsheet", en, [])
assert cache_key("/factsheet", pt, ["language"]) != cache_key("/factsheet", en, ["language"])
assert cache_key("/factsheet", pt, ["language"]) == cache_key("/factsheet", {**pt, "campaign": "b"}, ["language"])
assert cache_key("/factsheet", pt, ["language"]) != cache_key("/prices", pt, ["language"])
assert cache_key("/factsheet", pt, ["language", "campaign"]) != cache_key("/factsheet", {**pt, "campaign": "b"}, ["language", "campaign"])
print("five key checks passed; no real content cached or authorized")
Dois pedidos para /factsheet com language=pt e language=en devem produzir variantes distintas; uma campanha diferente não deve criar variante se não altera o documento.
Armadilhas comuns
Confundir forwarding com chave; assumir que no-store vence um mínimo positivo; tratar GET recuperado como DR completo.
Tópicos relacionados: Identidade e TLS · Release e rollback
Desenha cache, autorização, transporte e recuperação como contratos verificáveis em cada caminho.
Referência: Control the cache key · ANS-C01