Forçando o CloudFront a passar o arquivo HTML mais recente do S3

Question

Antecedentes

Estou hospedando um site estático no S3, com o CloudFront por cima. O problema que tenho é com meus arquivos HTML.

De acordo com Perguntas frequentes do CloudFront :

Amazon CloudFront uses these cache control headers to determine how frequently it needs to check the origin for an updated version of that file

O que eu fiz até agora

Com isso em mente, configurei os arquivos HTML no meu bucket do S3 para adicionar os seguintes cabeçalhos:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: Fri, 01 Jan 1990 00:00:00 GMT

Na minha primeira chamada para o meu samplefile.htm , vejo os seguintes cabeçalhos de resposta (excluímos cabeçalhos óbvios (por exemplo, Content-Type ) para manter o ponto:

Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Date:Sat, 10 Dec 2011 14:16:51 GMT
ETag:"a5890ace30a3e84d9118196c161aeec2"
Expires:Fri, 01 Jan 1990 00:00:00 GMT
Last-Modified:Sat, 10 Dec 2011 14:16:43 GMT
Server:AmazonS3
X-Cache:Miss from cloudfront

Como você pode ver, meu Cache-Control header está lá. O problema é que, se eu atualizar esse arquivo e atualizar, recebo o conteúdo em cache (em vez do arquivo mais recente), e posso ver que o CloudFront está veiculando sua versão em cache observando os cabeçalhos de resposta:

X-Cache:Hit from cloudfront

Resumo / pergunta

Com o acima em mente, como posso obter a recuperação automática do HTML mais recente ao usar o CloudFront?

De acordo com o seu FAQ, eu deveria ser capaz de fazer isso com os cabeçalhos Cache-Control, mas parece que não consigo fazer isso funcionar.

Seguindo as respostas abaixo

No final, decidi alterar meu www CNAME para apontar para o meu bucket S3 diretamente. Em seguida, adicionou um novo CNAME chamado "static", que aponta para o CloudFront.

Isso significa que o HTML é direto do S3, que tem todas as referências CSS / JS / IMG apontando para static.mydomain.com

    

Answer 1

Em primeiro lugar, o objetivo da Cloudfront é veicular conteúdo em cache - se você tentar veicular conteúdo não armazenado em cache do Cloudfront, é mais lento do que veiculá-lo diretamente do S3, em quase todos os casos (algo como streaming de conteúdo seria a exceção). Considere por um momento o que precisa acontecer para veicular conteúdo do Cloudfront - ele precisa ser recuperado do servidor de origem para um local geograficamente próximo ao usuário - o que significa que para uma solicitação em que o Cloudfront precisa recuperar conteúdo do servidor de origem , você adiciona latência extra à solicitação e o usuário recebe o conteúdo mais lentamente. Somente quando o conteúdo estiver disponível no ponto de presença, as solicitações subseqüentes serão mais rápidas.

A melhor abordagem para esse problema é alterar seus nomes de arquivos quando você atualiza uma página - isso forçará a Cloudfront a recuperar o novo conteúdo. Novamente, lembre-se de que o Cloudfront é normalmente usado para arquivos de mídia (incluindo imagens) e style / javascript - e não tanto para html. Essencialmente, você teria seu HTML no S3 e suas imagens no Cloudfront - com todas as alterações feitas, você pode alterar o nome do arquivo no Cloudfront (por exemplo, arquivo-v1.jpg, arquivo-v2.jpg, etc). Outra maneira comum é incluir uma string de consulta com informações de versão.

Além disso, lembre-se de que o Cloudfront não oferece conteúdo gzipado - o que pode resultar em uma resposta mais lenta do que em um servidor regular (embora, no seu caso, o S3 também não identifique navegadores compatíveis com gzip).

Por fim, se você quiser, poderá usar a invalidação para forçar a Cloudfront a descartar sua cópia existente e buscar uma nova no servidor de origem. Observe, no entanto, que a Cloudfront oferece apenas mil invalidações gratuitas por mês, após as quais o custo é de US $ 0,005 / invalidação.

O menor tempo que a Cloudfront manterá o conteúdo é 1hr , embora, o padrão seja 24 horas. Eu, portanto, tentaria definir a idade máxima para pelo menos 3600. Considere também um cabeçalho s-maxage (para compartilhamento - ou seja, conteúdo com proxy). A Amazon recomenda o tutorial de cache .

Houve um problema recente com isso, corrigido há alguns dias

    

Answer 2

Acredito que as respostas até agora, embora corretas no momento, estão desatualizadas, já que a Cloudfront agora suporta um TTL mínimo de 0, e a tentativa original do OP de usar cache-age = 0 agora deve funcionar.

Você gostaria de verificar se deve usar esses outros cabeçalhos de controle de cache, em termos de se eles produzirão o resultado que você está procurando - você pode precisar apenas de max-age. O que você provavelmente quer é que o Cloudfront verifique o S3 para ver se o arquivo HTML foi alterado. Se tiver, o Cloudfront pode buscar e retornar o novo arquivo. Caso contrário, ele poderá servir o cliente a partir de seu cache existente (conservando a largura de banda do S3 e atendendo o cliente com mais rapidez e mais localmente).

O objetivo do Cloudfront é veicular conteúdo em cache, sim, mas agora isso inclui conteúdo que às vezes muda, mas pode ser armazenado em cache se não tiver sido alterado.

p. strings de consulta também funcionam com o Cloudfront agora (se você configurar um 'comportamento' para a origem relevante - outro novo recurso), no entanto, alguns proxies ainda podem falhar ao armazenar em cache quaisquer arquivos com strings de consulta.

Guia do desenvolvedor da Amazon: expiração 1

    

Answer 3

Não tenho certeza de como o CloudFront trata o cabeçalho como o seu, mas, se você não especificar nenhum cabeçalho, o horário padrão para atualizar os objetos será 24 horas.

Uma das coisas que você pode fazer para atualizar os objetos é Invalidar o conteúdo. Confira abaixo o link de mais informações. link