AWS Lambda Durable Functions

Build resilient multi-step applications and AI workflows that can execute for up to 1 year while maintaining reliable progress despite interruptions.

Works best with the AWS MCP server (opens in a new tab) but is not required. All AWS interactions in this skill use standard AWS CLI commands that work in any environment with configured AWS credentials.

Critical Rules

Read these before writing any code. Each one is a constraint that will silently break a function if violated.

1. Durable execution must be enabled at function creation time — it cannot be retrofitted. A new Lambda function must be created with durable execution turned on. Migrate the logic into the new function; do not attempt to install the SDK and wrap the handler of the existing function and expect it to work.
2. Durable functions must be invoked with a qualified ARN — a specific version, an alias, or the literal $LATEST suffix. An unqualified function name will fail. See the Invocation Requirements section below for examples.
3. Durable operations cannot be nested. You cannot call context.step(), context.wait(), or context.invoke() from inside another step’s callback. Use context.runInChildContext() to group operations instead.
4. All non-deterministic code must run inside steps. Date.now(), Math.random(), UUID generation, API calls, and database queries outside a step will produce different values on replay and corrupt execution state.
5. Closure mutations are lost on replay - return values from steps
6. Side effects outside steps repeat - use context.logger (replay-aware)

When to Load Reference Files

Load the appropriate reference file based on what the user is working on:

• Getting started, basic setup, example, ESLint, or Jest setup -> see getting-started.md (opens in a new tab)
• Understanding replay model, determinism, or non-deterministic errors -> see replay-model-rules.md (opens in a new tab)
• Creating steps, atomic operations, or retry logic -> see step-operations.md (opens in a new tab)
• Waiting, delays, callbacks, external systems, or polling -> see wait-operations.md (opens in a new tab)
• Parallel execution, map operations, batch processing, or concurrency -> see concurrent-operations.md (opens in a new tab)
• Error handling, retry strategies, saga pattern, or compensating transactions -> see error-handling.md (opens in a new tab)
• Advanced error handling, timeout handling, circuit breakers, or conditional retries -> see advanced-error-handling.md (opens in a new tab)
• Testing, local testing, cloud testing, test runner, or flaky tests -> see testing-patterns.md (opens in a new tab)
• Deployment, CloudFormation, CDK, SAM, log groups, deploy, or infrastructure -> see deployment-iac.md (opens in a new tab)
• Advanced patterns, GenAI agents, completion policies, step semantics, or custom serialization -> see advanced-patterns.md (opens in a new tab)
• troubleshooting, stuck execution, failed execution, debug execution ID, execution history, execution error, why did my execution fail, execution timed out, callback not received, diagnose execution, or root cause execution -> see troubleshooting-executions.md (opens in a new tab)

Quick Reference

Basic Handler Pattern

TypeScript:

import { withDurableExecution, DurableContext } from '@aws/durable-execution-sdk-js';

export const handler = withDurableExecution(async (event, context: DurableContext) => {
  const result = await context.step('process', async () => processData(event));
  return result;
});

Python:

from aws_durable_execution_sdk_python import durable_execution, DurableContext

@durable_execution
def handler(event: dict, context: DurableContext) -> dict:
    result = context.step(lambda _: process_data(event), name='process')
    return result

Python API Differences

The Python SDK differs from TypeScript in several key areas:

• Steps: Use @durable_step decorator + context.step(my_step(args)), or inline context.step(lambda _: ..., name='...'). Prefer the decorator for automatic step naming.
• Wait: context.wait(duration=Duration.from_seconds(n), name='...')
• Exceptions: ExecutionError (permanent), InvocationError (transient), CallbackError (callback failures)
• Testing: Use DurableFunctionTestRunner class directly - instantiate with handler, use context manager, call run(input=...)

Invocation Requirements

Durable functions require qualified ARNs (version, alias, or $LATEST):

# Valid
aws lambda invoke --function-name my-function:1 output.json
aws lambda invoke --function-name my-function:live output.json

# Invalid - will fail
aws lambda invoke --function-name my-function output.json

IAM Permissions

Your Lambda execution role MUST have the AWSLambdaBasicDurableExecutionRolePolicy managed policy attached. This includes:

• lambda:CheckpointDurableExecution - Persist execution state
• lambda:GetDurableExecutionState - Retrieve execution state
• CloudWatch Logs permissions

Additional permissions needed for:

• Durable invokes: lambda:InvokeFunction on target function ARNs
• External callbacks: Systems need lambda:SendDurableExecutionCallbackSuccess and lambda:SendDurableExecutionCallbackFailure

Validation Guidelines

When writing or reviewing durable function code, ALWAYS check for these replay model violations:

1. Non-deterministic code outside steps: Date.now(), Math.random(), UUID generation, API calls, database queries must all be inside steps
2. Nested durable operations in step functions: Cannot call context.step(), context.wait(), or context.invoke() inside a step function — use context.runInChildContext() instead
3. Closure mutations that won’t persist: Variables mutated inside steps are NOT preserved across replays — return values from steps instead
4. Side effects outside steps that repeat on replay: Use context.logger for logging (it is replay-aware and deduplicates automatically)

When implementing or modifying tests for durable functions, ALWAYS verify:

1. All operations have descriptive names
2. Tests get operations by NAME, never by index
3. Replay behavior is tested with multiple invocations
4. Use LocalDurableTestRunner for local testing

Security Considerations

• Checkpoint data encryption: Execution state is persisted automatically. Enable KMS encryption on associated CloudWatch Log Groups to protect checkpointed data at rest.
• Sensitive data in step results: Step return values are checkpointed and persisted. Do not return secrets, raw credentials, or PII from steps — store sensitive data in Secrets Manager or SSM Parameter Store and return references instead.
• Input validation: Validate and sanitize event payloads at the handler entry point before passing data to steps.
• Credential management: Retrieve secrets from AWS Secrets Manager or SSM Parameter Store within steps.
• Callback payload validation: Data received via waitForCallback originates from external systems — validate and sanitize before processing.
• Logging: Avoid DEBUG log level in non-development environments as it may expose step results and execution state. Enable CloudWatch Logs encryption with KMS.

Resources

• AWS Lambda durable functions Documentation (opens in a new tab)
• JavaScript SDK Repository (opens in a new tab)
• Python SDK Repository (opens in a new tab)
• IAM Policy Reference (opens in a new tab)