Crear Lambda layers a mano con el AWS CLI funciona, pero se vuelve un dolor de cabeza cuando tu proyecto crece. Aquí verás cómo automatizar la generación y despliegue de Lambda layers con GitHub Actions y Serverless Framework, para que cada pull request a main empaquete dependencias, suba el artefacto y actualice tu Lambda sin que tú toques una terminal.

¿Por qué automatizar la creación de Lambda Layers?

Cuando tienes una sola layer tipo prod-dependencies, hacerlo manual no se siente tan pesado. El problema aparece cuando empiezas a segmentar.

Imagina que ya no tienes una, sino varias layers especializadas:

• prod-dependencies-clients para integraciones con clientes externos.
• prod-dependencies-processing para tareas de procesamiento en background.
• prod-database-dependencies para conexiones a base de datos.

Cada una requiere comprimir un nodejs.zip, subirlo con AWS CLI y referenciar el ARN correcto en tu serverless.yaml. Multiplica eso por cinco layers (el máximo permitido por Lambda) y cada cambio se vuelve un ritual manual propenso a errores.

¿Cuántas Lambda layers puedo asociar a una función? Máximo cinco por Lambda. Por eso conviene segregarlas por responsabilidad única, no meter todo en una sola.

La solución es delegar todo ese flujo a un motor de CI/CD. Y aquí entra GitHub Actions [01:50].

¿Cómo se estructura el workflow de GitHub Actions para Serverless?

El workflow parte del mismo archivo que ya usabas en el curso anterior de Serverless, pero con cambios puntuales en la sección de artefactos y layers. Se dispara con cada pull request hacia la rama main.

¿Qué hace el job que construye las dependencias?

Este job corre en Ubuntu, dentro de un contenedor de Node 14 buster, y replica los mismos comandos que ejecutarías en local [03:30]:

1. Hace checkout del código.
2. Ejecuta npm install --production sin especificar arquitectura ni plataforma, porque el contenedor ya corre en Linux x64.
3. Crea una carpeta nodejs y mueve los node_modules dentro.
4. Actualiza paquetes e instala zip, ya que la imagen base no lo trae.
5. Genera el archivo comprimido nodejs.zip.

La imagen node:14-buster es importante porque te garantiza compatibilidad con el runtime de Lambda sin tener que pelear con diferencias de tu sistema operativo local.

¿Cómo se pasan los artefactos entre jobs?

Aquí aparece una buena práctica clave: un job no debería tener una cantidad infinita de pasos. Se segrega la responsabilidad en varios jobs y se conectan mediante artefactos.

El primer job sube el nodejs.zip con la acción upload-artifact bajo un nombre, por ejemplo nodejs-devs. El segundo job, el de despliegue, lo descarga con download-artifact referenciando ese mismo nombre y especificando el path donde lo necesita [05:40].

¿Qué es un artefacto en GitHub Actions? Es un archivo o carpeta que un job guarda temporalmente para que otro job del mismo workflow pueda usarlo. Sirve para pasar builds entre etapas sin reconstruir.

¿Qué cambios necesitas hacer en serverless.yaml?

Un detalle fácil de pasar por alto: cuando GitHub Actions descarga el artefacto, lo coloca dentro de una carpeta app. Por eso, en la definición de la layer dentro de serverless.yaml, la referencia al archivo debe apuntar a app/nodejs.zip, no solo a nodejs.zip.

Con ese ajuste, Serverless Framework empaqueta correctamente la layer durante el deploy y CloudFormation la registra como una nueva versión.

¿Cómo se ejecuta el flujo en un pull request real?

El proceso de prueba sigue una secuencia clara:

1. Crear una rama nueva, por ejemplo improvement-layers.
2. Hacer commit de los cambios al serverless.yaml.
3. Publicar la rama con git push -u origin improvement-layers.
4. Abrir un pull request hacia main desde la interfaz de GitHub o con el CLI usando gh pr create.

Apenas se crea el PR, GitHub Actions dispara los jobs. El orden está definido por dependencias: el job deploy-lambda declara que depende de los jobs de testing y de construcción de la layer, así que espera a que ambos terminen antes de desplegar.

¿Qué pasa si fallan las credenciales de AWS?

Un error muy común en el primer despliegue es que falten los secrets configurados. Si vas a Settings > Secrets del repositorio y no tienes las credenciales de AWS guardadas, el job de deploy va a fallar aunque los anteriores hayan pasado.

Lo bueno: GitHub Actions te permite re-ejecutar solo el job fallido, sin repetir todo el pipeline. En la prueba real, después de configurar las variables de entorno, el despliegue completo tomó aproximadamente 90 segundos [09:50].

¿Cómo verificar que la Lambda Layer se actualizó?

Hay dos formas de validarlo desde la consola de AWS.

La primera es ir a la sección de Lambda > Layers y recargar. Vas a ver que la versión subió, por ejemplo de la versión 1 a la versión 2, con la marca de tiempo de hace pocos minutos.

La segunda es revisar CloudFormation, donde en la pestaña de eventos aparece registrada la creación de BaseLambdaLayer. Esa misma referencia se usa como parámetro de CloudFormation para la Lambda del thumbnail generator, lo que asegura que tu función siempre apunte a la última versión de la layer desplegada.

Con esto tienes un pipeline totalmente automático que empaqueta dependencias, las sube como layer y actualiza tu Lambda en cada PR a main. ¿Ya habías usado GitHub Actions con Serverless? Cuéntame en los comentarios cómo lo tienes montado en tus proyectos.