Obligar a CloudFront a pasar el último archivo HTML de S3

Antecedentes

Estoy alojando un sitio estático en S3, con CloudFront en la parte superior. El problema que tengo es con mis archivos HTML.

De acuerdo con las preguntas frecuentes de CloudFront :

Amazon CloudFront usa estos encabezados de control de caché para determinar con qué frecuencia necesita verificar el origen de una versión actualizada de ese archivo

Lo que he hecho hasta ahora

Con esto en mente, configuré los archivos HTML en mi S3 Bucket para agregar los siguientes encabezados:

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

En mi primera llamada a mi samplefile.htm, veo los siguientes encabezados de respuesta (he excluido los encabezados obvios (por ejemplo Content-Type) para mantener el punto:

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 puede ver, mi Cache-Controlencabezado está allí. El problema es que si actualizo este archivo y actualizo, obtengo el contenido en caché (en lugar del último archivo), y puedo ver que CloudFront está sirviendo su versión en caché mirando los encabezados de respuesta:

X-Cache:Hit from cloudfront

Resumen / pregunta

Con lo anterior en mente, ¿cómo puedo lograr la recuperación automática del último HTML cuando uso CloudFront?

Según sus preguntas frecuentes, debería poder hacer esto con los encabezados Cache-Control, pero parece que no puedo hacer que esto funcione.

Siguiendo las respuestas a continuación

Al final decidí cambiar mi www CNAME para apuntar directamente a mi cubo S3. Luego agregó un nuevo CNAME llamado "estático", que apunta a CloudFront.

Esto significa que HTML es directo desde S3, que luego tiene todas sus referencias CSS / JS / IMG apuntando a static.mydomain.com

En primer lugar, el objetivo de Cloudfront es servir contenido en caché: si intenta servir contenido sin caché desde Cloudfront, es más lento que servirlo directamente desde S3, en casi todos los casos (algo como la transmisión de contenido sería la excepción). Considere por un momento lo que debe suceder para servir contenido de Cloudfront: debe recuperarse del servidor de origen en una ubicación que esté geográficamente cerca del usuario, lo que significa que para una solicitud donde Cloudfront tiene que recuperar contenido del servidor de origen , agrega latencia adicional a la solicitud y el usuario recibe contenido más lentamente. Es solo una vez que el contenido está disponible en la ubicación de borde que las solicitudes posteriores son más rápidas.

El mejor enfoque para este problema es cambiar sus nombres de archivo cuando actualiza una página; esto obligará a Cloudfront a recuperar el nuevo contenido. Nuevamente, tenga en cuenta que Cloudfront generalmente se usa para archivos multimedia (incluidas imágenes) y estilo / javascript, y no tanto para html. Esencialmente, tendría su HTML en S3 y sus imágenes en Cloudfront; con cualquier cambio que realice, puede cambiar el nombre del archivo en Cloudfront (por ejemplo, file-v1.jpg, file-v2.jpg, etc.). Otra forma común es incluir una cadena de consulta con información de versión.

Además, tenga en cuenta que Cloudfront no sirve contenido comprimido, lo que puede dar como resultado una respuesta más lenta que la de un servidor normal (aunque, en su caso, S3 tampoco identifica navegadores compatibles con gzip).

Finalmente, si lo desea, puede usar la invalidación para obligar a Cloudfront a descartar su copia existente y obtener una nueva del servidor de origen. Sin embargo, tenga en cuenta que Cloudfront le brinda solo 1000 invalidaciones gratuitas por mes, después de lo cual el costo es de $ 0.005 / invalidación.

El tiempo más bajo que Cloudfront mantendrá el contenido es 1 hora , aunque el valor predeterminado es 24 horas. Por lo tanto, trataría de establecer la edad máxima en al menos 3600. Considere también un encabezado s-maxage (para contenido compartido, es decir, proxy). Amazon recomienda este tutorial de almacenamiento en caché.

Hubo un problema reciente con esto, rectificado hace unos días.

Creo que las respuestas hasta ahora, aunque correctas en ese momento, ahora están desactualizadas, ya que Cloudfront ahora admite un TTL mínimo de 0, y el intento original del OP de usar cache-age = 0 ahora debería funcionar.

Debería analizar si usará esos otros encabezados de control de caché, en términos de si producirán el resultado que está buscando; es posible que solo necesite la edad máxima. Lo que probablemente quiera es que Cloudfront verifique S3 para ver si el archivo HTML ha cambiado. Si es así, Cloudfront puede buscar y devolver el nuevo archivo. De lo contrario, puede servir al cliente desde su caché existente (conservando el ancho de banda S3 y sirviendo al cliente más rápido y más localmente).

El objetivo de Cloudfront es servir contenido en caché, sí, pero ahora esto incluye contenido que a veces cambia, pero se puede almacenar en caché si no ha cambiado.

Las cadenas de consulta Ps ahora también funcionan con Cloudfront (si configura un 'comportamiento' para el origen relevante, otra característica nueva), sin embargo, algunos servidores proxy aún no pueden almacenar en caché los archivos con cadenas de consulta.

Guía para desarrolladores de Amazon: Caducidad 1

No estoy seguro de cómo CloudFront trata el encabezado como usted, pero si no especifica ningún encabezado, el tiempo predeterminado para actualizar los objetos es de 24 horas.

Una de las cosas que puede hacer para actualizar los objetos es invalidar el contenido. Consulte el siguiente enlace para obtener más información. http://blog.cloudberrylab.com/2010/08/how-to-manage-cloudfront-object.html