Lambda SnapStart llega a las imágenes de contenedor y elimina el trueque de empaquetado

AWS ha extendido SnapStart a las funciones de Lambda empaquetadas como imagen de contenedor. Hasta ahora, quien optaba por contenedor para esquivar el techo de 250 MB de los archivos zip se quedaba sin SnapStart y asumía arranques de varios segundos mientras Lambda descargaba las capas de la imagen e inicializaba el runtime. Esa disyuntiva desaparece, al menos en parte.

SnapStart toma una instantánea del entorno de ejecución ya inicializado en el momento del despliegue, la cachea y reanuda desde ahí en cada invocación en lugar de arrancar de cero. AWS cifra el resultado en tiempos de inicio por debajo del segundo. La función solo cubría los runtimes gestionados de Python, .NET y Java, así que el contenedor quedaba fuera.

No todas las imágenes base valen igual

El soporte no es uniforme. En las imágenes base de AWS con Java 11 o superior, Python 3.12 o superior y .NET 8 o superior, el comportamiento es el mismo que en un zip. Cualquier otra imagen —Node.js, Ruby, bases propias— necesita añadir LABEL com.amazonaws.lambda.feature.snapstart="Allow" al Dockerfile o implementar los runtime hooks de SnapStart. Sin una de las dos cosas, la publicación de la versión falla durante la inicialización.

Queda una diferencia entre ambos modelos de empaquetado: AWS parchea el runtime en las funciones basadas en zip, pero con imágenes de contenedor mantener la imagen base al día es responsabilidad del cliente. SnapStart no cambia eso.

El contexto que empujó la demanda se vio en Reddit un mes antes del anuncio. Un equipo que corría pandas y numpy en Lambda había chocado con el límite de 250 MB y recurrió a eliminar espacios en blanco, comentarios y docstrings de su propio código y de los paquetes instalados, con lo que recuperó unos 5 MB. Los docstrings solo podían quitarse donde nada llamara a __doc__, y el autor rechazó rehacer la arquitectura: era código heredado, acoplado a la pila, y el mundo real tiene deuda técnica. En el hilo se corrigió una suposición habitual: las capas de Lambda cuentan contra el mismo presupuesto de 250 MB descomprimidos, así que mover pandas y numpy a una capa no libera espacio. La salida para conservar SnapStart pasaba por montar un punto de acceso EFS e importar las librerías pesadas desde ahí.

El tooling ha ido detrás rápido. Serverless Framework 4.42.0 añadió soporte en la semana siguiente al anuncio, después de que un usuario abriera un issue señalando la carencia. Ahora el framework rechaza antes de desplegar una configuración con almacenamiento efímero por encima de 512 MB combinado con SnapStart, y un fallo al publicar la versión en una función de contenedor imprime una pista que apunta a la etiqueta o a los hooks en lugar de un mensaje crudo de CloudFormation. Un mantenedor del proyecto comentó de paso que la propia documentación de AWS sobre SnapStart seguía describiendo la era en la que solo existía para Java.

SnapStart para imágenes de contenedor está disponible en todas las regiones comerciales de AWS salvo Asia Pacífico en Nueva Zelanda y Taipéi, y se activa en funciones nuevas o existentes desde la API, la consola, la CLI, CloudFormation, SAM, los SDK y el CDK. El precio se documenta aparte del de Lambda estándar.

Lo relevante para quien mantiene cargas pesadas en serverless es que el límite de tamaño deja de ser por sí solo motivo para rediseñar. Los argumentos que apuntaban a ECS Fargate, Step Functions o AWS Batch para trabajo por lotes con pandas siguen en pie: Lambda no es buena herramienta para eso. Lo que cambia es que ya no hay que pagar un peaje de arranque por elegir contenedor.