Workflows that wait: why Lambda durable functions change how we build automations
AWS has completed the rollout of Lambda durable functions: workflows that pause for up to a year with no idle servers. What they solve, what they bill for, and when Step Functions still wins.
Most of the automations we build for mid-sized companies look nothing like a Big Tech data pipeline. They look like this: an order comes in, it gets validated, someone has to approve it, an invoice goes out, the system waits for payment, people get notified. Between steps, minutes or weeks can pass. The compute is trivial; the hard part has always been waiting well.
Until recently, AWS gave you three ways to wait, and each charged its own toll. An always-on server or container doing polling: you pay 24/7 for a process that works 2% of the time. A cron job checking states in a database: it works, but you end up hand-writing all the “where was I?” machinery — retries, resumption, edge cases — and that machinery is where the bugs live. Or Step Functions: the serious option, in exchange for describing your process as a state machine in ASL, a JSON dialect your team uses for nothing else.
For a few months now AWS has been pushing a fourth path, and this past week it was completed. Lambda durable functions — announced in December 2025, with SDKs for JavaScript/TypeScript and Python, Java since April — closed the loop on July 23 with general availability of the .NET SDK, as covered in the AWS Weekly Roundup of July 27. No major runtime is left out. Time to decide whether this affects you.
What a durable function actually is
It’s a regular Lambda function where you write your workflow as plain sequential code — no state machine, no external orchestrator — and the SDK makes it fault-tolerant through checkpointing and replay. Every durable operation (a step, a wait, a call to another function) is recorded along with its inputs and results. If execution is interrupted — a failure, a deployment, or simply a long wait — the code re-runs from the top on resume, but completed operations aren’t executed again: their stored results are substituted in.
The SDK’s building blocks are the ones anyone who has hand-rolled this will recognize: steps with configurable retries, waits that suspend execution for up to a year without consuming compute, callbacks that pause until a person (or an agent) responds, reliable invocation of other Lambdas, and parallel/map for fan-out. There’s also a local emulator for development — something Step Functions took years to get right.
AWS’s own list of use cases — payment processing, AI agent orchestration, human-in-the-loop approvals — reads like the automation backlog of a typical mid-sized business.
What actually changes
For us the shift isn’t about capability — all of this was already possible — but about where the sensible default now sits. A workflow with long waits used to justify Step Functions almost automatically, learning curve included. Now the common case — a sequential process, some waits, a couple of approvals — is solved with ordinary code in the language your team already uses, versioned in the same repo as the rest of your backend, testable locally.
One case fits especially well: AI agents with human supervision. An agent that drafts something, waits for sign-off and then continues is, structurally, a workflow with a callback in the middle. Having that wait cost nothing in compute and survive deployments is exactly what this model gives you for free.
What to check before you commit
Determinism is a rule, not a suggestion. Replay requires your code to produce the same output for the same inputs: no timestamps, random values or external state reads outside a step. It’s a habit teams pick up quickly, but your first replay bug will be a confusing one.
Checkpoints are billed. Every durable operation is metered on data written and retained: a map over a thousand items means over a thousand checkpoints, and an aggressive WaitForCondition polling loop adds up on every iteration. Irrelevant for a workflow of a few dozen steps; for massive fan-outs, run the numbers first — the same discipline Step Functions state transitions already demanded.
It’s light lock-in, but lock-in. Your logic is written against an AWS SDK. Code is more portable than an ASL definition — it’s your language, with your tests — but checkpoint/replay semantics don’t travel to another provider for free.
Step Functions isn’t dead. It still wins when the value lies in visible orchestration: visual audit trails for non-technical stakeholders, direct integrations with dozens of AWS services without glue code, workflows spanning teams or accounts. If your process is more diagram than code, that’s still Step Functions territory.
Where we land
For business processes that wait — approvals, invoicing, onboarding, human-in-the-loop agents — durable functions are now our default on AWS: fewer moving parts, no infrastructure dedicated to remembering where things left off, and the workflow lives in the same language and repo as everything else. We keep Step Functions for cross-system orchestration and for processes where the diagram is the deliverable. And if you’re running a server today whose only job is to wait and poll, this is probably the best reason all year to retire it.
Sources: AWS — durable functions announcement (Dec 2025) · AWS — Durable Execution SDK for .NET GA (Jul 23, 2026) · AWS Weekly Roundup (Jul 27, 2026) · Durable Execution SDK documentation