AWS ha presentado una de las novedades más interesantes para quienes desarrollan aplicaciones serverless a gran escala. Con la llegada de Self-Managed Code Storage para AWS Lambda, las funciones ya no tienen por qué almacenar su código dentro del almacenamiento gestionado por el propio servicio. En su lugar, pueden ejecutarse referenciando directamente los artefactos almacenados en un bucket de Amazon S3 perteneciente al cliente. El cambio parece pequeño, pero elimina una limitación histórica de Lambda y abre nuevas posibilidades para equipos que gestionan cientos o miles de funciones.

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

• AWS permite que Lambda referencie directamente el código almacenado en un bucket propio de Amazon S3.
• Desaparece el límite práctico de almacenamiento de código, que pasa a depender de la capacidad del bucket.
• También aumenta la cuota del almacenamiento gestionado de Lambda de 75 GB a 300 GB por región y cuenta.
• El despliegue puede ser más rápido y el cliente mantiene un mayor control sobre seguridad, cifrado y recuperación ante desastres.

Durante años, el almacenamiento del código apenas había sido una preocupación para proyectos pequeños. Sin embargo, a medida que las arquitecturas serverless han ido creciendo, muchas organizaciones han terminado gestionando cientos de funciones Lambda, múltiples layers compartidos, librerías cada vez más pesadas e incluso dependencias relacionadas con inteligencia artificial o procesamiento de datos. En estos escenarios, el límite histórico de 75 GB por región y cuenta podía convertirse en un obstáculo, obligando a solicitar ampliaciones de cuota mediante soporte técnico. Aunque AWS ya había incrementado ese límite hasta 300 GB, la nueva funcionalidad va un paso más allá y elimina prácticamente esa restricción.

Qué cambia realmente con Self-Managed Code Storage

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

Con Self-Managed Code Storage, Lambda deja de realizar esa copia y pasa a utilizar directamente el objeto almacenado en el bucket del cliente.

En la práctica, 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

El cambio reduce un paso completo del proceso de despliegue y convierte el bucket S3 en la fuente de verdad del código.

AWS indica además que, en sus propias pruebas con una función Python 3.13 de aproximadamente 200 MB, el tiempo necesario para crear la función fue alrededor de cinco segundos menor utilizando el modo REFERENCE frente al comportamiento tradicional.

Del límite de 75 GB al almacenamiento prácticamente ilimitado

El beneficio más evidente es el relacionado con el espacio disponible.

Hasta ahora, todas las versiones de funciones y layers almacenadas por Lambda consumían parte de la cuota regional. En organizaciones con despliegues continuos, numerosos entornos o múltiples versiones activas, ese 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 de Amazon S3.

Además, AWS ha aumentado simultáneamente la cuota del almacenamiento gestionado de Lambda de 75 GB a 300 GB por región y cuenta. Esto significa que incluso quienes decidan continuar utilizando el modo tradicional dispondrán de un margen cuatro veces mayor.

COPY frente a REFERENCE: ¿qué diferencias existen?

Aspecto	COPY	REFERENCE
Almacenamiento gestionado por Lambda	Sí	No
Límite práctico	300 GB por región	Capacidad del bucket S3
Tiempo de despliegue	Incluye copia del paquete	Evita la copia
Fuente de verdad del código	Lambda	Bucket S3 del cliente
Control sobre cifrado y retención	Limitado	Completo
Recuperación ante desastres mediante CRR	No	Sí
Edición desde la consola Lambda	Disponible	No disponible
Versionado obligatorio	No	Sí

No se trata únicamente de disponer de más espacio. También cambia quién controla el ciclo de vida de los artefactos.

Un cambio que encaja especialmente bien con los pipelines CI/CD

Para muchos equipos DevOps, el nuevo funcionamiento 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 directamente en la copia utilizada por Lambda, evitando duplicaciones innecesarias.

Esto simplifica operaciones habituales como:

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

En organizaciones que utilizan varias cuentas mediante AWS Organizations, también resulta más sencillo centralizar los paquetes de despliegue en una cuenta específica de tooling y permitir el acceso controlado desde las cuentas de producción mediante políticas de bucket.

Más control sobre seguridad y cumplimiento normativo

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

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

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

Eso facilita cumplir requisitos internos de seguridad o determinadas obligaciones regulatorias sin depender exclusivamente del almacenamiento administrado por Lambda.

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

También aparecen nuevas responsabilidades

La otra cara de la moneda es que el cliente pasa a ser responsable de mantener accesible ese código.

Con el modo REFERENCE, el bucket debe tener el versionado habilitado y Lambda necesita permisos para acceder a los objetos mediante s3:GetObject y s3:GetObjectVersion.

Si se utiliza una clave KMS gestionada por el cliente, Lambda también necesitará permisos kms:Decrypt.

Además, hay un aspecto importante que conviene tener presente: si el objeto desaparece, cambia la política del bucket o deja de estar disponible la clave de cifrado, Lambda ya no podrá acceder al código. En ese caso la función puede pasar al estado Inactive, algo que no ocurría cuando Lambda almacenaba internamente su propia copia.

Por ese motivo resulta recomendable configurar políticas de ciclo de vida que eliminen versiones antiguas del código de forma controlada, manteniendo siempre algunas versiones disponibles para facilitar posibles rollbacks.

Terraform todavía está poniéndose al día

En el momento de publicarse esta funcionalidad, AWS confirmó soporte mediante AWS CLI y AWS CloudFormation.

Sin embargo, el proveedor oficial hashicorp/aws para Terraform todavía no había incorporado el parámetro s3_object_storage_mode, por lo que, de forma temporal, muchos equipos deberán combinar Terraform con CloudFormation o con la CLI para desplegar funciones utilizando el nuevo modo REFERENCE.

Es previsible que el soporte llegue en futuras versiones del provider.

¿Cuándo merece la pena utilizar REFERENCE?

No todas las organizaciones necesitan cambiar inmediatamente.

El modo tradicional sigue siendo perfectamente válido para muchos proyectos.

REFERENCE resulta especialmente interesante cuando:

• se gestionan cientos o miles de funciones Lambda;
• existen numerosos layers compartidos;
• los pipelines CI/CD ya utilizan Amazon S3 como repositorio de artefactos;
• se necesitan políticas avanzadas de seguridad o cumplimiento;
• se quiere mantener una única fuente de verdad del código.

COPY continúa siendo una buena opción cuando:

• el proyecto es pequeño;
• las funciones ocupan poco espacio;
• los 300 GB disponibles son suficientes;
• se desea mantener la máxima simplicidad operativa;
• se utiliza con frecuencia el editor integrado de código de la consola de Lambda.

Una evolución lógica del modelo serverless

Self-Managed Code Storage no cambia la forma en que AWS Lambda ejecuta el código, pero sí modifica la manera de gestionar los artefactos de despliegue. El almacenamiento deja de ser responsabilidad exclusiva de Lambda y pasa a estar bajo el control del propio cliente, algo que encaja especialmente bien con organizaciones que ya trabajan con infraestructuras como código y pipelines de despliegue automatizados.

Además de eliminar prácticamente el límite histórico de almacenamiento de código, esta funcionalidad ofrece un mayor control sobre seguridad, recuperación ante desastres y gobierno del software. Al mismo tiempo, obliga a gestionar con más cuidado el ciclo de vida de los objetos almacenados en Amazon S3.

Para equipos que ya utilizan S3 como repositorio central de artefactos, el paso hacia REFERENCE resulta prácticamente natural. Para el resto, el aumento de la cuota hasta 300 GB ya supone una mejora importante sin necesidad de modificar la arquitectura existente.

Preguntas frecuentes

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

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

¿Desaparece el límite de almacenamiento de Lambda?

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

¿Es obligatorio activar el versionado del bucket?

Sí. El modo REFERENCE requiere que el bucket tenga el versionado habilitado para garantizar que Lambda siempre haga referencia a una versión concreta e inmutable del artefacto.

¿Tiene algún coste adicional?

AWS no cobra un coste adicional por utilizar Self-Managed Code Storage, pero el almacenamiento pasa a depender de Amazon S3, por lo que se aplican los costes habituales del servicio, además de posibles solicitudes y transferencias de datos entre regiones si corresponde.