
はじめに
こんにちは!アプリケーションエンジニア2年目の松澤です!
この度、2025年12月1日〜12月5日にわたってラスベガスで開催された、AWS re:Invent 2025という大規模なカンファレンスに参加してきました!人生で初めて海外に行き、グローバルなカンファレンスで5日間に渡り、数多くのセッションに参加したことで、私もとても刺激を受けました!
その中でも今回は、Keynoteでも取り上げられた、AWS Lambda durable functions (以下 durable functions)を徹底解説したセッションを受けてきましたので、聴講レポートを執筆いたします!
- はじめに
- セッション概要
- AWS Lambda durable functionとは?
- durable functionsの3つのキーワード
- Checkpoint と Replay のフロー
- 実行方法
- その他詳細
- AWS Step Functionsとどちらを選べばよい?
- まとめ
セッション概要
私は、「Deep Dive on AWS Lambda durable functions (CNS380) 」というブレイクアウトセッションを聴講しました。登壇者は、Senior Product ManagerのMichael Gasch氏、Principal Developer Advocateの Eric Johnson氏でした。
このセッションは、2日目のkeynoteにて、durable functions が発表された後に追加されたセッションでした。新規アップデートにまつわるセッションとのことで、広い会場も満員となり、かなり人気のセッションとなっていました。
セッションは下記のリンクからYouTube上で聞くことが可能です。
1時間かけて、かなり詳しくdurable functionについて説明していただきましたが、その中でも重要だと感じた事項について抜粋します。
AWS Lambda durable functionとは?
かつて、ビジネスロジックを構成する際にこのようなことを思っていた方もいらっしゃると思います。
- マルチステップアプリケーションでも、Lambda上で直接構築したい
- 使い慣れた言語、IDE、LLMを利用したい
- デプロイする前にロジックをローカルで構築、テスト、デバッグしたい
このような方に対して、durable functionsが有効です。
durable functionsは、「依存関係のあるビジネスロジックを、使いなれた言語とツールを用いてシーケンシャルなコードで記載することができる」というものです。
durable functionsの3つのキーワード
durable functionsを象徴する3つのキーワードがあります。

Checkpoint
- durable functionsは、イベントハンドラで進行状況をチェックすることができる永続実行関数です
- 障害発生時、どのチェックポイントから回復するかを確認することができます(完了したチェックポイントはスキップします)
- Lambda関数の実行を一時停止し、待機させることができます
Replay
- 障害などでLambda関数の中断や停止があったときに、ビジネスロジックを上から下まで再度実行します
- この時、完了したチェックポイントをスキップします
SDK
Checkpoint とReplayのロジックを可能にするSDKを提供します。
| メソッド | 説明 |
|---|---|
context.step |
関数を実行する |
context.invoke |
別のLambda関数を呼び出す |
context.wait |
一定期間待機する |
context.waitForCallback |
外部システムを実行する |
context.waitForCondition |
条件が満たされるまで待機する |
context.parallel |
並列処理を行う |
context.map |
配列の項目を処理する |
Checkpoint と Replay のフロー
CheckpointとReplayに関しては、具体的に図を用いて説明をされていました。
障害時の動き
Step1 Validateが完了し、Step2 Reserveがクラッシュしたとします。この時、Replayが開始されます。

Replay時、異なるLambda関数のバージョンのロジックで起動することを防ぐために、クラッシュ時のdurable functionと全く同じバージョンで呼び出されることを確認します。
再実行時に、完了しているCheckpointをスキップします。すなわち Step1は飛ばして Step2を最初に実行します。

待機
ボタンをクリックしたり、クレジットカードをスワイプしたりするというユースケースのために、待機をすることができます。
待機もチェックポイントの一つなので、待機中は関数が停止され、実行されません。

待機を解除する方法としては、指定した時間が経過するか、コールバックIDやトークンを下流のLambda関数やほかのサービスに送信して、コールバックを受ける方法など、様々な待機戦略があります。
Sagaパターン
コード内で、別の分岐処理を行ったりキャンセルしたい場合は、ロールバックして前に実行した作業を元に戻す必要があります。(Sagaパターン)
durable functionsの場合は、単なるステップなので、try-catch文を利用するなどすれば実装が非常に簡単です。

実行方法
Console
関数作成時に永続実行を許可します。

API
DurableConfigプロパティを追加します
"DurableConfig":{ "ExecutionTimeout": 86400 // 関数全体の実行タイムアウト。1day "RetentionPeriodInDays": 14 // データやチェックポイントの保持期間 default(1~90 days) }
SDK
@aws/durable-execution-sdk-js を利用します。
import { withDurableExecution, DurableContext } from '@aws/durable-execution-sdk-js'; export const handler = withDurableExecution( async (event: any, context: DurableContext) => { // Your function receives DurableContext instead of Lambda context // Use context.step(), context.wait(), etc. return result; } );
その他詳細
その他、durable functionsに関する詳細はドキュメントに記載していますが、セッションで取り上げられていたトピックについてピックアップします。
Durable functions Unit test framework
2つのテストモード(ローカルで実行、クラウド上のデプロイ済み関数で実行)で利用することが可能
Runtime
- Node.js 22/24
- Python 3.13/3.14
Event sources
- 最大実行タイムアウト
- 同期実行をした場合:15分
- 非同期実行をした場合:1年
- ExecutionName(Optional):実行名を渡すことができる(重複解除効果が得られる)
- durable invokes (chaining)
- 他のdurable関数・非durable関数などのLambda関数が存在する可能性が高いので、コンテキスト呼び出しを実行することができる。他の関数を呼び出す際は、自分の関数を中断することができる
- 関数の実行自体に負荷がかからないため、Lambda関数の連鎖自体はアンチパターンではなくなる
- イベントソースマッピングをサポート(SQS、Kinesisなど)
- Lambdaで同時実行制御を備えたバッファとしてSQSを利用することも可能
- SQSのFIFOも保証
Version
- 被修飾のARNを許可しない
- Replay時にLambdaのバージョンが異ならないようにする
- $LATEST for prototyping #YOLO
- 適切なバージョン、エイリアスを実行したい場合に、最新のバージョンを一度だけ有効にするモード
Monitoring
- CloudWatch Logs
- context.logger:Replay対応
- 新しいCloudWatch Metricsの追加
- ApproximateRunningDurableExecutions:RUNNING状態の永続実行の数
- DurableExecutionFailed:失敗して完了した永続実行の数
- DurableExecutionOperations:永続実行内で実行された操作の累積数(最大: 3,000)
- EventBridge rule
- 実行ステータス変更イベントをEventbridgeに送信することが可能
RUNNING:処理開始SUCCEEDED:正常に完了STOPPED:StopDurableExecution APIを使用して実行が停止FAILED:エラーにより実行失敗TIMED_OUT:実行が設定されたタイムアウトを超えた
- 実行ステータス変更イベントをEventbridgeに送信することが可能
- Quotas
- 最大永続実行数、永続実行中の永続オペレーション数など様々なQuotasが追加されています。ほとんどのユースケースをカバーできるほど十分に高く調整しましょう
Best Practices
- シンプルに、コーディングのベストプラクティスを適用すること
- 好みのパッケージマネージャを用いてSDKをバンドルすること。コンソール上でもSDKを使うこと
- LLMが、durable functionsを理解しているか確認してからコーディングを行うこと
- 同期実行時・非同期実行時の2つの実行タイムアウトに、十分な時間が確保されていること
- Lambda関数をReplayすることになるので、UUIDの生成、タイムスタンプなどの非決定論的なコード(再現性がないコード)を同じステップで配置してラップすること
- バックエンドでデータを永続化させるカスタムシリアライザー、デシリアライザー
- チェックポイントを超える大きなペイロードがある場合は、カスタムシリアライザーを用いてS3などに保存し、Replay時にデータを取得できる
料金
| 対象 | 料金 | |
|---|---|---|
| Durable Operations | チェックポイント(ステップ、待機、コールバックなど) | $8.00 / 100万オペレーション |
| Data Written | Durable 実行によって永続化される実データ(ステップ結果、コールバックデータなど) | $0.25 / GB |
| Data Retained | 実行中および完了後に保持されるデータ | $0.15 / GB・月 |
既存のLambdaコンピューティングの料金も適用されるので注意しましょう。
AWS Step Functionsとどちらを選べばよい?

これまでの説明を聴いている私は、durable functionsは、Lambda関数内で扱うことができるStep Functions程度の認識で、いまいちStep Functionsとの違いがわかりませんでした。そんな私のような反応を想定してか、Step Functionとの違いも提示していただきました。
以下の表は、サービスの比較を日本語にまとめたものです。
| 項目 | AWS Step Functions | AWS Lambda Durable Functions |
|---|---|---|
| 主な目的 (Primary focus) | AWS 全体にわたるワークフローのオーケストレーション | Lambda 上でのアプリケーション開発 |
| サービス形態 (Service type) | スタンドアロンの専用ワークフローサービス | Lambda 内で実行 |
| プログラミングモデル (Programming model) | グラフベース、Amazon States Language DSL または CDK | 標準プログラミング言語(JavaScript/TypeScript、Python)* |
| 開発ツール (Development tools) | コンソールのビジュアルビルダー / AWS Toolkit IDE 拡張機能、CDK | Lambda DX、SAM、AWS Toolkit IDE 拡張機能 |
| 統合 (Integrations) | 220 以上の AWS サービス、16,000 の API | Lambda プログラミングモデルの拡張 |
| 運用管理 (Management) | フルマネージド、ランタイム非依存、運用不要(パッチ適用やランタイム更新なし) | Lambda 環境内で管理 |
| 最適な用途 (Best for) | ビジネスプロセスおよび IT の自動化、データ処理、AI ワークフロー | 分散トランザクション、ステートフルなアプリケーションロジック、関数オーケストレーション、データ処理、AI ワークフロー |
結論、両者の使い分けの基準は下記になりそうです。
- Step Functions:様々なサービスにわたりバッチをオーケストレーションしている場合
- Lambda durable functions:アプリケーションコードのオーケストレーションを行う場合
とはいえ、ビジュアルビルダーが欲しかったらStep Functionsというように、結局のところ開発者が何を求めているか、それにどうアプローチするかが重要とのことです。
まとめ
今回はAWS Lambdaの新しい機能であるdurable functionsについて徹底解説したセッションをまとめました。
durable functionsは、TypescriptやPythonなど、アプリケーションエンジニアにもなじみのある言語でオーケストレーションをすることができるため、アプリケーションエンジニアにとっても有用な機能だと感じました。
私が一番durable functionsで魅力的だなと思った点は、非同期実行時、durable functions全体の最大実行タイムアウトが1年であるということです。Lambdaには依然として同期実行時、15分の最大実行タイムアウトがあります。しかし、durable functionsを組み合わせることで、全体のビジネスロジックの実行時間が15分を超えることもできます。同期実行時の15分制限がネックになりLambdaで動かせなかったバッチも、うまくオーケストレーションをすることでLambda上で展開できるかもしれません!

皆さんもdurable functionsを是非使ってみてください!