AWS has made its Lambda Durable Execution SDK generally available for.NET, giving C# teams a supported way to build long-running, stateful workflows alongside Python, TypeScript and Java. The practical change is narrower than “workflow code disappears”: teams can reconsider how much checkpointing and recovery machinery they still need to maintain themselves.
For.NET teams, that distinction matters. Workflow recovery code often begins as a sensible safeguard, then grows into a second system around the business process: progress records, retry counters, duplicate-work protection, resume branches and operational scripts for jobs that stopped halfway through.
AWS Durable Execution changes the ownership question. Some of that machinery may now belong to the platform. The application team still owns workflow semantics, failure policy and side-effect safety.
What became available to.NET teams
The release adds C# support to the generally available AWS Lambda Durable Execution SDK. According to AWS,.NET now joins Python, TypeScript and Java as a supported language for long-running, stateful workflows.
That is the reported fact. The important analysis starts with what “stateful” means for application design.
A conventional Lambda invocation is a poor place to keep durable progress in memory. If a process spans multiple steps, waits or retries, developers usually need an external record of what completed and enough code to reconstruct the next action. Durable execution offers a platform-managed model for preserving workflow progress across a longer-running operation.
For a C# team that already built its own recovery layer, adoption is therefore an architecture decision rather than a package installation. Existing checkpoint tables and resume handlers may encode years of production lessons. Replacing them safely requires understanding which parts are generic execution plumbing and which parts protect business rules.
The general availability label also deserves precise reading. It indicates that AWS has moved the.NET SDK beyond a preview stage. It does not prove that every existing workflow should migrate, or that the service matches the latency, cost, regional and operational requirements of a particular system. As with any platform announcement, read the support status separately from the fit assessment. Our guide to what “deprecated” actually means in a platform changelog applies the same discipline in the opposite direction.
The code you may be able to stop owning
The best migration candidates are likely to contain substantial code whose only purpose is remembering progress and resuming execution. Look for workflow records updated after each stage, hand-built state machines, polling loops and recovery commands that operators run after an interrupted process.
Do not delete those components merely because the SDK now exists. First classify them.
Some code records technical progress: step three completed, step four is waiting, retry two failed. That is the category most directly challenged by a durable execution service.
Other code enforces business correctness: never charge twice, do not issue an entitlement before payment settles, reject a stale approval, or stop after a cancellation. Those protections remain application responsibilities even when the platform remembers where execution paused.
This boundary is easy to miss because technical recovery and business idempotency often sit in the same method. A durable runtime may resume the workflow correctly while an external API receives the same request twice. Checkpointing reduces one class of uncertainty. It does not automatically make every side effect safe.
The useful question for code review is specific: “Does this branch exist because the business process requires it, or because our runtime previously could not preserve execution state?” The answer identifies code that may become optional without treating the entire orchestration layer as disposable.
General availability does not remove operational work
Platform-managed durability changes failure modes; it does not remove them. Teams still need to know what operators can see when execution pauses, how retries behave, which errors stop a workflow and how deployments affect work already in progress.
Those questions should be answered before production migration. Otherwise, internally managed recovery code can be replaced by a managed system the on-call team understands less well.
Start with one bounded workflow and deliberately interrupt it at each meaningful stage. Verify the persisted state, retry behavior and external side effects. Then change the deployed code while an execution remains active and observe what happens. A green deployment check does not establish that an in-flight workflow can finish safely, as the distinction in Green Checks, Dead Application makes clear.
Cost also needs measurement under realistic waiting, retry and execution patterns. The supplied announcement establishes language support and general availability, not the economics of a specific workload. Treat any cost conclusion as an item for testing.
The next Friday should begin with an inventory
Before the next recovery window, search the.NET codebase for checkpoint writes, resume switches, retry counters, status polling and operator-only repair commands. Map each one to the failure it addresses.
Keep controls that enforce business invariants. Mark generic progress persistence and reconstruction logic as migration candidates. Run a small workflow through forced failures, document what the platform records, and require the on-call owner to recover it without help from the implementation team.
If that exercise works, the first deletion should be modest and reversible. Remove one redundant checkpoint path, retain observability around the workflow and compare the operational result. The value of the.NET release will show up in code the team can safely stop owning, not in the number of workflows renamed “durable.”
Sources
AWS announcement referenced in the supplied current CLI web research: Lambda Durable Execution SDK general availability for.NET.
Comments
No comments yet.