Lambda que redimensiona imágenes con Sharp

Generar miniaturas de imágenes de forma automática es uno de los casos de uso más útiles de AWS Lambda con eventos de S3. Aquí aprendes a configurar una función serverless que detecta cargas en un bucket, redimensiona la imagen en múltiples tamaños y devuelve los resultados listos para producción, todo de forma asíncrona.

Este flujo es ideal si trabajas con front-ends que necesitan compatibilidad entre dispositivos: televisor, computador y teléfono no comparten medidas, y tus imágenes tampoco deberían.

Qué hace una Lambda activada por eventos de S3

La idea es simple: cada vez que un usuario sube una imagen a la carpeta uploads del bucket, se dispara una función Lambda que procesa la imagen en segundo plano y guarda versiones redimensionadas en otra carpeta del mismo bucket.

A diferencia de las Lambdas que respondían a API Gateway, esta no expone un endpoint HTTP. Su disparador es un evento nativo de S3, específicamente del tipo object created [01:30].

¿Qué es un evento de S3 en Lambda? Es una notificación que S3 envía automáticamente cuando ocurre una acción sobre un objeto, por ejemplo crearlo o eliminarlo. Lambda escucha ese evento y ejecuta el código asociado.

Cómo se estructura el handler del thumbnail generator

El handler tiene dos funciones principales: thumbnailGenerator, que actúa como punto de entrada, y resizer, que hace el trabajo pesado [01:50].

En la parte superior se importan tres piezas clave:

• El AWS SDK para conectarse a los servicios de Amazon.
• Una librería utilitaria interna del proyecto.
• Sharp, librería externa que ejecuta el resizing de imágenes.

También se define un cliente de S3, que servirá tanto para descargar la imagen original como para subir las versiones procesadas.

Qué hace la función resizer

El resizer recibe el body de la imagen, el nuevo tamaño, el bucket destino y el fileKey con la ruta completa. Internamente hace un split del fileKey para extraer el nombre del archivo, usa Sharp para generar un buffer redimensionado y luego ejecuta putObject para subir esa nueva imagen al bucket [02:40].

Qué hace la función thumbnailGenerator

Esta función inspecciona el evento entrante, identifica el sourceBucket y la key del objeto, valida que la extensión sea JPG o PNG, descarga la imagen con getObject y finalmente llama al resizer por cada tamaño definido en un array [03:50].

¿Por qué generar varios tamaños de la misma imagen? Porque una pantalla de TV, una de laptop y una de móvil tienen resoluciones distintas. Servir la imagen correcta para cada dispositivo mejora la velocidad de carga y la experiencia de usuario.

Cómo configurar el evento de S3 en Serverless Framework

En el archivo serverless.yml se declara una nueva función llamada thumbGenerator. En lugar de un evento http, se usa un evento s3 con estos atributos clave [05:30]:

• bucket: el nombre del bucket existente.
• event: el tipo, en este caso s3:ObjectCreated:*.
• rules: filtros como prefix: uploads/ para limitar el disparo a una carpeta específica.
• existing: true: indica que el bucket ya existe y no debe crearse uno nuevo.

Este último flag es esencial. Sin él, Serverless intentaría crear un bucket nuevo y romper la integración con el que ya tienes desplegado.

Cómo manejar dependencias externas como Sharp

Sharp no viene incluida en el runtime de Lambda, así que hay que instalarla como dependencia de producción con npm install --save sharp [07:10].

Aquí aparece un detalle crítico relacionado con la arquitectura del procesador. Si trabajas en un Mac con chip M1, npm instala una versión de Sharp para darwin-arm64, que no es compatible con el runtime de AWS Lambda.

La solución es forzar la instalación con flags específicos:

• Especificar --arch=x64 para la arquitectura.
• Especificar --platform=linux para el sistema operativo.
• Borrar node_modules antes de reinstalar para evitar caches viejas.

¿Por qué falla Sharp en Lambda si lo instalo desde Mac M1? Porque Lambda corre en Linux x64 y Sharp incluye binarios nativos compilados para la arquitectura donde lo instalaste. Necesitas instalarlo apuntando explícitamente a Linux x64.

Por qué incluir node_modules en el package

Por defecto, Serverless solo empaqueta el handler. Para que Sharp llegue a la nube hay que añadir un patrón adicional en la configuración de package, incluyendo node_modules/** [09:20].

Esto hace que el bundle final pese alrededor de 8.4 MB, suficiente para que AWS deje de mostrar el editor de código en la consola, ya que supera los 3 MB.

Cómo se ve el resultado en el bucket

Después de ejecutar sls deploy, en la sección de event notifications del bucket aparece la notificación creada automáticamente por Serverless Framework, con su tipo, filtro y Lambda asociada [11:40].

Al subir una imagen a la carpeta uploads/, la Lambda se dispara y genera una carpeta resized/ en la raíz del bucket con tres versiones del archivo:

• 50x50 píxeles.
• 100x100 píxeles.
• 200x200 píxeles.

Si el filtro apunta a uploads/ con barra final y subes la imagen a la raíz, no pasa nada. Crear la carpeta correcta resuelve el problema y confirma que el filtrado por prefijo funciona como esperabas.

Por qué empaquetar node_modules no es la mejor estrategia

Incluir todas las dependencias dentro del zip de la Lambda funciona, pero escala mal. Si tu proyecto crece con varios clientes, librerías y subdependencias, cada función se vuelve pesada y lenta de desplegar.

La alternativa son las Lambda layers, una capa separada donde alojas las dependencias y las compartes entre múltiples funciones. El código queda en la Lambda, las librerías en la layer, y el deploy se vuelve mucho más liviano.

¿Ya identificaste qué pequeño cambio se puede hacer al código para mejorarlo? Déjamelo en los comentarios.