delete create control cloudfront cache aws amazon-web-services cdn amazon-cloudfront

amazon web services - create - ¿Para qué sirve TTL 0 en CloudFront?



delete cloudfront cache (3)

CloudFront se puede usar en combinación con el administrador de certificados para agregar compatibilidad con HTTPS a los sitios web de S3. Es posible que desee esto, pero caché cero.

Hace algunas semanas, Amazon anunció que había bajado el período de caducidad del contenido:

Amazon CloudFront reduce el período de caducidad del contenido mínimo

Tanto que realmente puede establecer ahora TTL en CloudFront en 0. Entonces mi pregunta es, ¿por qué podría ser útil tener una distribución de CloudFront con TTL establecido en 0. Para mí esto significa que no hay almacenamiento en caché, por lo que cada solicitud que llegue a CloudFront terminará golpeando el origen.

¿Qué me estoy perdiendo?


Esta nueva característica de Amazon CloudFront es realmente muy útil para muchos casos de uso, porque tocar el origen funciona de una manera un poco diferente de lo que parece a primera vista y no es necesariamente un problema, por el contrario; si bien esta característica ya se lanzó anteriormente, todo se combina con la reciente versión de Amazon CloudFront - Soporte para contenido dinámico , por ejemplo, para la pregunta en cuestión:

Tiempo variable de vida (TTL) : en muchos casos, el contenido dinámico no se puede almacenar en la memoria caché o en caché durante un período de tiempo muy corto, tal vez de unos pocos segundos. En el pasado, el TTL mínimo de CloudFront era de 60 minutos, ya que todo el contenido se consideraba estático. El nuevo valor mínimo de TTL es 0 segundos. Si configura el TTL para un origen particular en 0, CloudFront aún almacenará en caché el contenido de ese origen. Luego hará una solicitud GET con un encabezado If-Modified-Since , dando así al origen la oportunidad de señalar que CloudFront puede seguir utilizando el contenido en caché si no ha cambiado en el origen . [énfasis mío]

En otras palabras, usar un TTL de 0 significa principalmente que CloudFront delega la autoridad para el control de la memoria caché en el origen, es decir, el servidor de origen decide si desea o no, y si durante cuánto tiempo CloudFront almacena en caché los objetos; tenga en cuenta específicamente que una solicitud GET con un encabezado If-Modified-Since no significa necesariamente que el objeto se recupera del origen, sino que el origen puede (y debe) devolver el código de estado HTTP 304 - No modificado donde corresponda :

Indica que el recurso no ha sido modificado desde la última solicitud. [...] El uso de esto ahorra ancho de banda y reprocesamiento tanto en el servidor como en el cliente, ya que solo los datos del encabezado deben enviarse y recibirse en comparación con la totalidad de la página que el servidor vuelve a procesar, y luego se envía de nuevo usando más ancho de banda del servidor y el cliente [énfasis mío]

Consulte el excelente tutorial de caché de Mark Nottingham para obtener detalles sobre la mecánica y los beneficios del control de caché HTTP, una parte realmente importante y efectiva de la arquitectura HTTP.

Entender cómo todas estas partes funcionan juntas puede ser un poco difícil, según la tabla de la sección Especificar el tiempo mínimo que CloudFront almacena en caché los objetos para Distribuciones de descarga dentro de Especificar cuánto tiempo permanecen los objetos en una caché de borde de CloudFront (Expiración de objetos) intenta resumir los efectos cuando se aplica en el contexto de CloudFront con o sin TTL = 0 específicamente.


Tenga en cuenta que Amazon no dice "TTL es 0", sino que dice "TTL mínimo es 0". y eso es muy diferente. La descripción anterior es muy deseable, pero no hay garantía de que Cloudfront realmente lo haga.

En mis experiencias en este momento, puedo ver una imagen almacenada en caché durante unos minutos en el borde, mientras que mi origen ya ha cambiado.

Por lo tanto, creo que decir "TTL mínimo es 0" es probablemente más parecido a "Amazon no tiene la intención estricta de mantener esto en un caché", y tal vez "y se volverá a buscar con frecuencia".

Para aplicaciones como CMS, donde el usuario de la web está publicando contenido nuevo, creo que TTL-0 aún no es suficiente. Aún debe invocar invalidaciones del CMS o emplear rutas diferentes para diferentes números de versión.