はじめに
re:Invent 2025 で AWS Lambda durable functions（永続関数） が発表されました。
発表内容では、Lambda に 「ステップ（step）」や「待機（wait）」 といった操作を導入することで、処理途中の チェックポイント（状態） を保存しながら実行を継続できるようです。
一見するとAWS Step Functionsと使いどころがかぶりそうに見えます。今回はre:Invent セッション 「Deep Dive on AWS Lambda durable functions (CNS380)」 の背景やStepFunction周りの内容を整理することで、durable Functionsについて理解してみることにしました。（デモのコード説明など一部内容は省略しているところはあります。また、コメントを追記した部分もあります）
なお、Deep Dive on AWS Lambda durable functions (CNS380)のセッション動画はYoutubeで公開されています。記事の画像はすべてセッション内のスライドをキャプチャーしたものです。
Durable Function が誕生した背景
モノリスとマイクロサービス
モノリスは、コードが一箇所にまとまっているため開発者にとって理解しやすい一方、スケールや運用の段階では結合がボトルネックになりやすいという特徴があります。
マイクロサービスは、サービス間を疎結合にすることで独立デプロイやスケールをしやすくできる一方、その疎結合を実際に実装・運用することが難しい、という課題があります。
ここで「開発体験はモノリスが楽だが、実際の運用やスケールにはマイクロサービスが必要(開発者はモノリスのように開発して、マイクロサービスのようにデプロイしたい)」というギャップが生まれました。AWSではこのギャップを埋めるために、Lambda(2014) → Step Functions(2016) → EventBridge(2019)といったサーバーレスのサービスを発表してきました。
これらのサービスにより、サービス間のオーケストレーションやイベントの受け渡しなどのマイクロサービスを成立させるためのインフラの部分は、以前よりも扱いやすくなったと思います。
ギャップは完全に解決されていない
しかし、「開発体験はモノリスが楽だが、実際の運用やスケールにはマイクロサービスが必要」というギャップを狭めることはできましたが、完全解決はできていませんでした。開発者たちはアプリケーションロジックのオーケストレーションをまだ求めていました。
例えば以下のようなものです。
- Lambdaの上で、信頼性の高いマルチステップのアプリケーションやワークフローを直接構築したい
- 慣れ親しんだプログラミング言語やツールをそのまま使いたい
- コードをローカル環境でテスト・デバッグしたい
- 1 行のコードで、長時間の待機（一時停止）を実現したい
通常のLambdaの場合「ステートレスなコード実行」が前提であるため、マルチステップや待機を含むフローを Lambdaだけで実装するのは難しいです。従来はStep Functionsで複数のLambdaを構成することで、ロジックを分割するのが一つの方法でしたが、「アプリの中のロジック」を外に出すこととなり、またASL(Amazon States Language)という言語で記述する必要がありました。
そこで登場したのが AWS Lambda Durable Functions です。
AWS Lambda Durable Function
セッションではdurable functionsの特徴について以下の３点で説明しています。
- チェックポイント により、ビジネスロジックの進捗を保持して待機できる
- 待機や失敗などでコードが中断された後もビジネスロジックをリプレイすることで継続できる
- １と２の操作のために、Lambda のイベントハンドラに
stepやwaitのような機能を複数言語のSDKで提供する
チェックポイントとリプレイはDurable excution(永続実行)のポイントとして知られています。このDurable excutionを実行できるようにSDKでサポートしているようです。
durable functionsは処理をstep単位で区切ります。stepの境界でチェックポイントが保存され、再開時には ハンドラは最初からリプレイされますが、完了済みのstepは保存済み結果が再利用されるため、見た目としては「途中から再開」しているように見えます。
デモ：カフェの注文システム
セッションでは有名なServerlesspressoの注文管理システム(バリスターダッシュボード)をdurable Functionsを利用したデモを紹介していました。
Serverlesspressoについて知りたい方は以下の記事を読んでみてください。
注文は次のような流れを考えます。
- 注文を受け取る
- Step 1：注文内容をチェック（在庫、合計金額など）
- Step 2：決済を実行（外部決済 API を叩く）
- wait：外部の確認を待つ（待機中は実行を中断し、イベント/条件で再開）
- Step 3：注文確定 → 通知 → 完了
各ステップは成功したらチェックポイントを作ります。こうすることで途中に処理が失敗しても 完了済みのstepは再実行されず、チェックポイントから再開できる、というところです。
また、waitには以下の3種類があり、種類によって再開のトリガーが変わります。
-
時間を指定して待機するwait。指定時間が過ぎると、新しいinvocationが発生して処理が再開されます
-
callback IDやtokenを発行し、それを外部サービスに渡して待機するcallbackによるwait。外部サービスが callbackを完了したタイミングで処理が再開されます
-
「5秒ごとに外部APIを呼び出して条件を確認する」といったcondition(条件)によるwait(ポーリング)。各チェックの間はLambdaの実行は停止しており、条件がtrueになった時点で処理が再開されます
Step Functionsとの使い分け
最初、私も疑問に思ったように 「それで、Step Functionsと何が違うのですか？」 という点です。(動画ではこれをelephant in the roomと言っていて、「誰もが知っているが、あえて触れたがらない大きな問題」という意味らしいです。なるほど)
セッションでは以下のような比較表を出していました。
| 項目 | AWS Step Functions | AWS Lambda durable functions |
|---|---|---|
| 主な目的 (Primary focus) | AWS 全体にわたるワークフローオーケストレーション | Lambda 内でのアプリケーション開発 |
| サービス種別 (Service type) | スタンドアロンのワークフローサービス | Lambda の中で動作 |
| プログラミングモデル (Programming model) | GUI、ASL(DSL)または CDK | プログラミング言語（JavaScript/TypeScript, Python など） |
| 開発ツール (Development tools) | コンソールの Workflow Studio / AWS Toolkit / CDK | Lambda の開発ツール（SAM 等）+ AWS Toolkit |
| 統合 (Integrations) | 220+ AWS サービス、14,000+ API アクション | Lambdaの拡張機能による統合 |
| 管理 (Management) | 完全マネージド、ランタイム非依存（ランタイム更新などを意識しにくい） | Lambda 環境内で管理（ランタイムやデプロイがより近い） |
| 最適な用途 (Best for) | ビジネスプロセス/IT 自動化、データ処理、AI ワークフロー | 分散トランザクション、ステートフルなロジック、関数内オーケストレーション等 |
大きくはAWSサービス全体をまたいでオーケストレーションしたいならStep Functions、アプリケーションコード内でオーケストレーションしたいならdurable functionsが選択としてよいと話してました。ただし、この区別ポイントはあいまいで、我々が今までロジックを分割してStep Functionsでオーケストレーションしてきたように、同じ内容のアプリでも違うアプローチが使えます。
結局は我々がどうしたいかが一番大事なポイントで、上記の表を参考にして例えばロジックをビジュアルでみたい場合はStep Functions、慣れたプログラミング言語でオーケストレーションをしたいのであればdurable functionsといった感じで決めていけばよいと思います。
私周りでのユースケース
ここまでの内容をベースに、私の周りでのdurable functionsのユースケースを考えてみました。
-
作業申請 → 承認 → 作業 → 完了通知をStep Functionsと複数Lambdaで構成したシステムがありますが、これをdurable functionsで１つのLambdaにまとめることで、よりシンプルに全体ロジックを構成できそうです
-
複数のLambdaまたはサービスで構成された夜間ジョブをStep Functionsで動かしており、失敗時の再実行回避のためにParameter Storeに各段階の結果を記録しています。durable functionsなら、Lambda内のstepのチェックポイントで同様の「完了済みの段階スキップ」が実現可能ですので、料金単位が状態遷移であるStandardのStep Functionsのワークフローより利用料を節約できると思いました
-
夜間ジョブの中でLambdaから外部サービスを実行した後に、Step Functionsから「実行 → 待機 → 状況確認 → 未完了なら待機....」を繰り返すロジックを持つワークフローがあります。これをdurable fucntionsのcondition(条件)によるwaitに置き換えれば、2番と同じくStep Functions利用料が安くすりそうでした
その他の考慮ポイント
制約事項（2025年12月時点）
現時点では利用条件に制約があります
- 利用できるリージョン：us-east-2(オハイオ)のみ → 追加でap-northesat-1(東京)を含めた14リージョンで利用可能になりました！
- ランタイム：Node.js 22と24、Python 3.13と3.14
- 新規関数の作成時にのみ有効化可能（既存関数からは変更不可）
利用料金
Durable Functionsは、Lambdaの利用料金に加えて追加で利用料が発生します。
- Durable operations（step/wait/callback など）：$8.00/100万operation
- Data written（チェックポイント等の書き込み）：$0.25/GB
- Data retained（保持）：$0.15/GB-month
待機中は実行時間課金が発生しない一方で、状態保持に関するコストは発生しますので見積もり時は考慮が必要です。
まとめ
AWS Lambda durable functionsはLambdaにdurable executionを導入し、stepとwaitを使ってチェックポイント(Checkpoint)を作りながら、待機や中断を挟む長い業務ロジックを扱えるようにする機能です。さらにリプレイ(Replay)によって、実行が中断されても「途中から続きが動くことを実現します。
これまで「複数ステップ(step) + 待機(wait) + 再開(replay)が必要なケースではStep Functionsにロジックを切り出す設計が必要になりましたが、durable functionsにより、同じ問題をLambda内のコードとして解けることも可能になって、ユーザとして選択肢が増えました。
ただし、今すぐStep Functions作ったものをdurable functionsに置き換える必要はないと思います。まずは、今後の新規開発や既存アプリケーションのリファクタリングのタイミングで、durable functionsがハマる箇所がないか検討してみるのが良さそうです。