Procesos que esperan: por qué las Lambda durable functions cambian cómo automatizamos
AWS ha completado el despliegue de las durable functions en Lambda: workflows que se pausan hasta un año sin servidores encendidos. Qué resuelven, qué cobran y cuándo Step Functions sigue ganando.
La mayoría de las automatizaciones que montamos para empresas medianas no se parecen a un pipeline de Big Tech. Se parecen a esto: llega un pedido, hay que validarlo, alguien tiene que aprobarlo, se genera una factura, se espera al pago, se notifica. Entre paso y paso pueden pasar minutos, días o semanas. El trabajo de cómputo es trivial; lo difícil siempre ha sido esperar bien.
Hasta ahora, en AWS tenías tres formas de esperar, y las tres cobraban peaje. Un servidor (o contenedor) siempre encendido que hace polling: pagas 24/7 por un proceso que trabaja el 2% del tiempo. Un cron que revisa estados en una base de datos: funciona, pero acabas escribiendo a mano toda la maquinaria de “¿por dónde iba?”, reintentos y casos raros — y esa maquinaria es donde viven los bugs. O Step Functions: la opción seria, a cambio de definir tu proceso como una máquina de estados en ASL, un lenguaje JSON que tu equipo no usa para nada más.
AWS lleva unos meses empujando una cuarta vía y esta semana la ha completado. Las durable functions de Lambda — anunciadas en diciembre de 2025, con SDKs para JavaScript/TypeScript y Python, Java desde abril — cerraron el círculo el 23 de julio con la disponibilidad general del SDK para .NET, como recogía el roundup semanal de AWS del 27 de julio. Ya no hay runtime mayoritario fuera. Es el momento de decidir si te afecta.
Qué es exactamente una durable function
Es una función Lambda normal en la que escribes tu workflow como código secuencial — sin máquina de estados, sin orquestador externo — y el SDK lo vuelve tolerante a fallos mediante checkpoints y replay: cada operación durable (un paso, una espera, una llamada a otra función) queda registrada con sus entradas y resultados. Si la ejecución se interrumpe — un fallo, un despliegue, o simplemente una espera larga — al reanudarse el código se re-ejecuta desde el principio, pero las operaciones ya completadas no se repiten: se sustituyen por su resultado guardado.
Las piezas que trae el SDK son las que cualquiera que haya montado esto a mano reconocerá: steps con reintentos configurables, waits que suspenden la ejecución hasta un año sin consumir cómputo, callbacks para pausar hasta que una persona (o un agente) responda, invocación fiable de otras Lambdas, y parallel/map para ramificar. Hay además un emulador local para desarrollo, algo que Step Functions tardó años en tener de forma decente.
La lista de casos de uso que cita AWS — procesamiento de pagos, orquestación de agentes de IA, aprobaciones con humano en el bucle — es exactamente el catálogo de automatización de una pyme.
Lo que esto cambia en la práctica
Para nosotros el cambio no es de capacidad — todo esto ya se podía hacer — sino de dónde queda el punto de entrada razonable. Antes, un workflow con esperas largas justificaba Step Functions casi por defecto, con su curva de aprendizaje y su fricción de desarrollo. Ahora el caso típico — proceso secuencial, algunas esperas, un par de aprobaciones — se resuelve con código normal en el lenguaje que tu equipo ya usa, versionado en el mismo repo que el resto de tu backend, testeable en local.
Y hay un caso donde encaja especialmente bien: los agentes de IA con supervisión humana. Un agente que prepara un borrador, espera aprobación y continúa es, estructuralmente, un workflow con un callback en medio. Que la espera de la aprobación no cueste cómputo y sobreviva a despliegues es justo lo que este modelo regala.
Lo que hay que mirar antes de firmar
El determinismo es una regla, no una sugerencia. El replay exige que tu código produzca lo mismo con las mismas entradas: nada de timestamps, aleatorios o lecturas de estado externo fuera de un step. Es un hábito que se aprende rápido, pero el primer bug de replay de tu equipo va a ser confuso.
Los checkpoints se cobran. Cada operación durable factura por escritura y retención de datos: un map sobre mil elementos son más de mil checkpoints, y un WaitForCondition con polling agresivo suma en cada iteración. Para workflows de decenas de pasos es irrelevante; para fan-outs masivos, haz números antes — igual que ya hacías con las transiciones de estado de Step Functions.
Es lock-in ligero, pero lock-in. Tu lógica queda escrita contra el SDK de AWS. El código es más portable que una definición ASL — es tu lenguaje, con tus tests — pero la semántica de checkpoint/replay no viaja gratis a otro proveedor.
Step Functions no ha muerto. Sigue ganando cuando el valor está en la orquestación visible: auditoría visual del proceso para gente no técnica, integraciones directas con decenas de servicios sin escribir código, workflows que cruzan equipos o cuentas. Si tu proceso es más diagrama que código, sigue siendo su terreno.
Nuestro criterio
Para procesos de negocio con esperas — aprobaciones, facturación, onboarding, agentes con humano en el bucle — las durable functions son desde ya nuestra opción por defecto en AWS: menos piezas, menos infraestructura dedicada a “recordar por dónde iba”, y el workflow vive en el mismo lenguaje y repo que todo lo demás. Mantenemos Step Functions para orquestación entre sistemas y para procesos donde el diagrama es el entregable. Y si hoy tienes un servidor encendido cuya única función es esperar y hacer polling, este es probablemente el mejor motivo del año para jubilarlo.
Fuentes: AWS — anuncio de durable functions (dic. 2025) · AWS — Durable Execution SDK para .NET GA (23 jul. 2026) · AWS Weekly Roundup (27 jul. 2026) · Documentación del Durable Execution SDK