amazon web services - the - Cambie el tamaño de las imágenes sobre la marcha en CloudFront y consígalos en la misma URL al instante: AWS CloudFront-> S3-> Lambda-> CloudFront

como funciona cloudfront

Question

TLDR: tenemos que engañar al caché de redireccionamiento de CloudFront 307 creando un nuevo comportamiento de caché para las respuestas que provienen de nuestra función Lambda.

No vas a creer lo cerca que estamos para lograr esto. Nos hemos pegado tan mal en el último paso.

Caso de negocio:

Nuestra aplicación almacena imágenes en S3 y las sirve con CloudFront para evitar cualquier desaceleración geográfica en todo el mundo. ¡Ahora queremos ser realmente flexibles con el diseño y poder solicitar nuevas dimensiones de imagen directamente en la URL CouldFront! Cada nuevo tamaño de imagen se creará a pedido y luego se almacenará en S3, por lo que la segunda vez que se solicite se servirá muy rápidamente, ya que existirá en S3 y también se almacenará en caché en CloudFront.

Digamos que el usuario ha subido la imagen chucknorris.jpg. Solo la imagen original se almacenará en S3 y se publicará en nuestra página de esta manera:

//xxxxx.cloudfront.net/chucknorris.jpg

Hemos calculado que ahora necesitamos mostrar una miniatura de 200x200 píxeles. Por eso ponemos la imagen src para que esté en nuestra plantilla:

//xxxxx.cloudfront.net/chucknorris-200x200.jpg

Cuando se solicita este nuevo tamaño, los servicios web de Amazon tienen que proporcionarlo sobre la marcha en el mismo cubo y con la clave solicitada. De esta manera, la imagen se cargará directamente en la misma URL de CloudFront.

Hice un dibujo feo con la descripción general de la arquitectura y el flujo de trabajo sobre cómo estamos haciendo esto en AWS:

Aquí es cómo termina Python Lambda:

return {
    ''statusCode'': ''301'',
    ''headers'': {''location'': redirect_url},
    ''body'': ''''
}

El problema:

Si hacemos que la función Lambda redirija a S3, funciona como un encanto. Si redireccionamos a CloudFront, entra en un bucle de redireccionamiento porque CloudFront almacena en caché 307 (así como 301, 302 y 303). Tan pronto como nuestra función Lambda redirige a CloudFront, CloudFront llama a la URL de la escapada de la API en lugar de recuperar la imagen de S3:

Me gustaría crear un nuevo comportamiento de caché en la pestaña de configuración de Behaviors de CloudFront. Este comportamiento no debe almacenar en caché las respuestas de Lambda o S3 (no sé qué es exactamente lo que está sucediendo internamente allí), pero aún así debería guardar en caché cualquier solicitud seguida de esta misma imagen redimensionada. Estoy tratando de establecer un patrón de ruta -/d+x/d+/..+$ , agregar el ARN de la función Lambda en agregar "Asociación de función Lambda" y configurar Origin Response tipo de evento. Junto a eso, estoy configurando el "Predeterminado TTL" en 0 .

Pero no puedo guardar el comportamiento debido a algún error:

¿Estamos en el camino correcto, o la idea de esta "Asociación de Función Lambda" es totalmente diferente?

Answer 1

Estás en el camino correcto ... quizás ... pero hay al menos dos problemas.

La "Asociación de funciones Lambda" que está configurando aquí se llama Lambda @ Edge y aún no está disponible. Los únicos usuarios que pueden acceder a él son los usuarios que han solicitado ser incluidos en la vista previa limitada. El error "maximum allowed is 0" significa que no es un participante de la vista previa. No he visto ningún anuncio relacionado con cuándo estará activo para todas las cuentas.

Pero incluso una vez que esté disponible, no te va a ayudar, aquí, de la forma que esperas, porque no creo que un disparador de Respuesta de Origen te permita hacer nada para activar CloudFront para probar un destino diferente y seguir las redirigir Si ve documentación que contradiga esta afirmación, hágamelo saber.

Sin embargo ... Lambda @ Edge será útil para configurar Cache-Control: no-cache en el 307, por lo que CloudFront no lo almacenará en caché, pero la redirección en sí misma aún tendrá que regresar al navegador.

También tenga en cuenta que Lambda @ Edge solo admite Node, no Python ... así que quizás esto todavía no sea parte de su plan. Realmente no puedo decir, de la pregunta.

Lea acerca de la vista previa limitada de Lambda @ Edge .

El segundo problema:

Estoy tratando de establecer un patrón de ruta -/d+x/d+/..+$

No puedes hacer eso. Los patrones de ruta son coincidencias de cadena que admiten * comodines. No son expresiones regulares. /*-*x*.jpg embargo, podría salirse con /*-*x*.jpg , ya que parece que se admiten varios comodines .

Answer 2

Finalmente pude resolverlo. Aunque esto no es realmente una solución estructural, hace lo que necesitamos.

Primero, gracias a la respuesta de Michael, he usado patrones de ruta para coincidir con todos los tipos de medios. En segundo lugar, la página Comportamiento de la memoria caché fue un poco engañosa para mí: de hecho, la asociación Lambda es para Lambda @ Edge, aunque no vi esto en ninguna parte en todas las informaciones sobre el comportamiento de la memoria caché: todo lo que ves es simplemente Lambda. Esta función no puede ayudarnos, ya que no queremos extender el alcance de nuestro servicio de AWS con Lambda @ Edge solo por ese problema en particular.

Aquí está el enfoque de solución:
He definido varios comportamientos de caché, uno por tipo de medio que admitimos:

Para cada comportamiento de caché, establezco el Default TTL en 0 .

Y la parte más importante: en la función Lambda, agregué un encabezado Cache-Control a las imágenes redimensionadas cuando las puse en S3:

s3_resource.Bucket(BUCKET).put_object(Key=new_key, 
                                      Body=edited_image_obj,
                                      CacheControl=''max-age=12312312'',
                                      ContentType=content_type)

Para validar que todo funciona, veo ahora que la nueva dimensión de imagen se sirve con el encabezado de caché en CloudFront: