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

fundo

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

De acordo com as Perguntas frequentes do CloudFront :

O Amazon CloudFront usa esses cabeçalhos de controle de cache para determinar com que frequência ele precisa verificar a origem de uma versão atualizada desse arquivo

O que eu fiz até agora

Com isso em mente, configurei os arquivos HTML no meu S3 Bucket 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í 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-Controlcabeçalho 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 vejo que o CloudFront está servindo sua versão em cache observando os cabeçalhos de resposta:

X-Cache:Hit from cloudfront

Resumo / pergunta

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

De acordo com as perguntas frequentes, devo conseguir fazer isso com os cabeçalhos de controle de cache, mas não consigo fazer isso funcionar.

Seguindo as respostas abaixo

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

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

Em primeiro lugar, o objetivo do 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 o streaming de conteúdo seria a exceção). Considere por um momento o que precisa acontecer para veicular o 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 precise recuperar o 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 local de borda é que as solicitações subsequentes serão mais rápidas.

A melhor abordagem para esse problema é alterar os nomes dos arquivos quando você atualiza uma página - isso forçará o Cloudfront a recuperar o novo conteúdo. Novamente, lembre-se de que o Cloudfront é normalmente usado para arquivos de mídia (incluindo imagens) e estilo / javascript - e não tanto para html. Essencialmente, você teria seu HTML no S3 e suas imagens no Cloudfront - com todas as alterações que você fizer, poderá 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 exibe conteúdo compactado com gzip - o que pode resultar em uma resposta mais lenta do que em um servidor comum (embora, no seu caso, o S3 também não identifique navegadores compatíveis com gzip).

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

O tempo mais baixo em que o Cloudfront manterá o conteúdo é de 1 hora , embora o padrão seja 24 horas. Portanto, eu tentaria definir a idade máxima para pelo menos 3600. Considere também um cabeçalho s-maxage (para conteúdo compartilhado - por exemplo, proxy). A Amazon recomenda este tutorial de armazenamento em cache.

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

Acredito que as respostas até agora, embora corretas no momento, estejam desatualizadas, já que o 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 examinar 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 da idade máxima. O que você provavelmente deseja é que o Cloudfront verifique o S3 para ver se o arquivo HTML foi alterado. Se houver, o Cloudfront pode buscar e retornar o novo arquivo. Caso contrário, ele pode atender o cliente a partir do cache existente (conservando a largura de banda do S3 e atendendo ao cliente mais rapidamente e localmente).

O objetivo do Cloudfront é servir 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.

As strings de consulta ps também funcionam com o Cloudfront agora (se você configurar um 'comportamento' para a origem relevante - outro novo recurso), no entanto, alguns proxies ainda poderão falhar no cache de arquivos com strings de consulta.

Guia do desenvolvedor da Amazon: Expiração 1

Não sabe como o CloudFront trata o cabeçalho como você possui, mas se você não especificar nenhum cabeçalho, o tempo padrão para atualizar os objetos é de 24 horas.

Uma das coisas que você pode fazer para atualizar os objetos é invalidar o conteúdo. Confira o link abaixo para mais informações. http://blog.cloudberrylab.com/2010/08/how-to-manage-cloudfront-object.html