Lambda Durable Functions とは何か ― チェックポイント&リプレイで最大1年間の実行を実現する仕組みと使いどころ

AWSAWS LambdaDurable FunctionsサーバーレスAIワークフローStep Functions
AWS Lambda announces durable functions for multi-step applications and AI workflows - AWS Discover more about what aws.amazon.com
Build multi-step applications and AI workflows with AWS Lambda durable functions | Amazon Web Services New Lambda capability lets you build applications that coordinate multiple steps reliably over exten... aws.amazon.com
Lambda durable functions - AWS Lambda Lambda durable functions extend traditional Lambda to support durable execution, enabling fault-tole... docs.aws.amazon.com
Building fault-tolerant applications with AWS Lambda durable functions | Amazon Web Services Business applications often coordinate multiple steps that need to run reliably or wait for extended... aws.amazon.com

AWS Lambda に Durable Functions（永続関数） という新機能が追加されました（2025年12月2日 AWS What’s New）。re:Invent 2025 で発表されたこの機能は、Lambda関数にチェックポイントとリプレイの仕組みを組み込み、最大1年間にわたる長時間実行やマルチステップ処理を、Lambda のプログラミングモデルそのままで実現するものです。

正直に言うと、自分はこの機能の存在を最近まで見落としていました。Step Functions の新しいSDK統合を調べている中で「Lambda Durable Execution API」という記述に出会い、「何これ？」となったのがきっかけです。調べてみると、これはかなり大きなパラダイムシフトだと感じています。

何が嬉しいのか

従来のLambda関数は、最大15分で完了する短命な処理に特化していました。注文処理やユーザーオンボーディングのような複数ステップからなるワークフローを組む場合、以下のいずれかの選択が必要でした。

  • Step Functions でワークフローを外部に切り出す（ASLというDSLで定義）
  • カスタムの状態管理を自前で実装する（DynamoDB + SQS等）

Durable Functions は、この問題に対して第三の選択肢を提示します。普段書いているPythonやJavaScriptのコードの中に step() や wait() を差し込むだけで、進捗のチェックポイント、障害からの自動回復、最大1年間の実行中断/再開ができるようになります。

Managed Instances 限定ではなく、通常のLambda（デフォルト）で使えます。CLIの --durable-config は --capacity-provider-config（Managed Instances用）とは独立したオプションです。

チェックポイントとリプレイの仕組み

Durable Functions の核心はチェックポイント & リプレイというメカニズムです。

チェックポイント

コード内で context.step() を呼ぶと、そのステップの結果がチェックポイントとして永続化されます。これが「セーブポイント」になります。

リプレイ

関数が中断や障害から再開される際、ハンドラは最初から実行し直されます。ただし、すでにチェックポイントが保存されているステップはスキップされ、保存済みの結果がそのまま使われます。つまり、同じ処理が二重に実行されることはありません。

wait による中断

context.wait() を呼ぶと、関数の実行が一時停止します。ここがポイントで、停止中はコンピュート料金が発生しません。人間の承認待ちや外部システムの完了待ちなど、数分〜数日かかるような待機をコスト効率よく実現できます。

コード例：注文処理ワークフロー

公式ブログで紹介されている注文処理ワークフローのコード例を見てみます（2025年12月2日 AWS News Blog）。

from aws_durable_execution_sdk_python import (
    DurableContext,
    StepContext,
    durable_execution,
    durable_step,
)
from aws_durable_execution_sdk_python.config import (
    Duration,
    StepConfig,
    CallbackConfig,
)
from aws_durable_execution_sdk_python.retries import (
    RetryStrategyConfig,
    create_retry_strategy,
)


@durable_step
def validate_order(step_context: StepContext, order_id: str) -> dict:
    step_context.logger.info(f"Validating order: {order_id}")
    return {"order_id": order_id, "status": "validated"}


@durable_step
def send_for_approval(step_context: StepContext, callback_id: str, order_id: str) -> dict:
    step_context.logger.info(f"Sending order {order_id} for approval with callback_id: {callback_id}")
    # 外部の承認システムに callback_id を送信
    return {"order_id": order_id, "callback_id": callback_id, "status": "sent_for_approval"}


@durable_step
def process_order(step_context: StepContext, order_id: str) -> dict:
    step_context.logger.info(f"Processing order: {order_id}")
    return {"order_id": order_id, "status": "processed", "timestamp": "2025-11-27T10:00:00Z"}


@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> dict:
    try:
        order_id = event.get("order_id")

        # Step 1: 注文のバリデーション
        validated = context.step(validate_order(order_id))
        if validated["status"] != "validated":
            raise Exception("Validation failed")  # ステップ外の例外 → 即座に実行停止

        # Step 2: コールバック作成（外部承認待ち）
        callback = context.create_callback(
            name="awaiting-approval",
            config=CallbackConfig(timeout=Duration.from_minutes(3))
        )

        # Step 3: 承認リクエスト送信
        context.step(send_for_approval(callback.callback_id, order_id))

        # Step 4: コールバック結果を待機（ここで関数は中断、コンピュート料金なし）
        approval_result = callback.result()

        # Step 5: 注文処理（リトライ戦略付き）
        retry_config = RetryStrategyConfig(max_attempts=3, backoff_rate=2.0)
        processed = context.step(
            process_order(order_id),
            config=StepConfig(retry_strategy=create_retry_strategy(retry_config)),
        )

        return processed

    except Exception as error:
        context.logger.error(f"Error processing order: {error}")
        raise error

見てもらうと分かるように、普通のPythonコードです。@durable_execution デコレータと context.step() / context.create_callback() を使うだけで、以下が自動的に実現されます。

  • Step 1 のバリデーション結果がチェックポイントに保存される。障害で再実行されても、バリデーションは再度実行されない
  • Step 4 で関数が中断して承認を待つ。外部システムが SendDurableExecutionCallbackSuccess API を呼ぶと再開される
  • Step 5 でエラーが発生すると自動リトライ。max_attempts=3, backoff_rate=2.0 で指数バックオフ

Step Functions でこれと同等のワークフローを組む場合、ASL（Amazon States Language）でステートマシンを定義し、各ステップをLambda関数として切り出す必要がありました。Durable Functions では、1つの関数内にすべてのロジックを書き、SDK がオーケストレーションを担います。

Durable Functions の主なプリミティブ

SDK が提供する操作は以下のとおりです。

プリミティブ説明
context.step()ビジネスロジックの実行。チェックポイント保存 + 自動リトライ
context.wait()指定時間の待機。関数を中断し、コンピュート料金なし
context.create_callback()外部イベント（APIレスポンス、人間の承認）を待つためのコールバック作成
context.wait_for_condition()特定の条件が満たされるまで待機（REST APIのポーリングなど）
context.parallel()複数の操作を並列実行
context.map()配列に対する並列処理

Step Functions との使い分け

Durable Functions の登場で、「Step Functions とどう使い分けるのか？」は当然の疑問です。

Lambda Durable FunctionsStep Functions
定義方法普通のプログラミング言語（Python/JS）ASL（DSL）またはビジュアルデザイナー
実行場所Lambda関数内独立したサービス
サービス統合コード内でSDKを呼び出す220以上のサービスとネイティブ統合
向いているケース密結合なマルチステップロジックサービス横断のオーケストレーション
最大実行時間1年Standard: 1年 / Express: 5分
可視化Durable Executions タブビジュアルワークフロー

自分の感覚では、使い分けは以下のようになると思います。

  • Durable Functions が向いているケース: 1つのアプリケーション内で完結するマルチステップ処理。コード内にロジックをまとめたいとき。AIエージェントのような、分岐が動的で事前にワークフローを定義しにくい処理
  • Step Functions が向いているケース: 複数のAWSサービスを横断するオーケストレーション。ビジュアルなワークフロー設計が欲しいとき。大規模なチームで非エンジニアにもフローを見せたい場合

両方を組み合わせることもできます。Step Functions のステップとして Durable Function を呼び出し、長時間実行する個々のステップの中でチェックポイントとリプレイの恩恵を受ける、というパターンです。

CLI でのパラメータ構造

検証環境

  • AWS CLI: aws-cli/2.34.8
  • リージョン: ap-northeast-1（東京）

関数作成時の DurableConfig

Durable Functions は関数作成時に有効化します。既存の関数に後から追加することはできません。

aws lambda create-function \
  --function-name my-durable-function \
  --runtime python3.14 \
  --handler index.lambda_handler \
  --role arn:aws:iam::123456789012:role/lambda-execution-role \
  --code S3Bucket=my-bucket,S3Key=code.zip \
  --durable-config RetentionPeriodInDays=30,ExecutionTimeout=86400 \
  --profile your-profile

DurableConfig のパラメータは2つです。

パラメータ説明制約
RetentionPeriodInDays実行履歴の保持日数1〜90日
ExecutionTimeoutDurable実行の最大時間（秒）1〜31,622,400秒（約366日）

ExecutionTimeout が31,622,400秒（約366日）まで設定できるのは驚きです。通常のLambdaのタイムアウトは最大15分ですが、Durable Functions では実行の中断と再開を繰り返すことで、最大1年間にわたる処理が可能になります。

Durable Execution 関連のCLIコマンド

確認したところ、以下の管理用コマンドが用意されています。

コマンド説明
list-durable-executions-by-function関数のDurable実行一覧
get-durable-execution実行の詳細取得
get-durable-execution-history実行履歴（各ステップの状態）取得
get-durable-execution-state実行状態取得（リプレイ用、SDK内部で使用）
checkpoint-durable-executionチェックポイントの作成
send-durable-execution-callback-successコールバックの成功応答
send-durable-execution-callback-failureコールバックの失敗応答
send-durable-execution-callback-heartbeatコールバックのハートビート
stop-durable-execution実行の停止

料金

Durable Functions の料金は、通常のLambda料金（リクエスト + 実行時間）に加えて、以下の3つの要素で構成されます。

項目料金
オペレーション$8.00 / 100万オペレーション
データ書き込み$0.25 / GB
データ保持$0.15 / GB-月

「オペレーション」はチェックポイントやステップの実行ごとにカウントされます。例えば、実行開始が1オペレーション、各ステップが1+リトライ回数のオペレーション、コールバック待機が3+リトライ回数のオペレーションとしてカウントされます。

チェックポイントの最大サイズは256KBです。大きなデータを扱う場合はS3に保存してARNだけをチェックポイントに含める方がコスト効率が良いとのことです。

注目すべきは、wait() で中断している間はコンピュート料金が発生しない点です。人間の承認待ちが数日間続いても、待機中のコストはデータ保持料金のみです。

利用可能なリージョン

当初はUS East（Ohio）のみでしたが、2025年12月18日に14リージョンが追加され、東京リージョンを含む15リージョンで利用可能になっています（2025年12月18日 AWS What’s New）。

対応リージョン: US East (N. Virginia / Ohio), US West (Oregon), Europe (Ireland / Frankfurt / Milan / Stockholm / Spain), Asia Pacific (Tokyo / Sydney / Hong Kong / Singapore / Mumbai / Malaysia / Thailand)

対応ランタイムと SDK

ランタイム対応バージョンSDKリポジトリ
Python3.13, 3.14aws-durable-execution-sdk-python
Node.js (JavaScript/TypeScript)22, 24aws-durable-execution-sdk-js
JavaDeveloper Preview（2026年2月〜）-

SDK はオープンソースで公開されており、関数コードにバンドルして使います。

Terraform の対応状況

Terraform AWS Provider v6.25.0（2025年12月4日）で aws_lambda_function に durable_config 引数が追加されています（#45359）。

注意点

いくつか押さえておくべき制約があります。

  • 既存の関数には追加できない: Durable Functions は関数作成時にのみ有効化できます。既存の関数を後からDurable化することはできません
  • Lambda バージョンの使用を推奨: 実行中にコードが更新された場合、リプレイは実行開始時のバージョンで行われます。本番デプロイではLambdaバージョンを使って一貫性を担保することが推奨されています
  • リプレイ時のログ重複: リプレイ中に通常のprint/loggingを使うとログが重複します。context.logger を使うと、リプレイ中の重複ログが自動的に抑制されます
  • チェックポイントサイズの上限: 256KB まで。大きなデータはS3に退避
  • スレッドセーフ: マルチコンカレンシー環境（Managed Instances）で使う場合は、コードがスレッドセーフである必要があります

EventBridge との連携

Durable Execution の状態変化はデフォルトの EventBridge イベントバスに自動送信されます。以下のパターンでルールを作成すれば、実行状態の監視や通知が可能です。

{
  "source": ["aws.lambda"],
  "detail-type": ["Durable Execution Status Change"]
}

まとめ

Lambda Durable Functions は、自分の中で「Lambda の概念が変わった」と感じるくらいのアップデートです。

特に注目しているのは以下の点です。

  • Lambdaの15分制約を超える: チェックポイントとリプレイにより、最大1年間の長時間実行が可能に。ただしこれは「15分で終わらない1つの処理を15分超動かせる」ではなく、「複数の短い処理をステップとして繋ぎ、全体として長期間にわたるワークフローを構築できる」という意味です
  • AIワークフローとの相性: 人間の承認待ちやエージェントの長時間推論など、非同期で待機が発生するパターンにぴったりです。wait() で中断中はコンピュート料金がかからないので、コスト面でも合理的です
  • Step Functions との共存: 競合ではなく補完関係だと考えています。Step Functions は220以上のサービスとのネイティブ統合が強みですが、Durable Functions は「コードの中に閉じたワークフロー」を得意とします

Managed Instances 限定ではなく通常のLambdaで使えるので、試すハードルは低いです。東京リージョンにも対応済みなので、まずは簡単なワークフローで試してみることをおすすめします。