Compared the elapsed time of the GA Lambda Durable Functions Go SDK with the Python SDK
This page has been translated by machine translation. View original
Introduction
On October 15, 2026, the Go SDK for AWS Lambda durable functions became GA (v1.0.0).
In response to my previous article about raising the operation limit, I received feedback that the latest Python SDK is faster and that performance issues have been fixed.
In this article, I ran a function with sequential steps using the Go SDK in the Tokyo region and compared the execution time with functions using Python SDK 2.0.1 and 1.5.0. The processing is the same as Function A from the previous article, executing 3,000 noop steps.
For the basic mechanism of durable functions and how operations are counted, please refer to the previous article.
Writing a Sequential Step Function with the Go SDK
Add the SDK to your module with the following command. Go 1.24 or later is required.
go get github.com/aws/aws-durable-execution-sdk-go@v1.0.0
The handler receives a durable.Context and calls step processing with durable.Step. Passing the handler to durable.Start allows it to be invoked from Lambda. The following function sequentially executes noop steps the number of times specified by steps in the input (default is 3,000 times) and sums the return value of each step.
package main
import (
"github.com/aws/aws-durable-execution-sdk-go/durable"
)
type Event struct {
Steps int `json:"steps"`
}
type Result struct {
Steps int `json:"steps"`
Sum int `json:"sum"`
}
func handler(ctx durable.Context, ev Event) (Result, error) {
n := ev.Steps
if n == 0 {
n = 3000
}
total := 0
for i := 0; i < n; i++ {
v, err := durable.Step(ctx, "noop", func(_ durable.StepContext) (int, error) {
return i, nil
})
if err != nil {
return Result{}, err
}
total += v
}
return Result{Steps: n, Sum: total}, nil
}
func main() {
durable.Start(handler)
}
The Go function is deployed as a single static binary to the provided.al2023 runtime. Following the README instructions, I built the bootstrap with the following command. GOARCH should match the Lambda architecture. Since this is x86_64, it is amd64.
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o dist/bootstrap .
I compressed it so that bootstrap is placed at the root of the zip, and used it as the function code.
Go function creation command
aws lambda create-function \
--function-name <function name> \
--runtime provided.al2023 \
--handler bootstrap \
--role arn:aws:iam::<account ID>:role/<role name> \
--zip-file fileb://<zip file> \
--timeout 900 \
--memory-size 512 \
--durable-config RetentionPeriodInDays=1,ExecutionTimeout=3600
A durabletest for local testing and durablelint to detect code that could break workflows on resume are also available.
Running 3,000 Steps with Go, Python 2.0.1, and Python 1.5.0
I ran 3 functions in parallel for 3 rounds during the same time period.
- Region: Tokyo (ap-northeast-1), memory: 512MB, timeout: 900 seconds, architecture: x86_64
- Durable settings: RetentionPeriodInDays=1, ExecutionTimeout=3600
- Python uses python3.14, with two functions: one using SDK 1.5.0 bundled with the runtime, and one using 2.0.1 bundled in the deployment package
- Go uses provided.al2023 with SDK v1.0.0 (built with go1.25.14)
- Input is
{"steps":3000}
The two Python functions share the same function code.
Python function code
from aws_durable_execution_sdk_python import (
DurableContext,
durable_execution,
durable_step,
)
@durable_step
def noop(step_context, i):
return i
@durable_execution
def lambda_handler(event, context: DurableContext):
n = event.get("steps", 3000)
total = 0
for i in range(n):
total += context.step(noop(i))
return {"steps": n, "sum": total}
All 9 executions succeeded. All 3 conditions process steps sequentially one at a time. The history of each execution has 3,000 StepStarted and 3,000 StepSucceeded events, with no retries and one Lambda invocation per execution.
The Maximum of DurableExecutionOperations in CloudWatch was 3,001 for all 3 conditions. This breaks down to 1 for starting the Execution and 3,000 for steps, which is the same counting method as Function A in the previous article.
The elapsed time is measured from the StartTimestamp to the EndTimestamp returned by get-durable-execution. Each round's value is a single measurement.
| Condition | Round 1 | Round 2 | Round 3 | Average | Per step (average) |
|---|---|---|---|---|---|
| Python SDK 1.5.0 (bundled with runtime) | 423.5 sec | 405.2 sec | 411.9 sec | 413.5 sec | 137.8 ms |
| Python SDK 2.0.1 | 181.1 sec | 176.2 sec | 181.1 sec | 179.5 sec | 59.8 ms |
| Go SDK v1.0.0 | 136.8 sec | 131.0 sec | 140.1 sec | 136.0 sec | 45.3 ms |
Comparing averages, Python SDK 2.0.1 was 2.30 times faster than 1.5.0. The Go SDK was 3.04 times faster than 1.5.0 and 1.32 times faster than 2.0.1. The 3 runs of 2.0.1 ranged from 176 to 181 seconds, and the 3 runs of Go ranged from 131 to 140 seconds, with no overlap in ranges.
The difference between Go and Python includes both the language (runtime) difference and the SDK difference. Since Python 1.5.0 and 2.0.1 use the same function code, same runtime, and same memory with only the SDK changed, the difference between these two is due to the SDK version difference.
Updating to Python SDK 2.0.1
The performance fix mentioned in the X comment corresponds to PR #725 in the primary source. The title is fix: remove idle waits from checkpoint batching, merged on 2026-09-15. This PR shortens the process of waiting up to 100ms with an empty queue after a synchronous checkpoint. In sequential steps, a synchronous checkpoint is performed for each step, so before the fix, this up-to-100ms wait occurred for every step. After the fix, the wait time for batches containing a synchronous checkpoint becomes 1ms.
This fix was included in 2.0.1 (released 2026-09-18).
To update the runtime-bundled SDK to 2.0.1, include only the SDK in the deployment package.
pip install --no-deps --target <output directory> aws-durable-execution-sdk-python==2.0.1
Because --no-deps is specified, boto3 from the Lambda runtime side is used. Python SDK 2.0.1 requires Python 3.11 or higher and boto3 1.42.1 or higher. In this case, it worked with the boto3 included in the python3.14 runtime.
Bundle the contents of the output directory and lambda_function.py so they are placed at the root of the zip, and deploy as function code.
In the 1.5.0 function, the SDK was loaded from the runtime's /var/lang/lib/python3.14/site-packages/. In the 2.0.1 function, it was loaded from the deployment package's /var/task/. As a result, I was able to update to 2.0.1 without changing the function code.
Summary
The Go SDK for Lambda durable functions has been released. I confirmed that sequential step processing identical to Python can be run on Lambda using the Go SDK.
For the same 3,000 sequential steps, both the Go SDK and Python SDK 2.0.1 finished in less time than the runtime-bundled Python SDK 1.5.0.
If you are using Lambda durable functions with Python and want to improve sequential processing performance, please evaluate the latest Python SDK 2.0.1. If you need even higher performance and can adopt Go, please also try the faster Go SDK.
