Empaquetar Lambda AWS: ZIP, capas y contenedores

Empaquetar Lambda AWS tiene tres caminos: ZIP hasta 250 MB descomprimido, capas (layers) para compartir dependencias, e imágenes de contenedor hasta 10 GB. La subida directa a Lambda corta en 50 MB comprimido; si tu artefacto pesa más, pasás obligatoriamente por S3. Elegís según el tamaño y si reutilizás librerías.

Empaquetar Lambda AWS es el proceso de armar el artefacto que subís a AWS con el código de tu función más sus dependencias. AWS soporta dos formatos: un archivo ZIP (código y librerías comprimidos) o una imagen de contenedor compatible con OCI. El artefacto se despliega con CreateFunction o UpdateFunctionCode, y define qué corre dentro del entorno de ejecución de Lambda.

¿Cuál es el límite de tamaño para el empaquetamiento de AWS Lambda?

Acá viene la confusión número uno. Hay dos números y no son lo mismo.

El primero: 50 MB comprimido. Es el máximo que podés subir de forma directa cuando mandás el ZIP en la request. El segundo: 250 MB descomprimido, que aplica al total de la función más todas sus capas ya expandidas en el entorno de ejecución. Según la documentación de configuración de Lambda, ese techo de 250 MB incluye el código de la función y las capas juntas. Ponele que tu ZIP pesa 40 MB comprimido pero al descomprimir se infla a 300 MB: pasás el límite igual, aunque la subida haya entrado.

¿Y si necesitás más? Ahí entra el contenedor: 10 GB de imagen. Es otro mundo de tamaño.

ZIP vs imágenes de contenedor: ¿cuándo usar cada una?

La regla que baja AWS es directa. Si el escenario habla de un paquete que supera los 250 MB, la respuesta es imagen de contenedor. Si habla de compartir dependencias entre varias funciones, la respuesta es capas. Para el resto (la mayoría de los casos), ZIP. Cubrimos ese tema en detalle en plataformas como Microsoft y GitHub.

El ZIP es el default por algo: arranca más rápido en el primer invoke y no te obliga a mantener un Dockerfile. El tema es que se queda corto con librerías pesadas. Si estás desplegando modelos de inferencia, AWS mostró que hasta eso entra en ZIP con optimización, pero cuando las dependencias no bajan de varios cientos de MB, el contenedor es el camino.

Formato	Límite tamaño	Cuándo usarlo	Contra
ZIP directo	50 MB comprimido	Funciones simples, pocas deps	No sirve para artefactos grandes
ZIP vía S3	250 MB descomprimido	La mayoría de los workloads	Techo de 250 MB con capas incluidas
Capas (layers)	250 MB total, 5 por función	Deps compartidas entre funciones	Gestión de versiones, límite de 5
Imagen de contenedor	10 GB	ML, runtimes custom, deps enormes	Cold start más lento en el primer invoke

Un dato que se olvida: no podés convertir un formato en otro. Si arrancaste con ZIP y querés pasar a contenedor, necesitás crear una función nueva. No hay migración in-place.

¿Cómo gestionar dependencias con AWS Lambda Layers?

Una capa es un ZIP con librerías, un runtime custom u otras dependencias que Lambda extrae a /opt en el entorno de ejecución. Cada vez que publicás una capa, se crea una versión inmutable (no se sobrescribe, se versiona). Y podés compartirla entre funciones, entre cuentas, o hacerla pública.

Los límites que importan, según la doc oficial de capas:

• Máximo 5 capas por función. Si necesitás una sexta, tenés que consolidar.
• El total sigue contando para los 250 MB descomprimidos (función + capas).
• Versionado automático: cada publish genera una versión nueva e inmutable.

¿Para qué te sirve en multi-ambiente? Ponele que tenés dev, staging y prod usando el mismo boto3 o el mismo cliente de base de datos. En vez de meter esa dependencia en cada ZIP, la empaquetás una vez como capa y la enganchás a las funciones que quieras. Deploys más chicos, y una sola fuente de verdad para esa librería.

Empaquetar dependencias Python y Node.js para Lambda

Acá está el clásico dolor de cabeza. Instalás numpy o pandas en tu Mac, armás el ZIP, lo subís, y en Lambda explota con un error de módulo que en local andaba perfecto. ¿Por qué? Lambda corre sobre Linux, y los paquetes con binarios compilados que instalaste en macOS o Windows no son compatibles. Sobre eso hablamos en vulnerabilidades de seguridad en repositorios.

La solución para Python la marca la documentación de empaquetado: instalar con el flag --platform manylinux2014_x86_64 (o el que corresponda a tu arquitectura), forzando ruedas compatibles con el runtime de Lambda. Así:

• Python: pip install --platform manylinux2014_x86_64 --only-binary=:all: -t ./package numpy
• Node.js en capas: la estructura tiene que ser nodejs/node_modules/. Si no respetás esa carpeta, Lambda no encuentra los módulos.

Con paquetes que tienen extensiones nativas, la vía más segura es compilar en un entorno Linux equivalente al de Lambda (un contenedor con la imagen base de AWS, por ejemplo). Subís el modelo, lo probás en local, funciona bárbaro, lo mandás a producción y de repente todo se rompe porque el binario era de otra plataforma, las ruedas no eran las correctas y nadie se dio cuenta hasta el primer invoke real.

Optimizar el artefacto: reducir el tamaño del paquete

Menos peso es menos cold start y menos dolores con el límite de 250 MB. Algunas jugadas concretas:

• Sacá lo que no corre en runtime: .git, tests, docs, archivos de ejemplo. No aportan nada dentro de Lambda.
• Excluí binarios del versionado: mantenelos fuera del árbol que empaquetás.
• Usá /tmp para cache temporal: tenés 512 MB por defecto en el entorno de ejecución (ampliable). Sirve para descargar y cachear cosas grandes en runtime.
• Archivos pesados a S3: si un modelo o dataset es enorme, dejalo en S3 y descargalo bajo demanda en vez de hornearlo en el artefacto.

Para Node.js, herramientas de bundling como serverless-webpack recortan el árbol de dependencias y bajan bastante el peso final.

Despliegue desde S3: cómo subir artefactos mayores a 50 MB

El upload directo corta en 50 MB. Punto. Si tu ZIP lo supera, el flujo es otro:

• Subís el ZIP a un bucket de S3 en la misma región que la función.
• Llamás a CreateFunction o UpdateFunctionCode apuntando al objeto de S3 (bucket + key), no mandando los bytes directo.
• No pagás transferencia por la descarga dentro de la misma región.

Si usás infraestructura como código, el comando cloudformation package (o sam package) sube el artefacto a S3 y reescribe la plantilla con la referencia automáticamente. Te ahorra hacerlo a mano. Y si además estás montando el resto de tu stack (un panel, una API pública, el front que consume estas funciones) y necesitás hosting y dominios en Argentina para esa parte, ese pedazo vive fuera de Lambda, pero conviene tenerlo mapeado desde el arranque.

¿Cómo estructurar un proyecto Lambda para múltiples entornos?

La idea base: separá lo que es código de lo que es configuración. El código va en el artefacto (ZIP o contenedor). La config que cambia entre dev, staging y prod no debería estar hardcodeada adentro. Esto se conecta con lo que analizamos en automatizar deploys con CI/CD.

AWS AppConfig resuelve la parte de configuración en runtime: cambiás un valor sin redeployar la función. Y las dependencias compartidas van en capas versionadas, así los tres entornos consumen la misma librería. Eso sí: actualizar una capa no actualiza sola a las funciones que la usan. Tenés que apuntar cada función a la versión nueva de la capa, es un paso explícito. Todo esto se integra con SAM o CDK en tu pipeline de CI/CD, que arma el artefacto, lo sube a S3 y despliega por ambiente.

Errores comunes al empaquetar artefactos Lambda

• Instalar deps en Windows o macOS y subirlas tal cual. Los binarios compilados no corren en el Linux de Lambda. Corrección: usá --platform manylinux2014 o compilá en un contenedor con la imagen base de AWS.
• Pasar los 250 MB sin plan. Si no entrás con capas, no insistas con ZIP: mové a imagen de contenedor (10 GB).
• Meter el node_modules entero. Arrastrás dev dependencies y basura que infla el paquete. Instalá solo producción y bundleá.
• Intentar más de 5 capas. Es un límite duro. Consolidá dependencias en menos capas antes de chocarte con él.
• No versionar bien las capas. Si asumís que “la capa” es una sola cosa, te vas a confundir: cada publish es una versión inmutable distinta y las funciones apuntan a una versión específica.

Preguntas Frecuentes

¿Cuál es el límite máximo de tamaño para un paquete ZIP de Lambda?

El límite es 50 MB comprimido para la subida directa y 250 MB descomprimido para el total de código más todas las capas ya extraídas. Son dos techos distintos: podés cumplir el primero y romper el segundo si tu paquete se infla al descomprimir.

¿Cómo crear y compartir dependencias entre funciones Lambda?

Con capas (Lambda Layers). Empaquetás las librerías en un ZIP, publicás la capa (genera una versión inmutable) y la enganchás a las funciones que la necesiten. Una capa se puede compartir entre funciones, entre cuentas o hacerse pública.

¿Qué debo hacer si mi paquete Lambda excede 250 MB?

Pasá a imagen de contenedor, que soporta hasta 10 GB. El límite de 250 MB descomprimido es exclusivo del formato ZIP con capas; una vez que lo superás, el contenedor OCI es el único camino que te habilita AWS. Ya lo cubrimos antes en elegir entre Jenkins y GitHub Actions.

¿Debo usar imágenes de contenedor o ZIP para Lambda?

ZIP para la mayoría de los workloads: arranca más rápido y no exige mantener un Dockerfile. Contenedor cuando tenés dependencias pesadas (ML, runtimes custom) o superás los 250 MB. No se puede convertir entre formatos: cambiar implica crear una función nueva.

¿Cómo subir un artefacto Lambda mayor a 50 MB?

Subilo primero a un bucket de S3 en la misma región y después referenciá ese objeto en CreateFunction o UpdateFunctionCode. La subida directa solo admite hasta 50 MB; con sam package o cloudformation package el paso a S3 se hace automático.

Conclusión

Empaquetar Lambda AWS no es un solo procedimiento, es elegir bien entre tres formatos según dos preguntas: ¿cuánto pesa y comparto dependencias? Si pesa poco, ZIP. Si comparto librerías entre funciones, capas. Si me paso de 250 MB, contenedor. Y si el artefacto supera 50 MB, sé que voy por S3 sin pensarlo.

El error que más caro se paga es el de los binarios compilados en la plataforma equivocada, porque no salta hasta el primer invoke en producción. Empezá por ahí: definí tu límite de tamaño, elegí el formato, y compilá tus dependencias en un entorno Linux compatible antes de armar el artefacto. Con eso te ahorrás el 80% de los dolores de deploy.

Fuentes

• AWS Lambda – Deployment packages (.zip) – Límites de tamaño y despliegue vía S3.
• AWS Lambda – Working with layers – Capas, límite de 5, versionado e /opt.
• AWS Lambda – Create a function using a container image – Formato de contenedor hasta 10 GB.
• AWS Lambda – Empaquetar dependencias Python – Flag –platform y manylinux2014.
• Prepare Application Artifacts To Be Deployed To AWS (dev.to) – Guía de artefactos multi-ambiente.