# Lambda Durable Execution (.NET) vs Step Functions vs EventBridge Scheduler (2026)

Anchors: [Lambda Durable Execution SDK for .NET GA (Jul 23, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/lambdadf-dotnet/), [C# SDK reference](https://docs.aws.amazon.com/durable-execution/sdk-reference/languages/csharp/), [Step Functions workflow types](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-standard-vs-express.html).

Score each candidate workflow **0–2** per column (0 = poor fit, 2 = strong fit). Highest column wins; ties favor the option your team already operates in production.

| Signal | Durable Lambda (.NET) | Step Functions (Standard) | Step Functions (Express) | EventBridge Scheduler only |
|--------|----------------------|---------------------------|--------------------------|----------------------------|
| Workflow logic lives in C# with strong typing | **2** | 0 (ASL / JSONPath) | 0 | 0 |
| Human-in-the-loop pause up to 1 year | **2** (`WaitForCallbackAsync`) | **2** (Task Token) | 0 (5 min max) | 0 |
| Visual ops / non-dev workflow edits | 0 | **2** (Workflow Studio) | **2** | 1 (cron only) |
| 20+ native AWS service integrations without custom code | 0 | **2** (optimized integrations) | **2** | 0 |
| High-volume short orchestration (>100k/day, <5 min) | 1 | 0 (transition cost) | **2** | 0 |
| Payment / saga with compensation in application code | **2** | **2** (Catch / Parallel) | 1 | 0 |
| AI agent multi-step with tool loops in one runtime | **2** | 1 (many Lambdas + ASL) | 0 | 0 |
| Org already standardized on SFN + CloudWatch execution history | 0 | **2** | **2** | 0 |
| One-shot delayed invocation (no state machine) | 0 | 0 | 0 | **2** |
| Need exactly-once audit trail in console without custom logging | 0 | **2** | 1 (CW Logs) | 0 |
| Team is Python/Node-only today | 0 (use durable SDK there) | 1 | 1 | 1 |
| .NET shop; Python/Node durable already in sibling services | **2** | 1 | 1 | 0 |

## Opinionated default (Jul 2026)

1. **New .NET multi-step workflow in a C# codebase** → prototype with **Durable Lambda** (`Amazon.Lambda.DurableExecution` + `DurableFunction.WrapAsync`). Keep orchestration in the same repo as domain logic.
2. **Cross-team visibility, compliance audit, or heavy AWS integration fan-out** → **Step Functions Standard** unless Express latency/volume math clearly wins.
3. **Fire-and-forget at a future time** with no branching → **EventBridge Scheduler** — do not stand up a state machine for a single delayed Lambda invoke.

## When NOT to pick durable .NET Lambda

- Workflow owners are primarily PMs / ops editing ASL in the console.
- You need **Express** throughput with sub-second fan-out across dozens of service integrations.
- Steps are mostly **declarative AWS API calls** (Glue start, EMR run, DynamoDB update) with little custom C# — ASL is thinner than maintaining handler replay semantics.
- Team has **not** internalized durable **replay**: step bodies must be deterministic and side-effect safe on retry.
- You invoke with **`$LATEST`** in production — replays can diverge after code deploy (use a **published version or alias**).

## When NOT to pick Step Functions

- The workflow is already a single Lambda with clear `StepAsync` boundaries and the team wants one deployable unit.
- Transition billing dominates (many micro-states, high daily volume) and Express does not fit duration/integration needs.
- Human wait is implemented but **all** business rules change weekly in C# — ASL drift becomes a second codebase.

## Pricing dimensions to compare (verify current pages)

| Option | Bill mainly on |
|--------|----------------|
| Durable Lambda | Lambda duration (active compute) + durable operations / checkpoint storage; **wait time does not bill duration** on on-demand |
| Step Functions Standard | State transitions (~$0.025 / 1k transitions) |
| Step Functions Express | Requests + duration |
| EventBridge Scheduler | Scheduler invocations (plus target Lambda cost) |

Run your own estimate — do not copy round-number “example workloads” from blog posts.