Capas de Lambda y paquetes de implementación

Los paquetes de implementación de Lambda deben ser autocontenidos: todas las dependencias (bibliotecas, SDK y binarios) deben incluirse en el ZIP. Esto aumenta rápidamente el tamaño del paquete: una función de ciencia de datos en Python con NumPy, Pandas y SciPy puede superar los 200 MB sin comprimir. Cada actualización del código de la función requiere volver a cargar todo el paquete, incluidas las bibliotecas que no han cambiado. Lambda Layers resuelve este problema al separar las dependencias compartidas del código de la función.

Una capa de Lambda es un archivo ZIP que contiene bibliotecas, runtimes personalizados, datos o archivos de configuración. Las capas se almacenan por separado del código de su función y se montan en el entorno de ejecución de la función en /opt. Varias funciones pueden compartir la misma capa: actualice la capa una vez y todas las funciones que la utilicen se beneficiarán. Cada función de Lambda puede tener hasta 5 capas, y el tamaño combinado sin comprimir debe mantenerse por debajo de 250 MB.

Para crear una capa, empaquete sus dependencias en la estructura de directorios correcta para su runtime (por ejemplo, python/lib/python3.12/site-packages/ para Python), comprímala en un archivo ZIP y publíquela. Una vez publicada, la capa recibe un ARN de versión. Haga referencia a este ARN al asociar la capa a una función. Cada vez que actualice la capa se crea una nueva versión; las funciones seguirán utilizando la versión con la que se configuraron hasta que las actualice explícitamente.

Añada capas a una función mediante el parámetro --layers al crear o actualizar una función. Lambda monta todas las capas asociadas en /opt antes de que se inicie la función. Los paquetes de Python ubicados en /opt/python se incluyen automáticamente en la ruta de Python; los módulos de Node.js ubicados en /opt/nodejs/node_modules se encuentran automáticamente. El código de su función puede usar import o require para importar paquetes de las capas como si estuvieran instalados localmente.

AWS publica capas oficiales que puede utilizar sin crear las suyas propias. Algunos ejemplos son la capa AWS Lambda Powertools (registro estructurado, trazabilidad y feature flags), las capas de controladores de bases de datos y la capa AWS Parameters and Secrets Lambda Extension, que permite almacenar localmente en caché valores de SSM/Secrets Manager. Proveedores externos como Datadog y New Relic también publican capas públicas para sus agentes de monitorización. Consulte el Serverless Application Repository y la consola de Lambda para ver las capas públicas disponibles.

Las extensiones de Lambda se ejecutan como procesos independientes junto al código de su función dentro del mismo entorno de ejecución. Se conectan a los eventos del ciclo de vida de Lambda (init, invoke y shutdown) para realizar tareas como la recopilación de telemetría, el análisis de seguridad o el almacenamiento en caché de la configuración. Las extensiones se distribuyen como capas de Lambda. AWS proporciona las extensiones CloudWatch Lambda Insights y AWS AppConfig; los proveedores ofrecen agentes de monitorización personalizados como extensiones.

Lambda admite dos formatos de implementación:

• ZIP (hasta 50 MB comprimido y 250 MB sin comprimir): carga rápida, admite capas y funciona con todos los runtimes.
• Imagen de contenedor (hasta 10 GB): se almacena en Amazon ECR, utiliza herramientas estándar de Docker, no admite capas y es ideal para dependencias muy grandes (modelos de ML y binarios grandes).

Las imágenes de contenedor deben implementar la Lambda Runtime Interface (mediante las imágenes base que proporciona AWS) para que Lambda sepa cómo invocar su handler.

La creación y la implementación de una imagen de contenedor de Lambda siguen un flujo de trabajo estándar de contenedores: cree la imagen con docker build, súbala a Amazon ECR y haga referencia al URI de la imagen al crear o actualizar la función de Lambda. Las imágenes de contenedor son inmutables: cada etiqueta de imagen corresponde a una versión específica de la función. Lambda almacena en caché las imágenes de contenedor en su infraestructura, por lo que los siguientes arranques en frío son más rápidos que el primero.

Las versiones de Lambda son instantáneas inmutables del código y la configuración de su función. Cada vez que publica una versión, Lambda congela el paquete de implementación, las variables de entorno y las capas. Los alias son punteros con nombre a versiones específicas: prod puede apuntar a la versión 5 y staging a la versión 6. También puede utilizar alias ponderados para dirigir un porcentaje del tráfico a una versión nueva durante las implementaciones canary (por ejemplo, 10 % a v6 y 90 % a v5).

Las capas también tienen versiones. Cuando publica una nueva versión de una capa, las funciones existentes siguen utilizando la versión fijada hasta que las actualiza. Esto le permite actualizar de forma segura una capa compartida sin interrumpir todas las funciones simultáneamente: implemente la nueva versión de forma gradual. Con el tiempo, marque como obsoletas las versiones antiguas de las capas para reducir la carga de almacenamiento y mantenimiento. Lambda conserva las versiones de las capas incluso si las elimina de la consola, hasta que ninguna función haga referencia a ellas.

Utilice capas cuando el tamaño total sin comprimir sea inferior a 250 MB, quiera compartir dependencias entre varias funciones y necesite iterar rápidamente (actualice la capa una vez y todas las funciones se beneficiarán). Utilice imágenes de contenedor cuando las dependencias superen los 250 MB, necesite usar paquetes de sistema operativo base personalizados, ya tenga flujos de trabajo de Docker o quiera incluir recursos grandes (modelos de ML y bases de datos de referencia). Las imágenes de contenedor no son compatibles con las capas de Lambda, pero ofrecen mayor flexibilidad.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que las capas de Lambda empaquetan las dependencias compartidas por separado del código de la función, lo que reduce el tamaño del paquete y permite reutilizarlas en varias funciones; las imágenes de contenedor (de hasta 10 GB mediante ECR) son la opción adecuada cuando las dependencias superan el límite de 250 MB de ZIP o cuando ya se utilizan flujos de trabajo de Docker; y el versionado y los alias permiten realizar implementaciones inmutables y despliegues canary con división ponderada del tráfico. A continuación exploraremos Lambda@Edge y los patrones basados en eventos.