Lambda Durable Functionsとは？東京の料金・15分制限の超え方・SDK実装【2026年10月】

AWS Lambda Durable Functions（日本語ドキュメントでは「耐久性のある関数」）は、Lambda関数のコードの中で処理をステップに区切り、進捗を自動保存しながら最大1年続くワークフローを書ける機能です。東京リージョンでは2025年12月18日から利用できます。

この記事では、東京での料金を実際の単価で試算し、同期呼び出し・非同期呼び出し・SQSなどのイベントソースから呼んだときにそれぞれ何分まで動けるかを整理します。コード例は、2026年10月下旬に出たSDK 3.0系をローカルのテストSDKで実行して動作を確かめたものです。なお、Azure Functionsの拡張機能「Durable Functions」とは別の製品です。

まとめ：Lambda Durable Functionsの要点

• 東京で使えるか：使える。GA（2025年12月2日）はオハイオのみ、2025年12月18日に東京を含む14リージョン、2026年4月22日に大阪を含む16リージョンへ拡大。
• 15分制限との関係：オンデマンドでは1回の呼び出しは最大15分。待機時の中断と再開時のリプレイにより、非同期のワークフロー全体は最大1年続く。
• 呼び出し方で上限が変わる：非同期呼び出しは最大1年、同期呼び出しは15分。SQSやKinesisのイベントソースマッピングは実行全体で15分（Lambda Managed Instancesなら90分）。長く動かすなら中継関数から非同期で起動する。
• 東京の料金：通常のLambda料金に加え、耐久操作100万回あたり10.60ドル、書き込み1GBあたり0.33ドル、保持1GB月あたり0.20ドル。オハイオより約3割高い。
• SDK：JavaScript／TypeScript・Python・Javaは2026年10月に3.0系、.NETは2026年7月にGA、Go版もv1.0.0。メジャー版は固定して同梱する。
• 使い分け：処理がLambdaの中で完結しコードで書きたいならDurable Functions、多数のAWSサービスをつなぐ・図で共有するならStep Functions。

チェックポイントとリプレイで動く仕組み

Durable Functionsは特別な実行基盤ではなく、通常のLambda関数にチェックポイントとリプレイの仕組みを足したものです。SDKでハンドラを包むと、stepやwaitといった耐久操作を呼ぶたびに結果がAWS側に記録されます。待機に入ると関数はいったん終了し、時間が来るか外部からコールバックが届くと、Lambdaが関数をもう一度呼び出します。SDKはコードを先頭から実行し直し、記録済みのステップは中身を実行せず保存した戻り値を返します（AWS公式ドキュメント「Lambda durable functions」）。

1回の呼び出しは15分のままという制約

オンデマンド（既定）のLambda関数では、1回の呼び出しのタイムアウト上限は今も900秒（15分）で、Durable Functionsを有効にしても変わりません。変わるのは、待機中は関数が止まっているので15分の時計が進まないという点です。たとえば「在庫を確保する→10分置く→上長の承認を最大24時間待つ→出荷する」という流れは、各ステップが15分以内で終われば、全体が数日かかっても1本の実行として書けます。逆に、1つのステップの中で20分かかる変換処理は、Durable Functionsでも途中で切れます。この場合はステップを分割するか、ECSなど別の実行環境を検討します。Lambda全般の制限と料金体系はAWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説で整理しています。

リプレイ時の完了済みステップの省略と再実行条件

後述の承認待ちワークフローをローカルのテストSDKで実行すると、関数は「最初の呼び出し」「10分の待機明け」「コールバック到着後」の3回呼ばれますが、在庫確保のステップ本体が実行されたのは1回だけでした。2回目以降は記録済みの結果が返るためです。ただし公式は、ステップの既定を少なくとも1回（at-least-once）と定めています。ステップが完了を記録する前に関数が落ちると、そのステップは再実行されます。決済やDB書き込みのステップには、注文IDなどを使った冪等キーが必要です。

リプレイが成り立つ前提として、ステップの外のコードは毎回同じ結果を返す必要があります。乱数、現在時刻、外部APIの呼び出しは必ずステップの中に入れます。ステップの外でDate.now()を使って分岐すると、再開のたびに別の道を通り、記録と食い違って失敗します。

東京・大阪リージョンの対応状況と対応ランタイム

対応リージョンは段階的に広がりました。拡大の日付はAWSの告知の掲載日です（14リージョン拡大の告知、16リージョン拡大の告知）。

対応ランタイムの一覧に載っているのは次の9種類ですが、使えるのはこれだけではありません。2026年7月28日の機能拡張により、対応するDurable Execution SDKを同梱すれば（自作のSDKも可・検証用の適合テストが公開済み）、Lambdaがサポートするほかのマネージドランタイムやカスタムランタイムも利用できます。下表には一覧掲載の9種類と、OS専用ランタイムを使うGoの例を示します。

Java版SDKは2026年4月21日、.NET版SDKは2026年7月23日にGAになりました。Go版はGitHubで2026年10月15日にv1.0.0が公開され、OS専用ランタイムのprovided.al2023で動かします。

SDKのメジャー版を固定して同梱する理由

Node.jsとPythonのランタイムにはSDKが同梱されていますが、公式は本番ではデプロイパッケージに含め、メジャー版を固定するよう求めています。新しいメジャー版が実行中のワークフローを壊しうるためです。実際、2026年10月26日に出たJavaScript版3.0.0とPython版3.0.0では、計測用プラグインの登録方法が変わり、旧形式のプラグインを渡すと初期化時にPluginLoadErrorで止まります。stepやwaitの書き方は2系から変わっていません。package.jsonなら"^3.0.0"、requirements.txtならaws-durable-execution-sdk-python>=3,<4のように上限を付けておきます。

呼び出し方式ごとの実行時間の上限

「最大1年」はどの呼び出し方でも成り立つわけではありません。呼び出し方式のドキュメントによると、上限は次のとおりです。

同期呼び出しでは、呼び出し元が待機を含めた実行全体の完了を待ちます。API Gateway経由では、Lambda側の上限とは別にAPI Gatewayの統合タイムアウトが適用されるため、クライアントが15分待てるとは限りません。承認待ちは非同期で起動し、結果を別のリクエストで取得する構成にします。

SQSから呼ぶと実行全体が15分に縛られる仕組み

イベントソースマッピングは耐久関数を同期で呼び出し、実行全体が終わるまで次のバッチに進みません。そのため、待機を含めた合計が15分を超えると実行はタイムアウトで失敗し、イベントソースマッピング側の再試行設定に従って処理されます。DurableConfigの実行タイムアウトをこの上限より長く設定していると、イベントソースマッピングの作成自体が失敗します。

関数をLambda Managed Instances（EC2インスタンス上でLambdaを動かす実行モード）で動かすと、この上限が90分に延びます。たとえば「SQSのメッセージを受けて2分処理し、外部のコールバックを20分待つ」流れは、オンデマンドでは失敗し、Managed Instancesなら通ります。2時間待つ流れはどちらでも失敗します。

15分を超えるワークフローの中継関数による非同期起動

公式が示す回避策は、イベントソースマッピングと耐久関数の間に、耐久実行を有効にしない普通の関数を挟む方法です。中継関数はメッセージを受け取り、耐久関数を非同期で起動してすぐに返ります。この時点でSQS側の処理は成功扱いになるため、その後に耐久実行が失敗しても元のイベントソースマッピングは再試行しません。耐久関数側にDLQと失敗通知を設定します。起動時にDurableExecutionName（英数字・ハイフン・アンダースコアで1〜64文字）を渡すと、実行中または完了後の履歴保持期間内であれば、同じ名前と同じペイロードの呼び出しは既存の実行を返します。保持期間を過ぎると同名でも新しい実行になるため、長期間の重複防止は業務側でも管理します。

import boto3

lam = boto3.client("lambda")

def handler(event, context):
    for record in event["Records"]:
        lam.invoke(
            FunctionName="order-workflow:prod",        # 修飾子付きで指定
            InvocationType="Event",                    # 非同期なら最大1年まで走れる
            DurableExecutionName=record["messageId"],  # 保持期間内の再配信は同じ実行に
            Payload=record["body"].encode(),
        )

イベントソースマッピングから直接起動した場合、この冪等性は効きません。再試行のたびに新しい実行が始まるため、直接つなぐ構成では関数側で重複を防ぐ処理が必要です。SQSとLambdaの接続設定そのものはEventBridgeからSQS・Lambdaへつなぐ設定｜キューポリシー・FIFO・部分バッチ応答とDLQ【2026年10月】で扱っています。

SDKで承認待ちワークフローを実装する手順

有効化とIAM権限（新規作成時のみ）

耐久実行は関数を作るときにしか有効化できず、既存の関数には後付けできません。作成時にDurableConfigを渡し、その中のExecutionTimeout（秒、1〜31,622,400）は必須です。省くとInvalidParameterValueExceptionで作成に失敗します。RetentionPeriodInDays（完了後に履歴を残す日数、1〜90、既定14）とKMSKeyArnは任意です。実行ロールには、チェックポイント用のlambda:CheckpointDurableExecutionとlambda:GetDurableExecutionStateを含む管理ポリシーAWSLambdaBasicDurableExecutionRolePolicyを付けます。

aws lambda create-function \
  --function-name order-workflow \
  --runtime nodejs24.x \
  --role arn:aws:iam::123456789012:role/order-workflow-role \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --durable-config '{"ExecutionTimeout": 172800, "RetentionPeriodInDays": 14}'

JavaScriptで書く承認待ちフロー

在庫確保→10分の待機→上長の承認を最大24時間待つ、という流れです。withDurableExecutionでハンドラを包み、渡されるcontextから耐久操作を呼びます。SDK 3.0.0とテストSDK 1.3.2で、在庫確保と承認通知をスタブに置き換えたローカルテストの成功を確認しました。下の抜粋ではreserveStockとsendApprovalRequestの定義を省略しているため、そのままでは実行できません。

import { withDurableExecution } from "@aws/durable-execution-sdk-js";

export const handler = withDurableExecution(async (event, context) => {
  // 完了すると結果が記録され、再開時は中身を実行せず結果だけ返る
  const stock = await context.step("reserve-stock", async () =>
    reserveStock(event.orderId)
  );

  // 待機中は関数が止まり、実行時間の課金も止まる
  await context.wait("cool-down", { minutes: 10 });

  // callbackId を承認者に送り、API経由の応答を最大24時間待つ
  const decision = await context.waitForCallback(
    "manager-approval",
    async (callbackId) => sendApprovalRequest(event.orderId, callbackId),
    { timeout: { hours: 24 } }
  );

  return { stock, decision: JSON.parse(decision) };
});

承認する側は、受け取ったcallbackIdを付けてSendDurableExecutionCallbackSuccess APIを呼びます（却下はSendDurableExecutionCallbackFailure）。コールバックの戻り値は文字列で届くので、JSONを渡すなら受け側でパースします。

Python SDKによる承認待ちフローの実装

Python版は同期メソッドで、async／awaitは使いません。ステップにする関数を@durable_stepで修飾し、context.stepにはその呼び出しを渡します。Python 3.13とSDK 3.0.1、テストSDK 1.4.0で実行を確認しました。

import json

from aws_durable_execution_sdk_python import (
    DurableContext, StepContext, durable_execution, durable_step,
)
from aws_durable_execution_sdk_python.config import Duration, WaitForCallbackConfig

@durable_step
def reserve_stock(step_context: StepContext, order_id: str) -> dict:
    return {"order_id": order_id, "reserved": True}

def send_approval_request(callback_id: str, ctx) -> None:
    ...  # メールやチャットに callback_id を載せて送る

@durable_execution
def handler(event: dict, context: DurableContext) -> dict:
    stock = context.step(reserve_stock(event["order_id"]))
    context.wait(Duration.from_minutes(10), name="cool-down")
    decision = context.wait_for_callback(
        send_approval_request,
        name="manager-approval",
        config=WaitForCallbackConfig(timeout=Duration.from_hours(24)),
    )
    return {"order": stock, "approved": json.loads(decision)["approved"]}

ほかに使える耐久操作は、条件を満たすまでポーリングするwait_for_condition、別のLambda関数を呼んで結果を待つinvoke、並列実行のparallelとmap、操作をまとめるrun_in_child_contextです。invokeで呼べるのは同じAWSアカウント内の関数に限られます。

SAM・CDK・Terraformでの設定

AWS SAMでは関数にDurableConfigを書き、AutoPublishAliasでバージョンとエイリアスを自動発行します。

Resources:
  OrderWorkflow:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: order-workflow
      Runtime: nodejs24.x
      Handler: index.handler
      CodeUri: ./src
      DurableConfig:
        ExecutionTimeout: 172800     # 秒。この例は48時間
        RetentionPeriodInDays: 14
      Policies:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicDurableExecutionRolePolicy
      AutoPublishAlias: prod         # 呼び出しは order-workflow:prod で

CDKではdurableConfig: { executionTimeout: Duration.hours(48), retentionPeriod: Duration.days(14) }のようにDuration型で、Terraformではdurable_configブロック（execution_timeout・retention_period）で指定します。TerraformはAWSプロバイダー6.25.0以降が必要です。

ローカルテストと本番の監視

テストSDKの時間スキップによるローカル実行

言語ごとにテストSDK（@aws/durable-execution-sdk-js-testing、aws-durable-execution-sdk-python-testing）があり、AWSにデプロイせずに耐久実行をローカルで再現できます。待機時間を飛ばすモードが既定で有効なため、10分の待機も一瞬で終わります。次はPython版のテストで、承認のコールバックを送って最終結果を確かめる例です。

import json
from aws_durable_execution_sdk_python_testing import DurableFunctionTestRunner
from approval import handler

with DurableFunctionTestRunner(handler=handler) as runner:
    arn = runner.run_async(
        input=json.dumps({"order_id": "A-1001"}),
        execution_timeout=172800,   # 既定300秒のままだと10分の待機で打ち切られる
    )
    callback_id = runner.wait_for_callback(arn)
    runner.send_callback_success(callback_id, result=json.dumps({"approved": True}).encode())
    result = runner.wait_for_result(arn)
    print(result.execution_status)  # ExecutionStatus.SUCCEEDED

テストランナーの実行タイムアウトは既定で300秒です。待機を飛ばしていても待機時間の合計はこれに数えられ、既定値のままでは「Execution timed out.」で失敗しました。ランタイムのコンテナで動かしたい場合は、AWS SAM CLIのsam local invoke MyDurableFunction --durable-execution-name my-testで実行し、別のターミナルからsam local callback succeed <callback-id>で承認を返せます。デプロイ済みの関数に対して同じテストを流すDurableFunctionCloudTestRunnerもあり、こちらは呼び出し元にlambda:GetDurableExecutionHistoryなどの権限が必要です。

CloudWatchメトリクスとEventBridgeによる失敗検知

本番では、DurableExecutionFailed・DurableExecutionTimedOut・ApproximateRunningDurableExecutionsUtilization（実行中件数がクォータの何％か）にアラームを付けます。実行の状態が変わるたびにEventBridgeへDurable Execution Status Changeイベントが送られるため、FAILED・STOPPED・TIMED_OUTを拾って通知できます。Lambdaの送信先（destinations）は耐久関数では使えません。非同期呼び出しの失敗を残すにはデッドレターキューを設定します。

東京リージョンの料金と試算

料金は「通常のLambda料金」と「耐久実行の料金」の合計です。通常の料金には、待機明けやリトライで関数が呼び直された分の呼び出しと実行時間も含まれます。待機中に実行時間の課金が止まるのは、料金ページの表現では「オンデマンドの関数」の場合です。Managed Instancesで動かす関数は、インスタンス単位の料金がかかり続けます。

耐久実行の単価（東京とオハイオ）

次の表は、AWS Price List Bulk APIの東京の価格ファイルとオハイオの価格ファイル（版20261030234255、2026年10月30日公開）から抽出した単価です。

耐久操作の回数は操作の種類で変わります。実行の開始が1回、ステップが1回（リトライ1回ごとに+1）、待機が1回です。waitForCallbackは内部でコンテキスト・コールバック・送信用ステップの3回になり、コールバックで受け取ったデータは2つ分書き込まれます。保持料金は、実行中と完了後の保持期間の両方にかかります。

承認フローを月100万件動かした場合の試算

前述のJavaScript版の承認待ちフローを東京で月100万件動かす場合です。条件は、入力8KB・在庫確保ステップの戻り値32KB・承認データ32KB・最終出力64KB（承認通知ステップの戻り値は無視できる大きさ）、承認は平均1日で届き、完了後14日保持、メモリ1GBのArm関数で処理時間は1件あたり合計3秒です。保持料金は全データを15日分持つ保守的な計算にし、無料枠は他の関数が使っていない前提です。

1件あたりの書き込み168KBの内訳は、入力8KB・ステップの戻り値32KB・承認データ2つ分64KB・最終出力64KBです。耐久実行の料金（135.84ドル）は実行時間の料金の3倍を超えています。この試算で効くのは操作回数と書き込み量です。ステップを細かく割りすぎると操作回数が増え、大きなデータをステップの戻り値で受け渡すと書き込み量が膨らみます。大きなデータはS3に置き、キーだけを戻り値にします。Lambda本体の料金を東京の単価で計算する手順はAWS Lambdaの料金を東京リージョンの実額で計算する：付帯課金の内訳と単価を下げる手順にまとめています。

実行タイムアウト・履歴保持とクォータの上限

設計時に効くのは、1回の実行あたりの操作数と書き込み量の上限です。どちらも引き上げできません（Lambdaのクォータ）。

同時実行中500万件と毎秒3,000件は東京の値で、バージニア北部・オレゴン・アイルランドはその2倍です。操作数30,000回の上限は、mapで大量の要素を回すときに効きます。mapは要素1件ごとに子コンテキストを作るため、1万件の要素それぞれで2回ずつステップを呼ぶと、それだけで3万回を超えます。件数が読めない一括処理は、実行を分けるか、ステップの中でまとめて処理します。

Step Functionsとの使い分け

どちらもワークフローの状態を自動管理しますが、AWSの比較ページは、Durable Functionsを「Lambdaの中のアプリケーション開発」、Step Functionsを「AWSサービスをまたぐオーケストレーション」と位置づけています。

判断の目安は、Lambda以外のAWSサービスを何個つなぐかです。Glue・ECS・Bedrock・SNSなどを順に呼ぶ流れや、業務担当者にも図でフローを確認してもらう必要がある場合はStep Functionsを選びます。処理の大半がLambdaの中にあり、開発者だけで実装からテストまで回すならDurable Functionsが向きます。両方を組み合わせ、上位の業務フローはStep Functions、その中の1タスクを耐久関数にする構成も公式が示しています。Step FunctionsとLambdaの役割分担はStep FunctionsとLambdaの違い：役割の切り分けとlambda:invoke・リトライの実装手順で詳しく扱っています。

AWS以外も選択肢に入れるなら、同じ「コードで書く耐久実行」の代表はTemporalです。マルチクラウドやオンプレミスで同じワークフローを動かす必要があるならTemporal、AWSの中で完結しサーバー運用を持ちたくないならDurable Functions、という分け方になります。Temporalの仕組みはTemporal Workflowとは？仕組み・Pythonの実測結果・Cloud料金を解説を参照してください。既存のLambda構成にワークフローを組み込む設計からまとめて相談したい場合は、一創のAWSを含むインフラ構築の支援も利用できます。

採用を見送る場面と運用の落とし穴

数秒で終わる単発のイベント処理や、状態を持たない変換処理には使いません。実行の開始だけで耐久操作1回分の料金がかかります。導入する場合は、次の4点を最初に決めておきます。

• $LATESTで本番を動かさない：耐久関数は修飾子なしの関数名では呼べず、バージョン・エイリアス・$LATESTのいずれかを付けます。$LATESTで始めた実行は開始時のコードに固定されず、待機中にコードを更新すると新しいコードで再開します。
• ステップ名と順序の変更は新しいバージョンで出す：リプレイは記録とステップ名で照合するため、$LATESTのまま待機中の実行が残っている状態でステップ名や順序を変えると、その実行は再開できなくなります。番号付きバージョンやエイリアスで始めた実行はエイリアスを更新しても旧バージョンで再開するので、変更は新しいバージョンとして発行し、新しい実行だけに適用します。
• 失敗の受け皿をDLQで用意する：Lambdaの送信先が使えないため、非同期呼び出しの失敗はデッドレターキューとEventBridgeのイベントで拾います。
• 別アカウントの関数は呼べない：invokeで呼べるのは同じアカウントの関数だけです。アカウントをまたぐ処理は、Step FunctionsかEventBridgeで橋渡しします。

Lambdaを中心にしたシステム全体の構成パターンはサーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説で比較しています。

よくある質問

Lambda Durable Functionsは東京リージョンで使えますか？

使えます。2025年12月18日に東京を含む14リージョンへ拡大しました。大阪は2026年4月22日の拡大で対応しています。

既存のLambda関数を後から耐久実行に切り替えられますか？

できません。耐久実行は関数の作成時にしか有効化できないため、新しい関数をDurableConfig付きで作り直します。

SQSから呼び出すと15分で失敗するのはなぜですか？

イベントソースマッピングは耐久関数を同期で呼び出し、待機を含む実行全体の完了を待つためです。上限は15分で、Lambda Managed Instancesなら90分です。それより長い処理は、中継関数からInvocationType=Eventで非同期に起動します。

待機している間も料金はかかりますか？

オンデマンドの関数なら、待機中の実行時間の料金はかかりません。ただし待機1回ごとに耐久操作の料金がかかり、待機中のデータ保持料金（東京で1GB月あたり0.20ドル）も発生します。

Azure Durable Functionsとは何が違いますか？

名前は似ていますが、Azure FunctionsのDurable Functions拡張とは別の製品です。コードを記録と照合しながらリプレイする考え方は共通していますが、AWS版はLambdaの機能として動き、SDK・API・料金体系はすべてAWS独自のものです。

関連記事

• AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説
• Lambda Managed Instancesとは？料金の実額・90分実行・標準Lambdaとの使い分け【2026年9月】
• Step FunctionsとLambdaの違い：役割の切り分けとlambda:invoke・リトライの実装手順
• ステートマシンとは？状態遷移の設計と実装パターン・採用判断を実装者目線で解説
• サーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説