Lambda sube el timeout a 90 minutos, pero solo en Managed Instances
El nuevo techo se aplica a Lambda Managed Instances y multiplica por seis el límite anterior. Las peticiones síncronas tradicionales siguen con 15 minutos.
AWS Lambda admite desde ahora funciones de hasta 90 minutos en Lambda Managed Instances, seis veces el límite de 15 minutos que regía hasta hoy. El cambio no toca las peticiones síncronas tradicionales, que conservan el techo anterior. Es el mayor salto en el tiempo máximo de ejecución desde 2018, cuando la compañía lo subió de 5 a 15 minutos.
El cuarto de hora se quedaba corto en procesado de medios, cálculos financieros, ETL y procesamiento de datos, inferencia de IA, scraping o transferencias de ficheros grandes: trabajos que superan ese tiempo de forma continua y obligaban a trocear la tarea, encadenar invocaciones o sacarla a ECS. AWS lo detalla en la nota de anuncio y en el blog de cómputo.
Lo que hay que revisar antes de estirar la función
Un runtime largo exige más cuidado. Las conexiones de red y las credenciales temporales tienen que seguir siendo válidas durante toda la ejecución, y el código debe tolerar reintentos y entregas duplicadas. Lambda no garantiza procesamiento exactly-once, y cuanto más dura la función, más ventana hay para que un reintento repita trabajo. El equipo recomienda Powertools for AWS Lambda para implementar idempotencia, de modo que un pago o una escritura en base de datos den el mismo resultado aunque se ejecuten dos veces. Las Durable Functions también piden idempotencia, porque un paso fallido puede volver a correr.
Lambda ya venía dividiéndose en dos formas: las funciones para cargas dirigidas por eventos, con 15 minutos, y los MicroVMs para código generado por usuarios o por IA, que llegan a 8 horas. Las Managed Instances son la pieza que faltaba para cargas en régimen estable: admiten varias peticiones por instancia y dan acceso a precios y opciones de cómputo de EC2 sin gestionar la infraestructura. El servicio soporta además instancias EC2 con Graviton5. El timeout extendido está disponible en todas las regiones donde hay Managed Instances.
La comunidad, entre el alivio y la factura
La reacción mayoritaria ha sido positiva. Yan Cui, experto en serverless y AWS Hero, lo resume con resignación: "Parte de mí lamenta que esto difumine aún más la línea entre ejecutar un servidor y una invocación de Lambda. Pero tiene sentido, sobre todo para el caso de uso de Lambda en flujos agénticos". Rajesh Pandey, ingeniero principal de AWS, apunta en la misma dirección: "He perdido la cuenta de cuántas veces los clientes nos han preguntado cuándo vais a construir funciones Lambda de larga duración. Por fin está aquí. Mucho del pegamento que había alrededor de la duración máxima de ejecución se puede quitar ya".
No todos lo ven igual. El usuario Dull_Caterpillar_642 avisa de que el nuevo límite puede premiar diseños frágiles: "Si tarda 90 minutos, hay muchas posibilidades de que deberías estar usando algo como durable functions. A menos que tu código esté literalmente haciendo cosas útiles todo ese tiempo en lugar de esperar a otras cosas, en cuyo caso la economía de Lambda puede no salir tan a tu favor, y algo como ECS Tasks o AWS Batch podría tener más sentido".
Para quien mantenía funciones partidas en trozos por culpa del cuarto de hora, la revisión de esa arquitectura ya se puede plantear. Para quien usaba Lambda como sustituto cómodo de un servidor, el cambio no arregla el problema de fondo: sigue sin garantizar exactly-once y sigue cobrando por tiempo de ejecución, así que la comparación con ECS o Batch conviene hacerla antes de mudar la carga, no después.
