AWS Durable Execution SDK for Rust
Build reliable, long-running workflows on AWS Lambda with automatic checkpointing and replay.
Overview
The AWS Durable Execution SDK enables Rust developers to build workflows that survive Lambda restarts, timeouts, and failures. Every operation is automatically checkpointed — if Lambda restarts, execution resumes from the last completed step. Replayed operations return cached results instantly. Workflows can run for up to one year, pausing and resuming seamlessly.
Installation
[]
= "0.1"
= { = "1.0", = ["full"] }
= { = "1.0", = ["derive"] }
Quick start
use ;
use ;
async
Core operations
| Operation | Description |
|---|---|
step() / step_named() |
Execute and checkpoint a unit of work |
wait() |
Pause execution for a duration (suspends Lambda) |
wait_for_condition() |
Poll a condition with configurable retry |
create_callback() / wait_for_callback() |
Wait for external systems to signal completion |
invoke() |
Call other durable Lambda functions |
map() |
Process collections in parallel with concurrency limits |
parallel() |
Execute multiple independent operations concurrently |
run_in_child_context() |
Create isolated nested workflows |
all() / any() / race() / all_settled() |
Promise-style combinators |
Step semantics
Two execution modes for different use cases:
AtLeastOncePerRetry(default) — Checkpoint after execution. May re-execute on interruption, but result is always persisted.AtMostOncePerRetry— Checkpoint before execution. Guarantees at-most-once execution for non-idempotent operations.
use ;
let config = StepConfig ;
let result = ctx.step.await?;
Parallel processing
use MapConfig;
let results = ctx.map.await?;
Callbacks
use CallbackConfig;
// Recommended: wait_for_callback combines creation with replay-safe notification
let approval: ApprovalResponse = ctx.wait_for_callback.await?;
Retry strategies
use ;
let config = StepConfig ;
Error handling
use DurableError;
// Execution errors (workflow fails, no Lambda retry)
execution;
// Invocation errors (triggers Lambda retry)
invocation;
Logging
ctx.log_info;
ctx.log_info_with;
All log messages automatically include durable_execution_arn, operation_id, parent_id, and is_replay for correlation.
Replay-safe helpers
use ;
// Deterministic UUID (same inputs = same UUID across replays)
let uuid = uuid_string_from_operation;
// Replay-safe timestamp (execution start time, not wall clock)
let ts = timestamp_from_execution;
Duration support
use Duration;
let d = from_seconds;
let d = from_minutes;
let d = from_hours;
let d = from_days;
let d = from_weeks; // 14 days
let d = from_months; // 90 days
let d = from_years; // 365 days
Execution limits
| Limit | Value |
|---|---|
| Maximum execution duration | 1 year |
| Maximum wait duration | 1 year |
| Minimum wait duration | 1 second |
| Maximum response payload | 6 MB |
| Maximum checkpoint payload | 256 KB |
| Maximum history size | 25,000 operations |
Crate structure
| Crate | Description |
|---|---|
durable-execution-sdk |
Core SDK with context, handlers, and client |
durable-execution-sdk-macros |
#[durable_execution] proc macro |
durable-execution-sdk-testing |
Local and cloud test runners |
Documentation
- Determinism Guide — Writing replay-safe workflows
- Limits Reference — Execution constraints
- Tracing Guide — Logging configuration and best practices
License
Apache-2.0