Por qué el límite de Lambda es 15 minutos - La racionalidad oculta en las restricciones de diseño serverless
Explicamos por qué el tiempo máximo de ejecución de 15 minutos de Lambda, el límite de memoria de 10 GB, el payload de 6 MB y otras restricciones serverless están configuradas en esos valores, desde la perspectiva de la filosofía de diseño de Firecracker y la operación multi-tenant.
Los límites son decisiones de diseño, no restricciones
Lo primero que enfrentan los desarrolladores al comenzar con Lambda son los diversos límites. Tiempo máximo de ejecución de 15 minutos, memoria de 128 MB a 10.240 MB, payload de invocación síncrona de 6 MB, paquete de despliegue de 250 MB (expandido). Estos números no se determinaron arbitrariamente, sino que son el resultado de equilibrar la equidad de recursos en un entorno multi-tenant, la seguridad operativa y la eficiencia de costos. Lambda ejecuta funciones de millones de clientes en infraestructura compartida, por lo que cada límite tiene una razón técnica u operativa.
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 extendió a 5 minutos en 2016 y se elevó a los actuales 15 minutos en 2018. Esta extensión gradual refleja la expansión de los casos de uso de los clientes y el avance en la optimización de infraestructura por parte de AWS. El valor de 15 minutos tiene varias justificaciones técnicas y operativas. Primero, la gestión del ciclo de vida de Firecracker MicroVM: mantener MicroVMs durante largos períodos consume recursos del host físico, por lo que se necesita un límite superior. Segundo, la equidad de recursos: si una función monopoliza recursos durante horas, otras funciones se ven afectadas. Tercero, la guía de diseño: el límite de 15 minutos promueve la descomposición del procesamiento en unidades pequeñas y la orquestación con Step Functions.
Razones de los 10 GB de memoria y 6 MB de payload
El límite de memoria de Lambda se elevó de 3.008 MB a 10.240 MB (10 GB) en 2020. Este límite se calcula inversamente a partir de la capacidad de memoria del host físico donde opera la Firecracker MicroVM y el número de MicroVMs que se ejecutan simultáneamente en un host. Como la memoria del host físico se comparte entre cientos de MicroVMs, hay un límite superior en la memoria asignable a una sola MicroVM. El límite de payload de 6 MB para invocaciones síncronas protege la estabilidad de la API Gateway y el servicio Lambda. Si se permitieran payloads de GB, un solo cliente podría saturar el ancho de banda de la red.
Límite predeterminado de 1.000 ejecuciones simultáneas
El límite predeterminado de ejecuciones simultáneas por cuenta de Lambda es 1.000. Este límite es una salvaguarda para evitar que cuentas nuevas ejecuten inadvertidamente grandes cantidades de funciones Lambda simultáneamente, generando facturas elevadas. Mediante solicitudes de aumento de límite, es posible elevarlo a decenas o cientos de miles de ejecuciones simultáneas. El límite de ejecuciones simultáneas también cumple el rol de proteger los servicios downstream a los que Lambda se conecta. Por ejemplo, si Lambda se conecta a una base de datos RDS, un aumento repentino de ejecuciones simultáneas podría agotar el pool de conexiones de la base de datos.
Diseño de arquitectura que aprovecha los límites
La calidad de la arquitectura cambia significativamente según se perciban los límites de Lambda como "restricciones inconvenientes" o como "guías de diseño". El límite de 15 minutos promueve un diseño que divide el procesamiento en unidades pequeñas y las orquesta con Step Functions. El Express Workflow de Step Functions permite un máximo de 5 minutos y el Standard Workflow hasta 1 año de ejecución, permitiendo que Lambda maneje cada paso individual mientras Step Functions gestiona el flujo general. El límite de payload de 6 MB promueve el patrón de pasar referencias de S3 en lugar de datos grandes directamente.