Durante más de una década, AWS Lambda ha sido sinónimo de una promesa clara: código que se ejecuta en respuesta a eventos, sin servidores que gestionar, sin infraestructura que mantener. Pero esa promesa siempre venía con una letra pequeña: 15 minutos.
Si tu tarea tardaba más, tenías que buscar alternativas, trocear el trabajo o recurrir a servicios más pesados. Ahora, AWS acaba de ampliar ese límite hasta los 90 minutos en Lambda Managed Instances, seis veces más que el máximo anterior. La noticia no es solo un cambio técnico; es una señal de hacia dónde se dirige el futuro de la computación sin servidores.
La medida llega acompañada de un matiz importante: el límite de 15 minutos sigue vigente para las solicitudes síncronas tradicionales. La extensión aplica únicamente a las funciones que se ejecutan en Lambda Managed Instances, la modalidad que AWS introdujo para cargas de trabajo en estado estacionario.
Es decir, Lambda ya no es solo para picos repentinos de tráfico o procesos ligeros. Ahora también puede manejar trabajos que antes requerían una instancia EC2 o un contenedor en ECS.
Una historia de límites que se quedaron cortos
Para entender la magnitud del cambio, conviene recordar la evolución. Cuando Lambda se lanzó en 2014, el tiempo máximo de ejecución era de cinco minutos. En 2018, AWS lo amplió a 15 minutos, y esa cifra se mantuvo durante casi una década. Durante ese tiempo, los desarrolladores aprendieron a vivir con la limitación, creando todo tipo de soluciones improvisadas: dividir tareas en fragmentos, encadenar invocaciones, usar Step Functions para orquestar procesos largos o, simplemente, migrar a servicios más tradicionales cuando el trabajo era demasiado extenso.
Los casos de uso que se beneficiarán de los 90 minutos son variados: procesamiento de medios, cálculos financieros, pipelines de ETL, inferencia de IA, web scraping y transferencia de archivos grandes. Todos ellos comparten una característica: son trabajos que pueden superar los 15 minutos de ejecución continua sin que ello implique un error de diseño.
Hasta ahora, esos escenarios obligaban a los equipos a elegir entre la comodidad de Lambda y la capacidad de ejecutar tareas prolongadas. Con la nueva modalidad, esa elección deja de ser excluyente.
La advertencia de AWS: más tiempo, más responsabilidad
AWS no ha lanzado la funcionalidad sin advertir de los riesgos. En su artículo “Announcing 90-minute function timeout on AWS Lambda Managed Instances”, la compañía señala que las funciones de larga duración requieren un cuidado adicional con las conexiones de red, las credenciales temporales y la ejecución duplicada. Los desarrolladores deben asegurarse de que las conexiones y credenciales sigan siendo válidas durante todo el tiempo de ejecución, y diseñar las operaciones para manejar reintentos y procesamiento duplicado de forma segura.
Las Durable Functions, el mecanismo de AWS para orquestar flujos de trabajo con estado, también exigen idempotencia, porque los pasos fallidos pueden volver a ejecutarse. Es un recordatorio de que la comodidad de Lambda no elimina la necesidad de pensar en la robustez. Al contrario, cuanto más tiempo se ejecuta una función, más oportunidades hay de que algo salga mal: una conexión que se cae, un token que expira, una operación que se repite sin querer.
Tres modalidades, tres propósitos
AWS ha estructurado su oferta de Lambda en tres formas complementarias. Las funciones tradicionales siguen siendo la opción para cargas de trabajo basadas en eventos, con un límite de 15 minutos. Las MicroVMs están diseñadas para ejecutar código generado por usuarios o por IA, con una duración de hasta ocho horas. Y las Lambda Managed Instances, la novedad, extienden el modelo a cargas de trabajo en estado estacionario, permitiendo múltiples solicitudes por instancia y acceso a precios y opciones de cómputo basados en EC2, pero sin necesidad de gestionar la infraestructura.
Rajesh Pandey, ingeniero principal de AWS, lo resumió con una sinceridad que refleja la frustración acumulada de años: “He perdido la cuenta de cuántas veces los clientes han preguntado cuándo vais a construir funciones Lambda de larga duración. Por fin está aquí. Gran parte del ‘duct tape’ que se construyó alrededor de la duración máxima de ejecución de Lambda ahora puede retirarse”.
La reacción de la comunidad: entusiasmo con reservas
La recepción de la comunidad ha sido mayoritariamente positiva. Los desarrolladores que han lidiado durante años con las limitaciones de Lambda celebran poder simplificar sus despliegues y eliminar las soluciones improvisadas que se acumulaban alrededor del límite de 15 minutos. Sin embargo, no faltan las voces que advierten de los riesgos.
Algunos señalan que la ampliación del tiempo de ejecución podría fomentar patrones frágiles y costosos. Una función que corre durante 90 minutos consume recursos de forma continua, y si falla al minuto 89, el coste ya se ha incurrido sin que el trabajo se haya completado. La tentación de usar Lambda para todo, sin evaluar si es la herramienta adecuada, es real. Y en un contexto donde el coste de la computación en la nube es una preocupación creciente para muchas empresas, esa tentación puede salir cara.
El futuro de serverless: menos límites, más matices
La ampliación del tiempo de ejecución de Lambda es un paso más en la evolución de lo que significa “sin servidores”. Durante años, el término implicaba una serie de restricciones: ejecuciones cortas, sin estado, orientadas a eventos. Pero esas restricciones se han ido relajando. Hoy, serverless abarca desde funciones de milisegundos hasta MicroVMs de ocho horas, desde procesos efímeros hasta cargas de trabajo en estado estacionario.
Esa flexibilidad es una buena noticia para los desarrolladores, que tienen más opciones para elegir la herramienta adecuada para cada tarea. Pero también es un recordatorio de que la comodidad no sustituye al criterio. Lambda con 90 minutos de ejecución no es una invitación a ignorar los principios del buen diseño: idempotencia, manejo de errores, gestión de credenciales y evaluación de costes siguen siendo tan importantes como siempre.
AWS ha eliminado una barrera técnica. Ahora les toca a los desarrolladores decidir si esa barrera era lo único que les impedía usar Lambda para trabajos largos, o si había otras razones —arquitectónicas, económicas, operativas— que justificaban buscar alternativas. La respuesta no es única, y dependerá de cada caso. Pero el hecho de que la pregunta pueda formularse sin la restricción de los 15 minutos es, en sí mismo, un avance significativo.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.
