AWS Builder Center

Builder Center

Set up AWS Lambda Durable Functions through the AWS Console

Set up AWS Lambda Durable Functions through the AWS Console

Series: Financial Service (19 articles)

  1. 1
    AWS Lambda MicroVMs and the End of Repeated Application Cold Initialization
  2. …
  3. 6
    Set up AWS Lambda Durable Functions through the AWS Console This article
  4. 7
    Serverless Small Language Models for Pre-Market Intelligence on AWS Lambda [1]

Martin

Dev @ Vertex Macro

Set up AWS Lambda Durable Functions through the AWS Console

This walkthrough creates a working AWS Lambda Durable Function with checkpointed steps, a durable wait, automatic replay, a published version, and observable execution history. It uses Node.js because the function can be created, edited, deployed, and tested entirely through the AWS Management Console.
Durable execution must be enabled when the Lambda function is created. It cannot currently be enabled on an existing Lambda function.

Select an AWS Region

Sign in to the AWS Management Console and select an AWS Region in which Lambda Durable Functions is available.
For a production financial-services workload, select the Region only after checking data-residency requirements, connectivity to downstream systems, broker or payment-service latency, business-continuity design, service quotas, and current feature availability.

Create the Durable Function

Open the Lambda Functions console.
Choose:
1
Create function
Select:
1
Author from scratch
Enter the following basic information:
1
2
3
Function name: myDurableFunction
Runtime: Node.js 24
Architecture: x86_64
Select:
1
Enable durable execution
Under permissions, select:
1
Create a new role with basic Lambda permissions
Then choose:
1
Create function
The console-created execution role includes the checkpoint permissions needed by the function:
1
2
lambda:CheckpointDurableExecution
lambda:GetDurableExecutionState
The role also needs permission to write to Amazon CloudWatch Logs. The console normally creates these permissions automatically for this setup.

Review the Durable Execution Configuration

Inside the function, open:
1
Configuration
Locate the durable execution settings. Depending on the current console layout, these may appear under a dedicated Durable configuration section.
Configure an appropriate execution timeout and history retention period.
For this demonstration, use:
1
2
Execution timeout: 1 hour
History retention: 7 days
The execution timeout applies to the entire durable execution, including waits and resumptions. It is different from the standard timeout of an individual Lambda invocation.
The supported durable execution timeout range is 1 to 31,622,400 seconds, approximately one year. Completed execution history can be retained for 1 to 90 days, with a documented default of 14 days.
For a production financial workflow, do not automatically select one year. Set the timeout according to the longest valid business lifecycle. A trade-approval workflow, for example, might use several hours, while an account-opening process might require several days.
If the console offers encryption configuration, you may select an AWS KMS customer-managed key. Lambda always encrypts durable execution data at rest, while a customer-managed key provides additional control over permissions, rotation, and audit visibility. The durable-execution key is distinct from the Lambda function key used for environment variables and deployment packages.

Add the Durable Function Code

Open the Code tab.
Select:
1
index.mjs
Replace the default code with the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
import {
withDurableExecution,
} from "@aws/durable-execution-sdk-js";

export const handler = withDurableExecution(
async (event, context) => {
const orderId = event.orderId;

const validationResult = await context.step(
"validate-order",
async (stepContext) => {
stepContext.logger.info(
`Validating order ${orderId}`
);

if (!orderId) {
throw new Error("orderId is required");
}

return {
orderId,
status: "validated",
};
}
);

const paymentResult = await context.step(
"process-payment",
async (stepContext) => {
stepContext.logger.info(
`Processing payment for order ${orderId}`
);

return {
orderId,
status: "paid",
amount: 99.99,
currency: "USD",
};
}
);

await context.wait(
"wait-for-external-confirmation",
{
seconds: 10,
}
);

const confirmationResult = await context.step(
"confirm-order",
async (stepContext) => {
stepContext.logger.info(
`Confirming order ${orderId}`
);

return {
orderId,
status: "confirmed",
};
}
);

return {
orderId,
status: "completed",
steps: [
validationResult,
paymentResult,
confirmationResult,
],
};
}
);
Choose:
1
Deploy
Supported Lambda runtimes include the Durable Execution SDK, which makes console testing possible without manually packaging the SDK. For production deployment, AWS recommends packaging an explicitly tested SDK version with the application to avoid unexpected behavior caused by runtime SDK-version changes.

Understand What the Code Does

The following wrapper enables durable execution:
1
withDurableExecution(...)
It supplies a durable context instead of relying solely on the standard Lambda context.
Each call to:
1
context.step(...)
creates a durable operation. When the step finishes, Lambda checkpoints its result. If the function is interrupted or resumed, the SDK returns the persisted result instead of running the completed step again.
The following operation creates a durable suspension:
1
2
3
4
5
6
await context.wait(
"wait-for-external-confirmation",
{
seconds: 10,
}
);
During the wait, the active invocation ends. When the wait expires, Lambda starts another invocation and replays the function from the beginning. The completed validation and payment results come from their checkpoints, so those steps are skipped rather than executed again. Durable waits do not consume Lambda compute duration while suspended.

Publish a Stable Version

Do not use only $LATEST for a production durable execution. A workflow can remain suspended for a long time, so it must resume against a stable code version.
Open:
1
Versions
Choose:
1
Publish new version
Enter:
1
Version description: Initial durable function version
Choose:
1
Publish
Lambda creates version 1. Its qualified ARN ends with:
1
:1
AWS recommends invoking a qualified ARN pointing to a stable version for deterministic execution. Infrastructure-as-code deployments of Durable Functions also require a published version or alias for qualified use.
For production, create an alias:
1
2
Alias name: prod
Version: 1
Your application should invoke the prod alias instead of invoking $LATEST.

Create a Console Test Event

Return to the Code or Test section.
Choose:
1
Create test event
Enter:
1
Event name: myTestEvent
Use the following JSON:
1
2
3
{
"orderId": "order-12345"
}
Save the event and choose Test.
The initial invocation validates the order, checkpoints the validation result, processes the simulated payment, checkpoints the payment result, enters the ten-second durable wait, ends the active Lambda invocation, resumes through a new invocation, replays the function, returns stored results for completed steps, runs the confirmation step, and returns the completed result.

Inspect the Durable Execution

Open the function's:
1
Durable executions
Find the new execution. Its status should move through states such as:
1
2
3
Running
Succeeded
Failed
Choose the execution ID.
The execution view should show the execution timeline, completed durable steps, checkpoint history, wait period, step results, final output, errors if any, and logs created through the durable context logger.
The expected output is similar to:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"orderId": "order-12345",
"status": "completed",
"steps": [
{
"orderId": "order-12345",
"status": "validated"
},
{
"orderId": "order-12345",
"status": "paid",
"amount": 99.99,
"currency": "USD"
},
{
"orderId": "order-12345",
"status": "confirmed"
}
]
}

Inspect CloudWatch Logs

Open the Amazon CloudWatch console.
Navigate to:
1
2
3
Logs
Log groups
/aws/lambda/myDurableFunction
Open the newest log streams.
You should find separate Lambda invocation records for the initial execution before the wait and the resumed execution after the wait.
When you use context.logger or stepContext.logger, those messages can also appear in the Lambda durable execution and step views.

Verify Replay Behavior

To understand replay, inspect the logs and execution history carefully.
Your business code starts from the beginning after the wait, but completed durable operations should not execute their business logic again. Instead, their checkpointed results are injected into the replay.
This means that code outside durable operations must remain deterministic.
Do not write this directly in the replay path:
1
2
const requestId = crypto.randomUUID();
const timestamp = Date.now();
Those expressions return different values during replay.
Place non-deterministic work inside context.step():
1
2
3
4
5
6
7
8
9
const identity = await context.step(
"create-order-identity",
async () => {
return {
requestId: crypto.randomUUID(),
timestamp: new Date().toISOString(),
};
}
);
The generated values are checkpointed and reused during replay.

Verify IAM Permissions

Open the function's:
1
2
3
Configuration
Permissions
Execution role
Open the linked AWS IAM role.
Verify that it includes the basic durable execution permissions. The relevant minimum actions are:
1
2
3
4
5
6
7
8
{
"Effect": "Allow",
"Action": [
"lambda:CheckpointDurableExecution",
"lambda:GetDurableExecutionState"
],
"Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:myDurableFunction:*"
}
The resource ARN must include a qualifier pattern such as :*. An unqualified function ARN does not match the durable execution sub-resource. The console normally handles these execution-role permissions when it creates the Durable Function.
Users or operational roles that need to inspect or stop executions may also require:
1
2
3
4
lambda:GetDurableExecution
lambda:GetDurableExecutionHistory
lambda:ListDurableExecutionsByFunction
lambda:StopDurableExecution
These management permissions should be granted separately using least privilege.

Production Hardening

Use business idempotency

A completed broker or payment API call might occur immediately before a failure that prevents the success result from being checkpointed. The step may therefore be attempted again.
Generate a stable business identifier in an earlier checkpointed step:
1
2
3
4
5
6
const identity = await context.step(
"create-identity",
async () => ({
clientOrderId: crypto.randomUUID(),
})
);
Pass that same identifier to every retry of the external system.

Keep checkpoint data small

Do not checkpoint complete order-book histories, large model prompts, documents, or large API responses.
Store large objects in Amazon S3, Amazon DynamoDB, or an approved external system of record.
Checkpoint only a compact reference:
1
2
3
4
5
6
{
"bucket": "fsi-workflow-evidence",
"key": "orders/order-12345/snapshot.json",
"sha256": "content-hash",
"version": "v1"
}
Large state increases storage cost and can affect performance.

Set explicit wait and callback timeouts

Human approvals and external callbacks must have deadlines. A missing response should result in a controlled terminal state, escalation, or compensation rather than an indefinitely open workflow.

Revalidate before consequential actions

If execution waits for approval, rerun relevant risk controls immediately before payment or order submission. An approval received hours later should not automatically authorize an action under materially changed market or account conditions.

Preserve old function versions

Do not delete a function version merely because a newer one has been released. Existing durable executions may still be associated with the older version.

Move production deployment to infrastructure as code

The console is suitable for learning and controlled experiments. Production deployments should use AWS CloudFormation, AWS CDK, AWS SAM, Terraform, or another approved infrastructure-as-code system so the function, durable configuration, role, permissions, version, alias, encryption, and alarms are repeatable and reviewable.

Clean Up the Demonstration

When finished, delete the test resources to avoid unnecessary retention and logging charges.
Delete the Lambda function, the automatically created IAM execution role if it is no longer used, the CloudWatch log group, and any customer-managed KMS key created solely for the test according to the organization's key-deletion policy.
To delete the function:
1
2
3
4
5
Lambda console
Functions
Select myDurableFunction
Actions
Delete
Enter:
1
confirm
Then choose Delete.

References

AWS Lambda Developer Guide, "Creating Lambda durable functions," https://docs.aws.amazon.com/lambda/latest/dg/durable-getting-started.html
AWS Lambda Developer Guide, "Lambda durable functions," https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html
AWS Lambda Developer Guide, "Configure Lambda durable functions," https://docs.aws.amazon.com/lambda/latest/dg/durable-configuration.html
AWS Lambda API Reference, "DurableConfig," https://docs.aws.amazon.com/lambda/latest/api/API_DurableConfig.html
AWS Lambda Developer Guide, "Security and permissions for Lambda durable functions," https://docs.aws.amazon.com/lambda/latest/dg/durable-security.html
AWS Lambda Developer Guide, "Encrypting AWS Lambda durable execution data," https://docs.aws.amazon.com/lambda/latest/dg/durable-encryption.html
AWS Lambda Developer Guide, "Deploy Lambda durable functions with Infrastructure as Code," https://docs.aws.amazon.com/lambda/latest/dg/durable-getting-started-iac.html

Series: Financial Service (19 articles)

  1. 1
    AWS Lambda MicroVMs and the End of Repeated Application Cold Initialization
  2. …
  3. 6
    Set up AWS Lambda Durable Functions through the AWS Console This article
  4. 7
    Serverless Small Language Models for Pre-Market Intelligence on AWS Lambda [1]
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article