【AWS re:Invent 2025】AWS Lambda Durable Functionsとは？

はじめに

こんにちは、帰国したら2キロ減っていたけど1日で戻ったヤマダ(北野)です。

サーバーレスアーキテクチャの進化は目覚ましいものがありますが、Lambda関数で時間のかかる処理や外部連携を伴う複雑なワークフローを実装するときに「途中で処理が中断したらどうしよう」「待機中にコストが発生するのはいやだ」といった困り事がありますよね。

AWS re:Invent 2025で発表されたAWS Lambda Durable Functionsは、まさにそんな悩みを解決するための強力なソリューションです！

Lambda Durable Functionsとは

https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html

Lambda Durable Functionsは、AWS Lambda関数に耐久性 (Durability)とステート管理 (State Management)の機能を追加し、関数が中断されても中断した場所から再開できるようにする仕組みです。

通常のLambda関数は最大実行時間に制限があり、外部へのコールや待機時間があると、その間も課金が発生し続けます。しかし、Durable Functionsを使えば、複雑なワークフローをシンプルに、かつコスト効率良く実行できます。

Durable Functionsの導入は非常に簡単です。Lambda関数の作成時、または既存の設定画面で項目を有効化するだけです。

実践！注文処理ワークフローのコードを実行検証

https://docs.aws.amazon.com/lambda/latest/dg/durable-getting-started.html

上記のページにあった「注文処理」のPythonコードを実際に動かし、その実行ログを分析することでDurable Functionsの仕組みを解説します。

検証したコードのポイント

上記の関数は以下の4つのステップを実行します。

1. validate_order（注文の検証）
2. process_payment（支払い処理）
3. context.wait(Duration.from_seconds(10))（外部確認待ちを10秒間シミュレート）
4. confirm_order（注文の確定）

【補足】バージョンの発行
Durable Functionsは適格ARNでの呼び出しが必要なため、実行前にバージョンの発行が必要です。検証では画面のようにシンプルにバージョンを発行しました。

永続オペレーションのタイムライン（実行の継続性）

まずLambdaコンソールの「Durable executions」タブで確認できる実行タイムラインを見てみましょう。

このタイムラインからvalidate_orderとprocess_paymentの成功後、Wait 操作によって10秒 1 ms の待機が発生し、その後 confirm_order がシームレスに実行されていることが分かります。関数が中断されたにもかかわらずワークフロー全体が継続していることが証明されます。

実行ログの分析（コスト効率とリプレイ）

次にこの実行が実際にはどのように行われているかをCloudWatch Logsで確認します。

1. 最初の実行の終了: 上部のログを見ると、Request ID: df737951-… の実行が status: “success” で終わっています。これは、Waitに到達したため、Lambda関数が一時的に休みに入ったことを示します。このお休み中にコンピューティングリソースは消費されていません。
2. 待機後の再開: 約10秒後（15:28:01Z）に全く異なる Request ID: ecfef65f-… で実行が再開しています。ログ上は新しい実行として始まっていますが処理は止まっていません。

この再開後の実行で重要なのは、validate_orderやprocess_paymentのログが出ていないことです！Durable Functionsは内部の「チェックポイント記録」を読み込み、すでに完了したステップは自動的にスキップしてくれました。

Durable Functionsの大きなメリット

Durable Functionsの強力な仕組みを体感した上で、主なメリットを分かりやすくまとめます。

1. ワークフローの信頼性と回復力（中断からの自動再開）

• 自動チェックポイント機能: @durable_step デコレーターでマークされた各ステップの実行前後にチェックポイントが作成されます。
• 中断からの再開: タイムアウトや意図的な待機で関数が中断されても、最後に完了したチェックポイントから自動的に実行が再開されてムダな再実行を防ぎます。

2. コスト効率の向上（待機中の課金なし）

context.wait()のような待機操作を行う時に関数は実行を一時停止します。この待機期間中にLambdaのコンピューティングリソースは消費されないので課金もされません。これは外部サービスの応答待ちや人間による承認待ちといったシナリオで非常に大きなコスト削減効果をもたらします。

3. 複雑なワークフローをシンプルなコードで記述可能

DurableContextオブジェクトのstep()やwait()といったシンプルなメソッドを順次呼び出すだけでステート管理の複雑さを意識することなく、ビジネスロジックに集中したコードが書けます。

主なユースケース

Durable Functionsはその耐久性と待機能力を活かし、様々な長時間実行されるステートフルなワークフローに適用できます。

1. 注文およびトランザクション処理
注文の検証 → 支払い処理 → 注文確認といった複数のステップからなる一連のビジネスプロセス。
途中で失敗してもその前のステップの結果は保持されます。

2. 人間によるレビュー・承認ワークフロー
経費申請 → 上長承認の待機 (数時間〜数日) → 支払い実行といった人間が関与する長時間の待機が必要なワークフロー。

3. データ処理パイプライン
大規模データのアップロード → データ検証 → 複数の変換・集計処理といった時間がかかって途中で中断・再開が必要になる可能性のあるタスク。

まとめ

AWS Lambda Durable Functionsはサーバーレス環境で信頼性・コスト効率・コードのシンプルさを維持しながら、複雑で長時間にわたるワークフローを構築できます。

この機能は、AWSのオーケストレーションサービスであるヤマダもラブなAWS Step Functionsと目的が似ています。

Durable Functionsは単一のLambda関数内で、耐久性と待機をシンプルに実現したい場合に有効です。Step Functionsは複数のLambda、S3、DynamoDBなど様々なAWSサービスを組み合わせてワークフローを構築したい場合に適しています。あとはやはり視覚的なワークフローではまだまだStep Functionsのほうが有利ではないでしょうか。

ヤマダ的にはより明確な使い分けやスマートな選定のためにこれから2つとも擦っていきたいと思います。