AWS Lambda elimineert een van haar grootste beperkingen: zo werkt Self-Managed Code Storage

AWS introduce una de las novedades más relevantes para quienes desarrollan aplicaciones serverless a gran escala. Con la llegada de Self-Managed Code Storage para AWS Lambda, las funciones ya no tienen que almacenar su código en el almacenamiento gestionado del servicio. En su lugar, pueden ejecutarse haciendo referencia directamente a los artefactos almacenados en un bucket de Amazon S3 propiedad del cliente. Aunque la diferencia pueda parecer pequeña, este cambio elimina una limitación histórica de Lambda y abre nuevas posibilidades para equipos que gestionan cientos o incluso miles de funciones.

Resumen en 20 segundos de las claves de Self-Managed Code Storage en AWS Lambda

• AWS permite que Lambda refiera directamente el código almacenado en un bucket propio de Amazon S3.
• Se elimina la restricción práctica de espacio de almacenamiento de código, limitado hasta ahora por la capacidad del bucket.
• El límite del almacenamiento gestionado por Lambda se incrementa de 75 GB a 300 GB por región y cuenta.
• El despliegue puede ser más ágil y el cliente mantiene un control total sobre seguridad, cifrado y recuperación ante desastres.

Durante años, el almacenamiento del código no fue una preocupación relevante para pequeños proyectos. Sin embargo, a medida que las arquitecturas serverless crecen, muchas organizaciones gestionan ahora cientos de funciones Lambda, múltiples layers compartidos, librerías cada vez más pesadas e incluso dependencias relacionadas con IA o procesamiento de datos. En estos escenarios, la limitación de 75 GB por región y cuenta podía convertirse en un obstáculo, requiriendo solicitar ampliaciones de cuota mediante soporte técnico. Aunque AWS ya elevó el límite a 300 GB, la nueva funcionalidad va aún más allá, eliminando prácticamente esa restricción.

¿Qué implica realmente Self-Managed Code Storage?

Hasta ahora, cuando se creaba o actualizaba una función Lambda usando un paquete ZIP almacenado en Amazon S3, Lambda copiaba ese paquete a su almacenamiento interno, gestionado por el servicio. Esa copia se usaba para ejecutar la función y consumía parte de la cuota disponible.

Con Self-Managed Code Storage, Lambda deja de realizar esa copia y en su lugar referencia directamente al objeto en el bucket del cliente.

En términos prácticos, la diferencia puede resumirse así:

Modelo tradicional (COPY)

CI/CD
   │
   ▼
Amazon S3
   │
   ▼
Lambda copia el ZIP
   │
   ▼
Almacenamiento interno de Lambda
   │
   ▼
Ejecución

Nuevo modelo (REFERENCE)

CI/CD
   │
   ▼
Amazon S3
   │
   ▼
Lambda referencia directamente el objeto

Este cambio reduce un paso en el proceso de despliegue y transforma al bucket S3 en la fuente única y confiable del código.

AWS también indica que, en sus pruebas con una función Python 3.13 de aproximadamente 200 MB, el tiempo de creación de la función fue unos cinco segundos menor usando el modo REFERENCE comparado con el método tradicional.

De los 75 GB a un almacenamiento prácticamente ilimitado

El beneficio más evidente es el aumento en capacidad.

Hasta ahora, todas las versiones de funciones y layers almacenadas en Lambda consumían parte de la cuota regional. En organizaciones con despliegues continuos, múltiples entornos o muchas versiones activas, este espacio podía crecer rápidamente.

Con el nuevo modo REFERENCE, el almacenamiento deja de depender de Lambda y pasa a depender únicamente del bucket S3 del cliente.

Además, AWS ha aumentado también la cuota del almacenamiento gestionado por Lambda a 300 GB por región y cuenta, equiparándolo con el límite práctico del modo REFERENCE. Esto significa que quienes opten por continuar con el método tradicional tendrán ahora cuatro veces más espacio.

COPY versus REFERENCE: ¿cuáles son las diferencias?

No se trata solo de disponer de más espacio; también cambia quién gestiona el ciclo de vida de los artefactos.

Una opción que se adapta especialmente a pipelines CI/CD

Para muchos equipos DevOps, este nuevo esquema resulta bastante natural.

En la mayoría de pipelines modernos, el proceso ya genera un artefacto, lo almacena en Amazon S3 y posteriormente despliega la infraestructura.

Ahora, ese mismo artefacto puede convertirse en la copia utilizada por Lambda, eliminando duplicidades y simplificando el flujo.

Esto facilita operaciones habituales como:

• realizar rollbacks apuntando a versiones anteriores del objeto S3;
• centralizar todos los artefactos de despliegue;
• aplicar políticas uniformes de cifrado y retención;
• mantener una fuente única de verdad para todo el código.

En organizaciones que gestionan varias cuentas mediante AWS Organizations, eliminar estas duplicidades también simplifica la centralización de los paquetes de despliegue en una cuenta específica y controlar el acceso desde las cuentas de producción mediante políticas en los buckets.

Mayor control en seguridad y cumplimiento

Una de las ventajas menos evidentes, pero probablemente más relevantes para muchas empresas, es el mayor control sobre la seguridad.

Al ser el cliente propietario del almacenamiento del código, puede aplicar directamente sus políticas sobre Amazon S3, como:

• cifrado con SSE-KMS;
• Object Lock;
• versionado;
• auditoría;
• políticas IAM específicas;
• retención de objetos.

Esto facilita cumplir requisitos internos de seguridad y obligaciones regulatorias, sin depender únicamente del almacenamiento gestionado por Lambda.

Además, si se utiliza S3 Cross-Region Replication (CRR), se puede mantener automáticamente una copia del código en otra región como parte de la estrategia de recuperación ante desastres.

Responsabilidades adicionales para el cliente

Por otro lado, el cliente pasa a ser responsable de mantener el acceso al código.

Con REFERENCE, el bucket debe tener habilitado el versión del objeto, y Lambda requerirá permisos s3:GetObject y s3:GetObjectVersion.

Si se usa una clave KMS gestionada por el cliente, también será necesario conceder permisos kms:Decrypt.

Es importante destacar que si el objeto desaparece, cambia la política del bucket o la clave de cifrado deja de estar disponible, Lambda no podrá acceder al código. En ese caso, la función podría pasar a un estado Inactive. Esto no ocurría cuando Lambda almacenaba su propia copia internamente.

Por ello, se recomienda implementar políticas de ciclo de vida que eliminen versiones antiguas y gestionen las renovaciones, asegurando que siempre existan versiones accesibles para facilitar recuperación y posibles rollback.

Terraform aún en proceso de actualización

Al momento del anuncio de estas funciones, AWS confirmó soporte mediante AWS CLI y AWS CloudFormation.

Sin embargo, el proveedor oficial hashicorp/aws para Terraform aún no ha integrado el parámetro s3_object_storage_mode, por lo que, de momento, muchos equipos deberán combinar Terraform con CloudFormation o la CLI para desplegar funciones en modo REFERENCE.

Se espera que este soporte llegue en próximas versiones del provider.

¿Cuándo conviene usar REFERENCE?

No todas las organizaciones necesitan hacer el cambio de forma inmediata.

El método clásico sigue siendo válido para muchos proyectos.

REFERENCE resulta especialmente útil cuando:

• gestionan cientos o miles de funciones Lambda;
• hay numerosos layers compartidos;
• los pipelines CI/CD ya almacenan artefactos en Amazon S3;
• se requieren políticas avanzadas de seguridad o cumplimiento;
• se desea mantener una única fuente de verdad del código.

El método COPY sigue siendo recomendable cuando:

• el proyecto es pequeño;
• las funciones ocupan poco espacio;
• los 300 GB disponibles son suficientes;
• se prefiere la simplicidad operativa;
• se usa frecuentemente el editor de código integrado en la consola de Lambda.

Una evolución lógica del entorno serverless

Self-Managed Code Storage no modifica la forma en que AWS Lambda ejecuta el código, pero sí cambia la gestión de los artefactos de despliegue. El almacenaje deja de ser responsabilidad exclusiva de Lambda y pasa a estar bajo control del cliente, una estrategia que encaja particularmente bien con organizaciones que ya trabajan con infraestructura como código y pipelines de despliegue automatizados.

Además de eliminar casi por completo la limitación de almacenamiento, esta funcionalidad ofrece mayor control sobre seguridad, recuperación ante desastres y gobernanza del software. A la vez, exige gestionar con mayor cuidado el ciclo de vida de los objetos en Amazon S3.

Para equipos que ya utilizan S3 como repositorio central, el paso a REFERENCE resulta casi natural. Para los demás, el aumento de cuota a 300 GB ya representa una mejora significativa sin necesidad de cambiar la arquitectura existente.

Preguntas frecuentes

¿Qué es AWS Lambda Self-Managed Code Storage?

Es una funcionalidad que permite a AWS Lambda usar directamente el código almacenado en un bucket de Amazon S3 del cliente, sin copiarlo previamente al almacenamiento gestionado por Lambda.

¿Se elimina el límite de almacenamiento de Lambda?

El almacenamiento gestionado por Lambda aumenta a 300 GB por región y cuenta. Si se utiliza el modo REFERENCE, el límite práctico será la capacidad del bucket S3.

¿Es obligatorio activar el versionado del bucket?

Sí. El modo REFERENCE requiere que el bucket tenga habilitado el versión para garantizar que Lambda siempre refiera a una versión concreta del artefacto, que debe ser inmutable.

¿Tiene algún coste adicional?

AWS no aplica cargos extra por usar Self-Managed Code Storage; no obstante, el almacenamiento en S3 sí implica costes habituales, además de posibles cargos por solicitudes o transferencias de datos entre regiones si procede.