GA になった Lambda durable functions の Go SDK、所要時間を Python SDK と比較してみた
はじめに
2026 年 10 月 15 日、AWS Lambda durable functions の Go SDK が GA となりました（v1.0.0）。
前回 operation 上限の引き上げ時に書いた記事に対し、最新の Python SDK は高速で、パフォーマンス上の問題が修正された、というご指摘をいただきました。
そこで本記事では、東京リージョンで Go SDK を使った逐次 step の関数を実行し、Python SDK 2.0.1 および 1.5.0 を使った関数と所要時間を比較しました。処理は前回記事の関数 A と同じで、noop の step を 3,000 回実行します。
durable functions の基本的な仕組みと operation の数え方については、前回記事をご覧ください。
Go SDK で逐次 step の関数を書く
SDK は次のコマンドでモジュールに追加します。Go 1.24 以降が必要です。
go get github.com/aws/aws-durable-execution-sdk-go@v1.0.0
ハンドラーは durable.Context を受け取り、step の処理を durable.Step で呼びます。durable.Start にハンドラーを渡すと Lambda から起動できます。次の関数は、入力の steps で指定した回数（既定は 3,000 回）だけ noop の step を逐次実行し、各 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)
}
Go の関数は、単一の静的バイナリとして provided.al2023 ランタイムにデプロイします。README の手順に従い、次のコマンドで bootstrap を作りました。GOARCH は Lambda のアーキテクチャに合わせます。今回は x86_64 なので amd64 です。
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o dist/bootstrap .
bootstrap が zip のルートに置かれるように圧縮し、関数コードとして使いました。
Go 関数の作成コマンド
aws lambda create-function \
--function-name <関数名> \
--runtime provided.al2023 \
--handler bootstrap \
--role arn:aws:iam::<アカウントID>:role/<ロール名> \
--zip-file fileb://<zipファイル> \
--timeout 900 \
--memory-size 512 \
--durable-config RetentionPeriodInDays=1,ExecutionTimeout=3600
ローカルテスト用の durabletest と、再開時にワークフローを壊しうるコードを検出する durablelint も用意されています。
3,000 step を Go・Python 2.0.1・Python 1.5.0 で動かす
3 つの関数を、同じ時間帯に並行して 3 ラウンド動かしました。
- リージョンは東京（ap-northeast-1）、メモリは 512MB、タイムアウトは 900 秒、アーキテクチャは x86_64
- durable 設定は RetentionPeriodInDays=1、ExecutionTimeout=3600
- Python は python3.14 で、ランタイム同梱の SDK 1.5.0 を使う関数と、デプロイパッケージに同梱した 2.0.1 を使う関数の 2 つ
- Go は provided.al2023 で、SDK は v1.0.0（go1.25.14 でビルド）
- 入力は
{"steps":3000}
Python の 2 関数は同じ関数コードです。
Python の関数コード
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}
全 9 実行が成功しました。3 条件とも、step を 1 つずつ順に実行する逐次処理です。各実行の履歴は StepStarted と StepSucceeded が 3,000 件ずつで、再試行はなく、Lambda の呼び出しは各実行 1 回でした。
CloudWatch の DurableExecutionOperations の Maximum は 3 条件とも 3,001 でした。内訳は Execution の開始 1 と step 3,000 で、前回記事の関数 A と同じ数え方になります。
所要時間は、get-durable-execution が返す StartTimestamp から EndTimestamp までです。各ラウンドの値は 1 回の測定です。
| 条件 | ラウンド 1 | ラウンド 2 | ラウンド 3 | 平均 | 1 step あたり（平均） |
|---|---|---|---|---|---|
| Python SDK 1.5.0（ランタイム同梱） | 423.5 秒 | 405.2 秒 | 411.9 秒 | 413.5 秒 | 137.8 ミリ秒 |
| Python SDK 2.0.1 | 181.1 秒 | 176.2 秒 | 181.1 秒 | 179.5 秒 | 59.8 ミリ秒 |
| Go SDK v1.0.0 | 136.8 秒 | 131.0 秒 | 140.1 秒 | 136.0 秒 | 45.3 ミリ秒 |
平均で比べると、Python SDK 2.0.1 は 1.5.0 の 2.30 倍の速さでした。Go SDK は 1.5.0 の 3.04 倍、2.0.1 の 1.32 倍でした。2.0.1 の 3 回は 176〜181 秒、Go の 3 回は 131〜140 秒で、範囲は重なっていません。
Go と Python の差には、言語（ランタイム）の差と SDK の差の両方が含まれます。Python の 1.5.0 と 2.0.1 は、同じ関数コード・同じランタイム・同じメモリで SDK だけを変えているので、この 2 つの間の差は SDK のバージョンの違いによるものです。
Python SDK を 2.0.1 に更新する
X のコメントにあった性能問題の修正は、一次ソースでは PR #725 に当たります。タイトルは fix: remove idle waits from checkpoint batching で、2026-09-15 にマージされています。この PR は、同期 checkpoint のあとにキューが空のまま最大 100ms 待つ処理を短縮するものです。逐次 step では step ごとに同期 checkpoint を行うため、修正前はこの最大 100ms の待機が step ごとに発生していました。修正後は、同期 checkpoint を含むバッチの待ち時間が 1ms になります。
この修正は 2.0.1（2026-09-18 リリース）で入りました。
ランタイム同梱の SDK を 2.0.1 に更新するには、SDK だけをデプロイパッケージへ入れます。
pip install --no-deps --target <出力ディレクトリ> aws-durable-execution-sdk-python==2.0.1
--no-deps を付けているため、boto3 は Lambda ランタイム側のものを使います。Python SDK 2.0.1 は Python 3.11 以上と boto3 1.42.1 以上を要求します。今回は、python3.14 ランタイムに含まれる boto3 で動作しました。
出力ディレクトリの中身と lambda_function.py が zip のルートに置かれるようにまとめ、関数コードとしてデプロイします。
1.5.0 の関数では、SDK はランタイム側の /var/lang/lib/python3.14/site-packages/ から読み込まれました。一方、2.0.1 の関数では、デプロイパッケージ側の /var/task/ から読み込まれました。このため、関数コードを変更せずに 2.0.1 へ更新できました。
まとめ
Lambda durable functions 用の Go SDK がリリースされました。Python と同じ逐次 step の処理を、Go SDK を使って Lambda 上で動かせることを確認しました。
同じ 3,000 step の逐次処理では、Go SDK と Python SDK 2.0.1 のどちらも、ランタイム同梱の Python SDK 1.5.0 より短い時間で終わりました。
Python で Lambda durable functions を利用していて逐次処理の性能を改善したい場合は、最新の Python SDK 2.0.1 を評価してみてください。さらに高い性能が必要で Go を採用できる場合は、より高速な Go SDK もお試しください。
