Por qué el límite de 15 minutos de Lambda es de 15 minutos - La racionalidad oculta en las restricciones de diseño serverless
Se explican los valores actuales de los diversos límites serverless, como el tiempo máximo de ejecución de 15 minutos de Lambda, el límite de memoria de 10 GB y el payload de 6 MB, y cómo afectan al diseño de la arquitectura. El análisis parte de la perspectiva de la operación multi-tenant y del ciclo de vida del entorno de ejecución.
Los límites son decisiones de diseño, no restricciones
Lo primero con lo que se encuentran los desarrolladores que empiezan a usar Lambda son sus diversos límites (Limits). Un tiempo máximo de ejecución de 15 minutos, una memoria de 128 MB a 10.240 MB, un payload de invocación síncrona de 6 MB y un paquete de despliegue de 250 MB (descomprimido) son los valores representativos (a fecha de agosto de 2026 / según la lista oficial de cuotas). AWS no ha publicado cómo decidió estos valores. Por ello, lo que se expone a continuación no es la justificación oficial del diseño, sino la racionalidad que se puede deducir desde la perspectiva de la equidad de recursos en un entorno multi-tenant, la seguridad operativa y la eficiencia de costes. Lambda es un servicio multi-tenant que ejecuta las funciones de muchos clientes sobre la misma infraestructura física. Si una función consume recursos sin límite, afecta a las funciones de otros clientes. Los límites son barreras de protección para evitar el «problema del vecino ruidoso» y, al mismo tiempo, restricciones intencionadas que dan forma al paradigma de diseño serverless. Precisamente porque existen límites, los desarrolladores pasan a dividir el procesamiento en unidades pequeñas y a diseñar arquitecturas basadas en eventos y débilmente acopladas.
Historia y contexto del límite de 15 minutos
Cuando Lambda se lanzó en 2014, el tiempo máximo de ejecución era de solo 60 segundos. Se amplió a 5 minutos en re:Invent 2015, en octubre de 2015, y se elevó a los 15 minutos actuales en octubre de 2018. Esta ampliación gradual refleja la expansión de los casos de uso de los clientes y el avance de la optimización de la infraestructura por parte de AWS. Sin embargo, no se encuentra ningún material oficial en el que AWS explique el fundamento de la decisión sobre «por qué se detiene en 15 minutos». Lo que sigue no es una razón de diseño publicada, sino una revisión ordenada de cómo funciona este límite en la práctica. El primer punto es su relación con el ciclo de vida del entorno de ejecución. Las funciones de Lambda se ejecutan en entornos de ejecución preparados sobre MicroVM basadas en Firecracker, y estos entornos de ejecución se reutilizan entre invocaciones, pero no son permanentes. El hecho de que el tiempo de ejecución tenga un límite superior impone de forma natural un diseño que no deja estado en el disco local ni en variables globales. El segundo punto es la perspectiva de la detección de fallos y la recuperación. Si una función sigue ejecutándose durante mucho tiempo, resulta difícil detectar interbloqueos y bucles infinitos. El tiempo de espera se puede configurar por invocación en un rango de 1 segundo a 900 segundos (15 minutos), y funciona como una red de seguridad que finaliza automáticamente las ejecuciones anómalas. El tercer punto es la previsibilidad de los costes. Como Lambda factura por el tiempo de ejecución, si no hay un límite superior en el tiempo de ejecución, un bucle infinito causado por un error da lugar a una factura elevada e inesperada. El límite de 15 minutos garantiza que, incluso en el peor de los casos, el coste de una sola ejecución se mantenga dentro de un rango previsible. Para el procesamiento que no termina en 15 minutos, lo habitual es dividirlo y orquestarlo con Step Functions, o delegarlo en tareas de AWS Batch o Fargate.
Lanzamiento en 2014, 15 minutos desde 2018
El significado práctico de 10 GB de memoria y un payload de 6 MB
El límite de memoria de Lambda se elevó de 3.008 MB a 10.240 MB (10 GB) en 2020. La configuración de memoria también está vinculada a la asignación de CPU: con 1.769 MB se asigna una capacidad de procesamiento equivalente a 1 vCPU, y con el límite de 10.240 MB, una equivalente a unas 6 vCPU. Es decir, aumentar la memoria es, tal cual, una operación que también aumenta la capacidad de cómputo. 10 GB es un límite superior práctico que puede cubrir la inferencia de aprendizaje automático, la transformación de datos a gran escala y el cómputo intensivo en memoria. No se ha publicado el fundamento del cálculo por el que se fijó la línea en 10.240 MB, por lo que, aunque se encuentre una explicación de que se dedujo a partir de la configuración de los hosts físicos, debe tratarse como una suposición. Los límites de payload son de 6 MB para las invocaciones síncronas y de 256 KB para las asíncronas (a fecha de agosto de 2026). Cuando se combina con API Gateway, también es necesario tener en cuenta que el límite de payload de solicitud/respuesta del lado de API Gateway es de 10 MB. Además, la codificación Base64 aumenta los datos binarios en un 33% aproximadamente, por lo que la cantidad de datos originales que realmente se puede transportar es menor que el límite nominal. No se ha indicado oficialmente si el valor de 6 MB se dedujo a partir de los 10 MB de API Gateway. En cualquier caso, cuando se manejan datos grandes, se recomienda el «patrón claim check», que guarda los datos en S3 y pasa a Lambda solo la clave del objeto. En las invocaciones asíncronas, la solicitud se almacena primero en una cola del lado de Lambda y después se pasa a la función. No se ha publicado el motivo del límite de 256 KB, pero sí se explica oficialmente que las invocaciones pasan por una cola.
El límite predeterminado de concurrencia de 1.000
La concurrencia predeterminada de Lambda por cuenta es de 1.000 por región (a fecha de agosto de 2026). Este límite es una salvaguarda para evitar que una cuenta nueva ejecute de forma no intencionada una gran cantidad de funciones de Lambda al mismo tiempo y se genere una factura elevada. Este valor se puede elevar mediante una solicitud de aumento de cuota (el valor que se puede alcanzar tras el aumento no se publica de forma uniforme, y la solicitud se revisa según el historial de uso y el uso previsto). El límite de concurrencia también cumple la función de proteger no solo a Lambda, sino también a los servicios posteriores a los que Lambda se conecta. Por ejemplo, cuando Lambda se conecta a una base de datos RDS, si la concurrencia no tiene límite, se supera el número máximo de conexiones de la base de datos. Si se utiliza RDS Proxy, se puede mitigar con la agrupación de conexiones, pero el propio límite de concurrencia funciona como la primera línea de defensa. Si se configura la concurrencia reservada a nivel de función (Reserved Concurrency), se puede evitar que una función concreta consuma la capacidad de concurrencia de otras funciones. Por ejemplo, si se configura una concurrencia reservada de 500 para la función de un backend de API importante y de 100 para una función de procesamiento por lotes, un aumento repentino del procesamiento por lotes no afecta al rendimiento de la API.
Diseño de arquitectura que convierte los límites en aliados
La calidad de la arquitectura cambia mucho según se consideren los límites de Lambda como «restricciones incómodas» o como «pautas de diseño». El límite de 15 minutos fomenta un diseño que divide el procesamiento en unidades pequeñas y lo orquesta con Step Functions. Los Express Workflows de Step Functions pueden ejecutarse hasta 5 minutos y los Standard Workflows hasta 1 año, por lo que se puede construir un flujo de trabajo de larga duración en su conjunto sin que cada función supere los 15 minutos. El límite de payload de 6 MB fomenta el patrón claim check, que utiliza S3 para pasar datos entre funciones, y como resultado aumenta el desacoplamiento entre funciones. El límite de memoria fomenta un diseño que convierte el procesamiento en streaming. En lugar de cargar en memoria un archivo de 10 GB de una vez, se puede dejar la agregación a Amazon Athena, leer objetos por partes con lecturas por rango (Range) de S3 o S3 Object Lambda, o enviar registro a registro con Kinesis Data Streams. Con estos métodos, se pueden procesar grandes cantidades de datos con poca memoria. Por otra parte, S3 Select ya no está disponible para clientes nuevos, por lo que queda fuera de las opciones para diseños nuevos (a fecha de agosto de 2026). Como resultado, estos límites conducen a los desarrolladores hacia arquitecturas escalables y con alta tolerancia a fallos. Sin límites, probablemente cederían a la tentación de escribir funciones monolíticas gigantes.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.