Sin encabezado de control de caché para archivos de AWS CloudFront con S3 Origin

Acabamos de migrar a Amazon AWS. Actualmente tenemos una instancia EC2 que funciona bien. Está ejecutando Nginx en el frente y Apache en el back-end. Eso también funciona bien. Todos los sitios se inician correctamente e incluyen el encabezado Cache-Control para los archivos que se sirven desde el EC2.

El problema es con TODOS los archivos estáticos que colocamos en Amazon S3 a los que se accede a través de CloudFront CDN . Podemos acceder bien a los archivos (y no hay problema con CORS), pero aparentemente CloudFront no sirve archivos con el encabezado Cache-Control. Queremos aprovechar el almacenamiento en caché del navegador.

A mi modo de ver, la instancia EC2 no juega un papel aquí ya que los archivos estáticos están siendo atendidos directamente por S3 + CloudFront, la solicitud no va al servidor web en EC2.

Estoy completamente perdido.

Pregunta: 1) ¿Cómo configuro el Cache-Control en este caso? 2) ¿Es posible configurar el control de caché? ¿De S3 o CloudFront?

Nota: Llegué a algunas páginas en Google donde puede configurar el encabezado en S3 para objetos individuales. Esa realmente no es una forma productiva de hacerlo especialmente ya que en mi caso estamos hablando de varios objetos.

¡Gracias!

Llegué a algunas páginas en Google donde puede configurar el encabezado en S3 para objetos individuales. Esa realmente no es una forma productiva de hacerlo especialmente ya que en mi caso estamos hablando de varios objetos.

Bueno, "productivo" o no, así es como está diseñado para funcionar.

CloudFront no agrega Cache-Control: encabezados.

CloudFront pasa (y también respeta, a menos que se configure lo contrario) los Cache-Control:encabezados proporcionados por el servidor de origen, que en este caso es S3.

Para obtener Cache-Control:encabezados proporcionados por S3 cuando se recupera un objeto, se deben proporcionar cuando el objeto se carga en S3, o se agrega a los metadatos del objeto mediante una operación put + copy posterior, que se puede usar para copiar internamente un objeto en sí mismo S3, modificando los metadatos en el proceso. Esto es lo que hace la consola, detrás de escena, si edita metadatos de objetos.

También hay (en caso de que se lo pregunte) ninguna configuración global en S3 para forzar a todos los objetos en un depósito a devolver estos encabezados; es un atributo por objeto.

Actualización: Lambda @ Edge es una nueva característica en CloudFront que le permite disparar disparadores contra solicitudes y / o respuestas, entre el visor y el caché y / o el caché y el origen, ejecutando código escrito en Node.js contra una simple estructura de objeto de solicitud / respuesta expuesto por CloudFront.

Una de las principales aplicaciones para esta función es manipular encabezados ... por lo tanto, aunque lo anterior sigue siendo preciso (CloudFront en sí no agrega Cache-Control), ahora es posible que una función Lambda los agregue a la respuesta que devuelve CloudFront.

Este ejemplo se agrega Cache-Control: public, max-age=86400solo si no hay un Cache-Controlencabezado ya presente en la respuesta.

El uso de este código en un desencadenador de respuesta de origen hará que se active cada vez que CloudFront recupere un objeto del origen y modifique la respuesta antes de que CloudFront lo almacene en caché.

'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;

    if(!response.headers['cache-control'])
    {
        response.headers['cache-control'] = [{ 
            key:   'Cache-Control', 
            value: 'public, max-age=86400' 
        }];
    }

    callback(null, response);
};

Actualización (2018-06-20): Recientemente, envié una solicitud de función al equipo de CloudFront para permitir la configuración de encabezados de respuesta de origen estáticos como atributos de origen, de forma similar a la forma en que se pueden agregar encabezados de solicitud estáticos , ahora ... pero con un twist, permitiendo que cada encabezado se configure para agregarse condicionalmente (solo si el origen no proporcionó ese encabezado en la respuesta) o incondicionalmente (agregar el encabezado y sobrescribir el encabezado desde el origen, si está presente).

Con las solicitudes de funciones, generalmente no recibe ninguna confirmación de si realmente están considerando implementar la nueva función ... o incluso si ya podrían haber estado trabajando en ella ... solo se anuncia cuando están listas. Por lo tanto, no tengo idea si se implementarán. Se debe argumentar que, dado que esta capacidad ya está disponible a través de Lambda @ Edge, no es necesario en la funcionalidad base ... pero mi contraargumento es que la base funcionalmente no está completa de características sin la capacidad de realice una manipulación de encabezado de respuesta estática simple, y que si esta es la única razón por la que se necesita un desencadenante, requerir un desencadenante Lambda es un costo innecesario, financieramente y con latencia adicional (aunque ninguno de los dos es necesariamente un costo extravagante).