Reducir el tamaño de tus funciones Lambda no es un capricho técnico: es la diferencia entre un despliegue que tarda 72 segundos y uno que vuela. Si tus funciones pesan 18 MB y solo necesitan unos cuantos kilobytes, estás cargando basura que ralentiza el cold start, infla tus minutos de GitHub Actions y te impide editar el código directamente en la consola de AWS.

¿Por qué importa el tamaño de una función Lambda?

Una Lambda pesada afecta dos momentos críticos: el despliegue y el arranque. Aunque serverless suene a “sin servidor”, tu código sí se ejecuta en una máquina en la nube que debe cargarlo cada vez que entra una petición HTTP.

• Cold start más lento: cuanto más pesa el paquete, más tarda el servidor en cargarlo antes de ejecutar la primera petición.
• Despliegues costosos: GitHub Actions cobra por minutos. Subir 18 MB a AWS toma más tiempo que subir 1 KB.
• Buenas prácticas de la industria: la recomendación es mantener Lambdas pequeñas y enfocadas.

En el ejemplo de la clase, el despliegue inicial tardaba 72 segundos [05:12], en buena parte porque GitHub Actions estaba subiendo 18 MB innecesarios a AWS.

¿Qué es el cold start en Lambda? Es el tiempo que tarda AWS en preparar un contenedor, cargar tu código y ejecutarlo por primera vez. Si tu paquete pesa menos, ese arranque es más rápido.

¿Cómo reducir el peso de una Lambda con serverless.yml?

La clave está en el bloque package del archivo serverless.yml. La estrategia es contraintuitiva pero efectiva: excluir todo y luego incluir solo lo necesario en cada función.

Excluir todos los archivos a nivel global

En la sección package del serverless.yml raíz, configuras un patrón que excluye absolutamente todo del paquete por defecto. El símbolo de exclamación (!) actúa como negación dentro del patrón, indicando que ningún archivo debe incluirse.

Si dejaras la configuración así, tu paquete quedaría vacío. El truco está en sobrescribir esta opción dentro de cada función Lambda.

Incluir solo el handler de cada función

Dentro de la definición de cada Lambda, agregas su propio bloque package con el patrón específico del archivo que necesita. Por ejemplo, para una función getUsers, indicas la ruta exacta: getUsers/handler.js.

Pasos concretos para hacer el refactor:

1. Mueve el patrón de exclusión global al nivel raíz de package.
2. Elimina la opción de empaquetado individual antigua, porque ahora cada Lambda gestiona su propio patrón.
3. En cada función, agrega un bloque package con patterns apuntando al handler específico.
4. Respeta la extensión correcta: .js para Node.js, .py para Python (por ejemplo, deleteUsers/handler.py).
5. Verifica que el nombre de la carpeta y el archivo coincidan exactamente con la estructura del proyecto.

Es fundamental que el YAML quede bien indentado y al mismo nivel que la propiedad handler de cada función [07:45].

¿Qué hace el símbolo ! en los patterns de Serverless Framework? Funciona como una negación. Le dice al empaquetador que excluya los archivos que coincidan con ese patrón, dejando fuera todo lo que no quieras subir a AWS.

¿Qué beneficios reales obtienes tras la optimización?

Después de aplicar este refactor, las funciones Lambda pasaron de 18 MB a aproximadamente 1.2 KB cada una [13:20]. La diferencia no es marginal, es de varios órdenes de magnitud.

Despliegues más rápidos y baratos

Menos peso significa menos tiempo subiendo el paquete a AWS desde GitHub Actions. Eso se traduce en menos minutos consumidos del plan gratuito y, si tu equipo crece, menos costos asociados al CI/CD.

En la clase también se mencionan otras estrategias complementarias para optimizar GitHub Actions:

• Cachear dependencias como Serverless Framework para evitar reinstalarlas en cada ejecución.
• Separar pasos del workflow para que no todos se ejecuten en cada commit.
• Usar Lambda layers cuando las dependencias crezcan y se repitan entre funciones.

Edición en vivo desde la consola de AWS

Aquí viene lo interesante. AWS impone un límite de tamaño para permitir editar el código de una Lambda directamente desde la consola web. Con paquetes de 18 MB, esa opción está bloqueada. Con paquetes de 1 KB, puedes hacer live coding y ajustar el handler sin necesidad de redesplegar desde tu máquina local.

Esto es especialmente útil para depurar errores rápidos o probar cambios menores en producción controlada.

¿Cómo validar el cambio sin desplegar manualmente?

Si ya tienes automatización con GitHub Actions configurada, no necesitas correr sls deploy localmente. Basta con seguir el flujo normal de Git:

1. git add . para incluir los cambios.
2. git commit -m "improvement on packaging" con un mensaje descriptivo.
3. git push origin nombre-de-la-rama para enviar los cambios al repositorio remoto.

El workflow se dispara solo, ejecuta el build and test, y al finalizar despliega las Lambdas optimizadas. En la pestaña de Actions del repositorio puedes ver el progreso en tiempo real y confirmar que el tiempo total bajó respecto a despliegues anteriores.

¿Qué otras estrategias has usado tú para reducir el peso de tus funciones serverless? Cuéntanos en los comentarios qué optimizaciones aplicarías o si ya estás usando Lambda layers en tus proyectos.