Go の Lambda 関数で、途中で人の承認を待つ多段ワークフローをどう書き、どうテストするか。SDK の4機能、provided.al2023 へのデプロイ、durabletest と durablelint の位置づけを整理する。
最大1年 durable execution 全体の最大期間 AWS の発表と開発者ガイドによる。個別の待機ごとに追加される期間ではない
承認待ちを、Go のコードに組み込める。AWS は2026年10月15日、AWS Lambda Durable Execution SDK for Go の一般提供を告知した。SDK が進捗の保存を担い、durabletest で待機を含む流れをローカル検証できる。
上限の最大1年は durable execution 全体の期間で、承認待ちのたびに1年を追加できる意味ではない。サービスはチェックポイントを使って複数の Lambda 呼び出しにまたがる進捗を維持するため、一つの関数プロセスをその期間ずっと動かす仕組みとも異なる。
SDK の主要な操作は、処理を記録する steps、外部との連携に使う callback、関数を連鎖させる durable invocation、効率的に一時停止する wait だ。AWS の発表は、インフラ自動化、承認ゲート付きデプロイ、AI の出力を人がレビューするパイプラインを利用例に挙げている。
公式 SDK の README では、Wait は時間を指定した待機、CreateCallback と WaitForCallback は外部からの結果を待つ操作として説明される。承認者の応答を待つなら callback の ID を外部システムに渡し、その ID に対して成功・失敗の結果を返す形になる。待ち時間と callback の期限も設計時に確認したい。
チェックポイント後に関数が再度呼ばれると、SDK は保存済みの結果を再生し、完了した操作をもう一度実行する代わりに未完了の続きへ進む。処理を普通の関数として順に書けても、再実行を意識しなくてよいわけではない。外部への書き込みや副作用をどの操作に置くかが実装上の確認点になる。
導入は Go module に SDK を追加し、provided.al2023 ランタイム向けの静的バイナリとしてデプロイする形だ。公式 README には次の追加コマンドが載っている。
go get github.com/aws/aws-durable-execution-sdk-goSDK を追加するだけでは、設定の確認は終わらない。README のデプロイ例には DurableConfig があり、既存の Go 関数と同じランタイムを使う場合でも、テンプレートの設定と実行ロールのチェックポイント・状態取得権限を公式例に照らして確認する必要がある。
この確認は本番に載せる前に行う。処理の一時停止と再開は、アプリのコードだけでなくサービス側の設定にも依存するからだ。
durabletest は、ネットワーク接続や AWS 認証情報なしでワークフロー全体を手元でテストするためのパッケージだ。承認結果が返った場合と返らない場合など、待機を含む流れをクラウドへデプロイする前に試せる。ただし、アプリが独自に呼ぶ外部サービスまで認証不要になるという意味ではない。
durablelint は、再開時にワークフローを壊しうるコードを検出する解析ツールだ。テストと併用し、指摘された処理が再実行されたときの挙動を確かめる。どちらも、本番の IAM 権限やリージョンでの提供確認を代替しない。
Lambda の開発者ガイドは、wait 中には compute charges が発生しないと説明している。ただし、それだけでワークフロー全体が無料になるわけではない。実際の処理や durable functions の利用料金は、公式料金ページで確認する。
Go の既存コードに承認ゲートを組み込みたいチームは、まず小さな処理で待機と再開を検証し、durablelint の指摘を確認してからデプロイ設定と権限を合わせるとよい。最大期間だけで採用を決めず、再開時に安全に続けられるかを確かめることが、導入判断につながる。