Lambda durable functions が発表されました！

先ほど、AWS re:Invent 2025 の Opening Keynote with Matt Garman (KEY001) にて、AWS Lambda の新機能である Lambda durable functions が発表されました！

What's new
公式ドキュメント

一言で言えば、Lambda の実行の途中にチェックポイントを設置でき、設置したチェックポイントからの再開を行うことで、長時間実行する必要のあるワークフローやポーリングのような処理を、サーバーレスの体系で実現する新機能です。
リリースの 2025/12/3 時点で、us-east-2 でサポートされています。

この記事は Serverless アドベントカレンダー 3日目の記事です。

tl;dr

• Lambda の状態管理と長時間実行を簡単にする新機能
• 複数ステップの処理を単一の関数で書ける
• 実行途中で待機や一時停止が可能
• クラッシュしても途中から再開できる
• Python、JavaScript/TypeScript をサポート
• Lambda通常料金に加えて、Durable operation 数（100 万回あたり $8）+ チェックポイントへのデータ書き込み（GB あたり $0.25）+ チェックポイントデータの保持（GB-month あたり $0.15）

使い方

作成時に Lambda の Option として Durable を有効化します。

作成すると、いつもと少し違うマネジメントコンソールになります。

パッと見てわかるのは、Durable executions のタブが増えていることと、関数内に見慣れない@aws/durable-execution-sdk-jsがあることです。

スクリーンショット内のコードの内容

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

export const handler = withDurableExecution(async (event, context) => {
  // TODO implement

  await context.step('Step #1', (stepCtx) => {
    stepCtx.logger.info('Hello from step #1');
  });

  // Pause for 1 second without consuming CPU cycles or incurring usage charges
  await context.wait({ seconds:1 });

  // Context logger is replay aware and will not log the same message multiple times
  context.logger.info('Waited for 1 second');

  const message = await context.step('Step #2', async () => {
    return 'Hello from Durable Lambda!';
  });

  const response = {
    statusCode: 200,
    body: JSON.stringify(message),
  };
  return response;
});

まず @aws/durable-execution-sdk-js について解説します。これは、Lambda durable functions を記述するための新しいライブラリです。このライブラリが提供する withDurableExecution で Lambda Handler をラップすることで、handler 内から Durable Context にアクセスすることができます。
context にはメソッドとして、以下のようなものが生えています。

• step
• wait
• waitForCallback
• waitForCondition
• map
• parallel

勘のいい方はお気づきかもしれませんが、Step Functions の state の構成要素に似ていますね。

durable functions では、context.step や context.wait などの context.[method] の単位で実行をチェックポイント管理します。
このチェックポイントごとの状態を保持して、再開することができます。
百聞は一見にしかずということで実際に実行してみましょう。
いつも通り、Test タブから実行してみます。
先ほど見えていた、Durable Execution のタブを開いてみると、以下のように実行がリストアップされています。

実行の詳細を見てみます。

画像上側に、Step #1, c81e728d9d4c..., Step #2 のような表示があるのがわかります。これが context.step などと対応しています。
実行の過程を解説します。

1. Lambda 関数の実行が開始される
2. Step #1 が実行される
3. c81e728d9d4c...のwaitが実行され、1秒間 Lambda の実行が停止する
4. Lambda 関数の実行が再開される
5. Step #1, c81e728d9d4c... までの実行がチェックポイントに記録されており、スキップされる
6. Step #2 が実行される

ポイントは 3 と 5 です。3 で Lambda の実行が停止されている間、Lambda の実行時間による課金は行われません。そして wait が終了したタイミングで 5 のように Lambda が再開した場合、それまでの実行状態がチェックポイントに保存され、正常終了部分はスキップされます。

注意点として、チェックポイントに保存されるのは、context.step などの durable operation の入出力のみです。グローバル変数や return していない値は保持されません。次の operation に引き継ぎたい値は必ず return するようにしてください。
return していない値は、再開時に参照することはできません。変な例ですが、以下のようなイメージです。

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

// グローバル変数（durable な状態にはならない）
let globalCounter = 0;

export const handler = withDurableExecution(async (event, context) => {
  // Step #1 ではローカル変数とグローバル変数を触る
  const { valueB } = await context.step('Step #1', (stepCtx) => {
    const valueA = 1;
    const valueB = "hoge";

    // グローバル変数を更新
    globalCounter += 1;

    // 次のステップで使いたい値だけ return している
    return { valueB }; // valueA や globalCounter は返していない
  });

  await context.wait({ seconds: 1 });

  const message = await context.step('Step #2', async () => {
    // Step #1 から return された値は安全に参照できる
    const resultB = doSomething(valueB); // ← OK

    // 一方、グローバル変数に直接依存するのは NG
    // replay や別コンテナで再開された場合、0 に戻っている可能性がある
    const maybeWrong = doSomething(globalCounter); // ← こういう書き方は避ける

    // const resultA = doSomething(valueA); // ← valueA はそもそもスコープ外

    ...
  });
});

注意点

• 各ステップは副作用のない決定論的な処理になるよう実装しましょう。
  • 実行のたびインクリメントしたい数値などは step の return value に必ず含めてください。グローバルスコープなどに置いても保持されません。
• 各ステップは冪等になるように実装しましょう。
  • 必要に応じて、executionMode: 'AT_MOST_ONCE_PER_RETRY' オプションを利用することができます。
• durable functions の 最大実行時間は 365 日です。これはチェックポイントデータの保存/再開可能期間（= durable functions としての RUNNING な最大期間）がこの期間であることを意味します。
  • これは従来の Lambda 関数の実行時間とは異なる設定項目です。durable functions においては、この両方を設定できることになり、Lambda としての最大実行時間（max 15 分、従来からあるもの）については、retry/replay を前提としない、一度の関数実行時間の上限として有効です。
  • 呼び出し側が待つ必要のある同期実行および ESM からの実行では 最大実行時間が 15 分に制限されます。このケースで 15 分より長い処理を実現したい場合のワークアラウンドとして、Intermediary function パターンが紹介されていますので参照ください。公式ドキュメント
  • 他にデータ保持期間（チェックポイントデータを保存する期間）が設定でき、デフォルトで 14 日間、最大 90 日間に設定できます。こちらは durable functions の実行が完了した後にデータをどの期間保持するかの設定となります。

料金体系

従来の Lambda の料金 に加えて、durable 用の 3 つの課金ポイントがあります。

• 通常の Lambda 課金

  • リクエスト数 / 実行時間（GB-秒）は従来どおり

• Durable operations

  • 実行開始や step / wait などの durable operation 1 回ごとにカウント
  • 100 万 operations あたり $8

• データ書き込み

  • チェックポイントに保存するデータ量に対して課金
  • 書き込み 1GB あたり $0.25

• データ保持

  • 実行中＋完了後に保持しているチェックポイントデータ
  • 1GB-month あたり $0.15（保持期間は 1〜90 日で設定可能）

待機中は Lambda の実行時間課金は止まるが、チェックポイントのデータ保持には課金される点に注意が必要です。

想定されるユースケース

• 注文処理・決済フローなど、複数ステップにまたがるドメインロジックのオーケストレーション
• 承認ワークフローなど、人間の操作や外部システムの完了待ちを含む長時間プロセス
• 外部ジョブやバッチの完了を数分〜数時間ポーリングし続けるような処理
• LLM / 外部 AI サービスを組み合わせたマルチステップ推論パイプライン

できることは Step Functions に近いですが、関数レベルのロジック寄りのオーケストレーションにより強い親和性を持ちます。こちらも参照ください。

よくありそうな質問

durable functions を使えば、Lambdaの 15 分の実行時間制限を超えられますか？

A. Yes/No です。replay を前提としない 1 回の関数実行時間の上限としては依然として 15 分に留まりますが、以下のように step で処理を分割することで擬似的に 15 分以上の実行が可能になります。

1. step A (14分)
2. wait (2分)
3. step B
   この durable functions 関数は 合計 16 分を超えますが、step A が終了して wait する段階で Lambda 関数の実行が一度停止するため、 step B に入る段階で再度実行時間のカウントがスタートします。よって上記の durable functions は実行可能です。

実際にやってみた例

試したい方向けサンプルコード

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

export const handler = withDurableExecution(async (event, context) => {

  await context.step('Step #1', async(stepCtx) => {
    const sleep = (time) => new Promise((resolve) => setTimeout(resolve, time));
    stepCtx.logger.info('Hello from step #1');
    await sleep(840000)
  });

  await context.wait({ minutes: 2 });

  // Context logger is replay aware and will not log the same message multiple times
  context.logger.info('Waited for 1 second');

  const message = await context.step('Step #2', async () => {
    return 'Hello from Durable Lambda after 16 mins!';
  });

  const response = {
    statusCode: 200,
    body: JSON.stringify(message),
  };
  return response;
});

Step Functions との使い分けは？

A. あくまで現時点での個人の考えに近いものですが、

• ハンドリングしたい対象がドメインロジックや関数の場合・ドメイン内のロジック => durable functions
• ハンドリングしたい対象がインフラやAWSサービスの場合・ドメイン間の連携 => Step Functions
  のように捉えています。「Step Functions でオーケストレーションしている対象が無数の Lambda になっている」みたいなケースでは durable functions がハマると思いますが、逆に SDK 統合を活用しているケースでは、Step Functions の方がメリットが多いと思います。
  他にも「慣れたプログラミング言語で開発したい！」などのニーズがあれば durable functions を使う方がいい場合もあると思います。オーバーラップする部分も多いと思うので、必ずしも上記が答えではありません。

感想

Lambda とサーバーレスに全く新しいパラダイムをもたらす新機能が登場しましたね！
日本ではあまり耳にすることは少なかったですが、durable executionという文脈は、いくつかの専業のスタートアップがあるような最近ホットな領域で、ここに Lambda らしい形で新たな選択肢が生まれたのは非常に面白いと感じています。
durable functions を使ってどんなことが実現されていくのか、非常に楽しみです。私は早速、外部状態をポーリングするタイプのワークロードに適用する例を考えてみようと思います。他にも面白い使い方や、ご質問、間違いの指摘があればコメントをお願いします！