# AWS Lambda durable functions in GovCloud: setup and limits

> Lambda durable functions reached AWS GovCloud (US-West) and (US-East) on 16 October 2026. What they do, how to set one up, and the limits AWS documents.

By Boris Tane, Founder of Polylane · Published October 17, 2026 · 11 min read
Canonical: https://polylane.com/learn/reliability/aws-lambda-durable-functions-govcloud-availability/

Since 16 October 2026, AWS Lambda durable functions are available in AWS GovCloud (US-West) and AWS GovCloud (US-East). You turn on durable execution when you create a new Lambda function, add the durable execution SDK, and use steps and waits so Lambda saves progress, recovers from failures and pauses without compute charges on on-demand functions. Executions can run for up to one year, but durable execution can't be added to an existing function, and production calls should use a published version or alias.

AWS announced on 16 October 2026 that Lambda durable functions now run in the AWS GovCloud (US-West) and AWS GovCloud (US-East) Regions. Teams in government and regulated industries that must stay inside GovCloud can now build multi-step workflows inside Lambda. AWS gives order processing, user onboarding and AI-assisted tasks as examples. Until now, that meant writing your own state handling or adding a separate orchestration service.

This announcement adds GovCloud. For the programming model, SDKs, limits and gotchas, this page follows the general Lambda Developer Guide, so confirm the details for GovCloud in your own account as you go. Most of this page covers those, plus what to check before you build in a GovCloud account.

## What changed in the 16 October 2026 announcement

The announcement adds two Regions: AWS GovCloud (US-West) and AWS GovCloud (US-East). It says you can enable durable functions on **new** functions for these languages:

- Python 3.13 and 3.14
- Node.js 22 and 24
- Go 1.24 or later
- .NET (the announcement lists version 2.2)
- Java 17 and later

You can enable it through the Lambda API, the AWS Management Console or the AWS SDK. Infrastructure as code works too: AWS CloudFormation, AWS SAM and the AWS CDK.

The announcement's runtime list and the Developer Guide's list don't quite match. The Developer Guide page on supported runtimes lists these managed runtimes: `nodejs22.x`, `nodejs24.x`, `python3.13`, `python3.14`, `java17`, `java21`, `java25`, `dotnet8` and `dotnet10`. It also lists OCI container images for other runtime versions. That page doesn't list a Go managed runtime. If you plan to write in Go or .NET, read the current supported runtimes page and SDK docs for the exact path before you commit to a design. For availability by Region, AWS points to its Capabilities by Region page. Check it for the Region your account runs in.

## What a durable function does: checkpoint and replay

A normal Lambda function runs one invocation from start to finish. If it times out or crashes halfway, the work it already did is lost, and a retry starts from the beginning. A durable function splits the handler into operations. The SDK records the result of each one in a checkpoint log.

The Developer Guide describes how this works:

- **Steps.** Each `context.step()` call writes a checkpoint before and after it runs. Once a step has completed, it never runs again. Lambda reuses its stored result.
- **Waits.** `context.wait()` pauses the execution without using compute. When the wait ends, Lambda invokes your function again.
- **Replay.** On every resume, Lambda runs your handler from the top. Completed steps return their saved results straight from the checkpoint log, so the code moves quickly to the first unfinished operation.
- **Suspension.** Lambda suspends the execution and stops charging for compute during durable waits such as `wait` or `waitForCallback`, and during automatic step retries.

One execution can span many invocations. Lambda gives each execution a unique ID. It ends when the handler returns a final result or throws an unhandled error.

```mermaid alt="How a durable execution checkpoints, suspends, replays and ends, with the failure path to a dead-letter queue"
graph TB
A[Invoke a published version or alias] --> B[Step runs and is checkpointed]
B --> C{Wait or retry needed?}
C -->|yes| D[Execution suspends, no compute]
D --> E[Lambda invokes the function again]
E --> F[Replay skips completed steps]
F --> B
C -->|no| G{Handler finished?}
G -->|returns result| H[Execution succeeds]
G -->|unhandled error| I[Execution fails]
I --> J[Original event goes to the DLQ]
style I fill:#fee2e2,stroke:#fca5a5,color:#7f1d1d
style J fill:#d1fae5,stroke:#6ee7b7,color:#065f46
```

Replay comes with a rule: the Developer Guide says your code must be deterministic. The handler runs again from the top on every resume. Any code outside a step has to do the same thing each time it runs, so put work whose result can change from one run to the next inside a step. Its saved value is then reused on replay.

## How this compares with plain Lambda and Step Functions

Most GovCloud teams that need multi-step work on Lambda today chain functions with queues, store state in a table, or use AWS Step Functions. AWS's own comparison page frames the choice like this:

- **Durable functions** run inside Lambda. You write the workflow in a normal programming language and test it with your usual unit test framework, AWS SAM and the AWS Toolkit. It suits distributed transactions, stateful application logic, function orchestration, data processing and AI workflows.
- **Step Functions** is a separate workflow service. You define workflows in Amazon States Language or the AWS CDK, and there's a visual builder. AWS lists integrations with 220+ AWS services and 16k APIs. It suits workflows that cross many AWS services, or that people outside the engineering team need to read.

AWS's decision rule is short. If the logic lives mostly in Lambda and your team prefers code, use durable functions. If the work coordinates many AWS services, or you want a visual workflow with no runtime to maintain, use Step Functions. You can use both: durable functions for application logic, with Step Functions coordinating the higher-level flow across services. If you already run Step Functions, AWS's advice is to keep those cross-service workflows and try durable functions for new Lambda logic.

## Checks to run in your GovCloud account before you build

Check these before you write any code:

1. **The Region is listed.** Confirm durable functions appear for your GovCloud Region on the AWS Capabilities by Region page.
2. **Your runtime is supported.** Pick a managed runtime from the supported runtimes page, or plan for a container image.
3. **The function is new.** The CLI guide says you can only enable durable execution when you create a function. To give an existing function a durable workflow, you create a new function and move traffic to it.
4. **The execution role has checkpoint permissions.** The role needs `lambda:CheckpointDurableExecution` and `lambda:GetDurableExecutionState`. The AWS managed policy `AWSLambdaBasicDurableExecutionRolePolicy` grants both, along with basic execution permissions.
5. **Your ARNs match your partition.** AWS's examples use commercial ARNs that start with `arn:aws:`. Copy the policy ARN and function ARNs from the IAM and Lambda consoles in your GovCloud account. Don't paste them from the docs.
6. **Everything you chain to is in the same account.** Cross-account chained invocations aren't supported. A durable function can only call another function with `context.invoke` when both are in the same AWS account.

## Creating a durable function from the CLI, step by step

These steps follow AWS's CLI guide. Set your profile and Region first so every command runs against the GovCloud account you mean to use.

### 1. Write the handler with the SDK

This Python handler comes from AWS's getting started guide. It validates an order, takes payment, waits, then confirms:

```python
from aws_durable_execution_sdk_python import (
    DurableContext,
    durable_execution,
    durable_step,
)
from aws_durable_execution_sdk_python.config import Duration

@durable_step
def validate_order(step_context, order_id):
    step_context.logger.info(f"Validating order {order_id}")
    return {"orderId": order_id, "status": "validated"}

@durable_step
def process_payment(step_context, order_id):
    step_context.logger.info(f"Processing payment for order {order_id}")
    return {"orderId": order_id, "status": "paid"}

@durable_step
def confirm_order(step_context, order_id):
    return {"orderId": order_id, "status": "confirmed"}

@durable_execution
def lambda_handler(event, context: DurableContext):
    order_id = event["orderId"]
    validation = context.step(validate_order(order_id))
    payment = context.step(process_payment(order_id))
    context.wait(Duration.from_seconds(10))
    confirmation = context.step(confirm_order(order_id))
    return {"orderId": order_id, "steps": [validation, payment, confirmation]}
```

The Python SDK is synchronous, so there's no `await`. In Node.js you wrap the handler in `withDurableExecution` from `@aws/durable-execution-sdk-js` and `await` each `context.step()`.

### 2. Put the SDK in your deployment package

The Node.js and Python runtimes already include the SDK, but AWS recommends shipping your own copy for production, locked to a major version. Java and .NET runtimes don't include it, so you must package it yourself.

```bash
pip install aws-durable-execution-sdk-python   # Python
npm install @aws/durable-execution-sdk-js      # Node.js
dotnet add package Amazon.Lambda.DurableExecution  # .NET
```

For Java, add the `software.amazon.lambda.durable:aws-durable-execution-sdk-java` dependency to `pom.xml`.

### 3. Create the role and the function

```bash
aws iam create-role \
  --role-name durable-function-role \
  --assume-role-policy-document file://trust-policy.json

# Use the policy ARN shown in your GovCloud IAM console
aws iam attach-role-policy \
  --role-name durable-function-role \
  --policy-arn <AWSLambdaBasicDurableExecutionRolePolicy ARN>

aws lambda create-function \
  --function-name myDurableFunction \
  --runtime python3.13 \
  --role <role ARN> \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://function.zip \
  --durable-config '{"ExecutionTimeout": 3600, "RetentionPeriodInDays": 7}'
```

`ExecutionTimeout` is in seconds. `RetentionPeriodInDays` sets how long Lambda keeps an execution's history after the execution closes.

### 4. Publish a version and an alias

```bash
aws lambda publish-version --function-name myDurableFunction --description "Initial version"
aws lambda create-alias --function-name myDurableFunction --name prod --function-version 1
```

### 5. Invoke it with a qualified name

Use a synchronous call for work that finishes within 15 minutes. Use an asynchronous call for anything that waits longer:

```bash
aws lambda invoke \
  --function-name myDurableFunction:prod \
  --invocation-type Event \
  --cli-binary-format raw-in-base64-out \
  --payload '{"orderId": "order-12345"}' \
  response.json
```

To make sure a retried start doesn't create a second execution, pass an execution name. AWS's Idempotency page covers this.

### 6. Check the execution ran

```bash
aws lambda list-durable-executions-by-function --function-name myDurableFunction
aws lambda get-durable-execution-history --durable-execution-arn <execution ARN>
```

In the console, the function's **Durable executions** tab shows each execution's status (Running, Succeeded or Failed), its step timeline, its checkpoint history and its step results. In CloudWatch Logs, the function's log group shows one entry for the first invocation and another for the replay after the wait.

## Deploying with AWS SAM or CloudFormation

Most GovCloud teams deploy through infrastructure as code. In AWS SAM, durable execution is the `DurableConfig` property on `AWS::Serverless::Function`. SAM passes it straight through to the `DurableConfig` of `AWS::Lambda::Function` in CloudFormation.

```yaml
Resources:
  OrderWorkflow:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.13
      Handler: lambda_function.lambda_handler
      CodeUri: src/
      AutoPublishAlias: prod
      DurableConfig:
        ExecutionTimeout: 3600
        RetentionPeriodInDays: 7
      DeadLetterQueue:
        Type: SQS
        TargetArn: !GetAtt OrderWorkflowDLQ.Arn
  OrderWorkflowDLQ:
    Type: AWS::SQS::Queue
```

The function still needs a role with the durable execution policy attached. Durable execution can only be set when a function is created, so put it on a new logical resource. You can't switch it on for a function that's already deployed.

## The limits AWS documents

- **Execution length.** `ExecutionTimeout` ranges from 1 second to 31,622,400 seconds, which is one 366-day year.
- **History retention.** `RetentionPeriodInDays` ranges from 1 to 90 days. The default is 14.
- **Synchronous calls.** These are capped at 15 minutes, or less if your function or execution timeout is shorter. If the whole execution, waits included, takes longer than that, the call times out.
- **Asynchronous calls.** These support executions of up to one year.
- **Qualified identifiers only.** You must invoke with a version number, an alias or `$LATEST`. A bare function name or unqualified ARN is rejected.
- **Destinations.** Durable functions support dead-letter queues. They don't support Lambda destinations.
- **Chaining.** Chained invocations only work within the same AWS account.
- **Container images.** The maximum uncompressed image size is 10 GB.
- **Event source mappings.** Using event source mappings with durable functions comes with its own details, including execution duration limits, set out on AWS's event source mappings with durable functions page.

## Mistakes that break in-flight durable executions

### Calling $LATEST in production

An execution started on `$LATEST` isn't pinned to the code it started with. If you deploy new code while it's paused, it resumes on the new code. That can cause non-determinism errors or silent failures. **Fix:** invoke a numbered version or an alias. An execution stays on the version it started on, even when you move the alias, so only new executions pick up new code.

### Renaming or changing a step while executions are running

The runtime matches saved state to step definitions. If you rename a step or change what it does, executions that are still running may fail to resume or return wrong results. **Fix:** make new versions able to read state written by older ones, and leave step names alone while older executions are still running.

### Expecting Lambda to retry a failed execution

AWS's best practices page says the service doesn't automatically retry durable executions that fail. This trips up anyone used to standard asynchronous retries. **Fix:** set explicit retry strategies with backoff inside steps. Also set `DeadLetterConfig` to an SQS queue or SNS topic. When an execution started asynchronously ends as FAILED, STOPPED or TIMED_OUT, Lambda sends the original event there.

### Letting a runtime update change the SDK under you

AWS patches managed runtimes, and a patch can ship a new SDK version. A new major version can break executions that are already running. **Fix:** bundle the SDK and lock it to a major version.

### Logic outside steps that changes between runs

Replay runs the handler from the top on every resume. Code outside a step that gives a different answer each time can send the handler down a different path from the one the checkpoint log recorded. **Fix:** move that work into a step so its value is saved and reused.

## Watching durable executions once they're live

A durable execution can run for months, so problems can show up long after the deploy that caused them. AWS's monitoring advice:

- Use structured logs that include the execution ID and step name. The logger on the durable context (`context.logger`, `stepContext.logger`) also shows its output in the console's execution and step views.
- Set CloudWatch alarms on error rate and execution duration, and use tracing to find slow steps.
- Create EventBridge rules for FAILED, STOPPED and TIMED_OUT status changes, so you hear about failures as they happen.
- Alarm on `ApproximateNumberOfMessagesVisible` for the dead-letter queue, so you notice when failed events start piling up.
- Look at checkpoint operations in CloudTrail data events when you need an audit trail.

I built serverless observability at Baselime and on the Workers team at Cloudflare. In both, debugging went fastest when every log line said which unit of work it belonged to. For durable functions, that unit is the execution and the step. Put the execution ID in every log line from the first day, because one execution's log lines are spread across many invocations.

Running on AWS? See [how Polylane monitors AWS in production](https://polylane.com/for/aws/).

## Common questions

**Which GovCloud Regions support Lambda durable functions?**

AWS GovCloud (US-West) and AWS GovCloud (US-East), as of the AWS announcement on 16 October 2026. For the current list, AWS points to its Capabilities by Region page.

**Can I turn on durable execution for an existing Lambda function?**

No. AWS's CLI guide says you can only enable durable execution when you create the function. Create a new function with DurableConfig set, then move callers to it.

**How long can a durable execution run?**

Up to one year. ExecutionTimeout accepts 1 to 31,622,400 seconds. Synchronous calls are still capped at 15 minutes, so use asynchronous invocation for anything longer.

**Am I charged while a durable function is waiting?**

For on-demand functions, AWS says waits pause the execution without compute charges. Lambda also suspends the execution and stops compute charges during automatic step retries. For the rates themselves, see the AWS Lambda pricing page.

**Which IAM permissions does a durable function need?**

Its execution role needs lambda:CheckpointDurableExecution and lambda:GetDurableExecutionState. The AWS managed policy AWSLambdaBasicDurableExecutionRolePolicy grants both, plus basic execution permissions. In GovCloud, copy the policy ARN from your own IAM console.

**Should I use durable functions or Step Functions in GovCloud?**

AWS recommends durable functions when your logic lives mostly in Lambda and your team prefers writing code. It recommends Step Functions for workflows across many AWS services or ones that need a visual definition. Many teams use both.

**Will Lambda retry a durable execution that fails?**

No. AWS says the service doesn't automatically retry failed durable executions. Configure retry strategies inside steps, and attach a dead-letter queue so the original event is kept when an asynchronous execution ends as FAILED, STOPPED or TIMED_OUT.

**Why does my durable function reject an unqualified function name?**

Durable functions must be invoked with a version number, an alias or $LATEST. Use a version or alias in production, because executions started on $LATEST can resume on code that changed while they were paused.

## Sources

- [AWS Lambda durable functions are now available in AWS GovCloud (US) Regions](https://aws.amazon.com/about-aws/whats-new/2026/10/durablefunctions-govcloud/)
- [Creating Lambda durable functions](https://docs.aws.amazon.com/lambda/latest/dg/durable-getting-started.html)
- [Deploy and invoke Lambda durable functions with the AWS CLI](https://docs.aws.amazon.com/lambda/latest/dg/durable-getting-started-cli.html)
- [Invoking durable Lambda functions](https://docs.aws.amazon.com/lambda/latest/dg/durable-invoking.html)
- [Best practices for Lambda durable functions](https://docs.aws.amazon.com/lambda/latest/dg/durable-best-practices.html)
- [Supported runtimes for durable functions](https://docs.aws.amazon.com/lambda/latest/dg/durable-supported-runtimes.html)
- [Durable functions or Step Functions](https://docs.aws.amazon.com/lambda/latest/dg/durable-step-functions.html)
- [DurableConfig, AWS Serverless Application Model](https://docs.aws.amazon.com/en_us/serverless-application-model/latest/developerguide/sam-property-function-durableconfig.html)

## About the author

Boris Tane is the founder of Polylane. He previously founded Baselime, observability for the future of the cloud, which Cloudflare acquired. At Cloudflare he built and led the Workers observability team.

## Related

- [How to correlate incidents with deploys using evidence](https://polylane.com/learn/deployment-safety/how-to-correlate-incidents-with-deploys/): Learn how to correlate incidents with deploys using release markers, metrics, logs and verified GitHub, Vercel, Cloudflare and Kubernetes change events.
- [Is It Safe to Give an AI SRE Read Access to Production?](https://polylane.com/learn/ai-in-production/is-it-safe-to-give-an-ai-sre-read-access-to-production/): Read access for an AI SRE is a sound first step if you scope it. The risks are secrets, customer data and exfiltration. Here are the controls and a checklist.
- [Lambda Durable Execution SDK for Go is GA: a practical guide](https://polylane.com/learn/reliability/aws-lambda-durable-execution-sdk-go-generally-available/): AWS made the Lambda Durable Execution SDK for Go generally available on 15 October 2026. What it does, how to ship one, and the limits that bite.
- [CloudWatch log centralisation: GovCloud and 13 new Regions](https://polylane.com/learn/monitoring-coverage/amazon-cloudwatch-log-centralization-new-regions/): AWS added CloudWatch log centralisation to GovCloud (US) and 13 commercial Regions on 16 October 2026. Setup steps, pricing, limits and gotchas.
- [Fix AuthorizerConfigurationException in API Gateway](https://polylane.com/learn/troubleshooting/aws-authorizerconfigurationexception/): AuthorizerConfigurationException means API Gateway couldn't call your Lambda authorizer or couldn't read its response. Find the cause and fix it.

Get started with one command: `curl -fsSL https://polylane.com/setup | bash` installs the CLI, connects your coding agents, and creates the account.