Lambda durable functions の上限引き上げ(operation 数3万と checkpoint サイズ1MB)を試してみた

はじめに

2026-10-13 に、Lambda durable functions の上限を引き上げるアップデートがありました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/10/aws-lambda-durable-gen-limit-increase/

新上限は durable functions が使える全リージョンに適用されます。1実行あたりの operation 数は 3,000 から 30,000 に、checkpoint の payload サイズは 256 KB から 1 MB になっています。

当記事では、旧上限を超える durable functions の実行を東京リージョンで試した結果を紹介します。

引き上げられた2つの上限

Lambda quotas では、どちらも利用者側から上限緩和を申請できない固定値として載っています。

https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html

step、wait、WaitForCondition、Parallel、Map を使う処理の operation 数は、SDK のドキュメントにある次の数え方で見積もれます。

• Execution の開始は 1、完了は 0
• step は 1 + 再試行回数
• wait は 1
• WaitForCondition は 1 + poll 回数
• Parallel と Map は 1 + ブランチ数(ブランチ内の operation は別に数えます)

checkpoint のサイズは、シリアライズして永続化されるデータのバイト数で数えます。

https://docs.aws.amazon.com/lambda/latest/dg/durable-execution-sdk.html

operation 数 3,001 の実行を試す

引数をそのまま返すだけの step を 3,000 回呼ぶ関数(以下、関数 A)を作りました。再試行が起きなければ、Execution の開始の 1 と step 3,000 回で operation 数は 3,001 になります。

from aws_durable_execution_sdk_python import (
    DurableContext,
    durable_execution,
    durable_step,
)

@durable_step
def noop(step_context, i):
    return i

@durable_execution
def lambda_handler(event, context: DurableContext):
    n = event.get("steps", 3000)
    total = 0
    for i in range(n):
        total += context.step(noop(i))
    return {"steps": n, "sum": total}

入力は {"steps":3000} です。実行は SUCCEEDED でした。戻り値の sum は 4498500 で、0 から 2,999 までの合計と一致しました。

関数のタイムアウトは 900 秒に設定しました。開始から終了まで約7分かかり、Lambda の呼び出しは1回でした。履歴の StepSucceeded と StepStarted はどちらも 3,000 件で、再試行は起きていませんでした。CloudWatch の DurableExecutionOperations は Sum、Maximum とも 3,001 で、上の数え方と一致しました。旧上限を超える operation 数の処理を、分割せずに1つの実行で完了できました。

260 KiB の checkpoint を試す

260 KiB(266,240 文字)は、旧上限の 256 KB を 262,144 バイトと見ても超えるサイズです。次の処理をする関数(以下、関数 B)を作りました。入力の {"size":266240} で指定した長さの文字列を作り、その文字列とサイズ、SHA-256 を1つの step で返します。続けて5秒の wait をはさみ、次の step が受け取った payload の SHA-256 を再計算して照合します。

import hashlib

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

@durable_step
def make_payload(step_context, size):
    step_context.logger.info(f"make_payload executed: size={size}")
    h = hashlib.sha256(b"seed").hexdigest()
    s = ""
    while len(s) < size:
        h = hashlib.sha256(h.encode()).hexdigest()
        s += h
    data = s[:size]
    return {
        "size": len(data),
        "sha256": hashlib.sha256(data.encode()).hexdigest(),
        "data": data,
    }

@durable_step
def verify(step_context, payload):
    actual = hashlib.sha256(payload["data"].encode()).hexdigest()
    ok = actual == payload["sha256"] and len(payload["data"]) == payload["size"]
    step_context.logger.info(f"verify executed: match={ok} size={len(payload['data'])}")
    return {"match": ok, "size": len(payload["data"]), "sha256": actual}

@durable_execution
def lambda_handler(event, context: DurableContext):
    size = event.get("size", 266240)
    context.logger.info("handler invoked")
    payload = context.step(make_payload(size))
    context.wait(Duration.from_seconds(5))
    return context.step(verify(payload))

実行は SUCCEEDED で、戻り値の match は true でした。履歴では、make_payload step が保存した payload は 266,397 バイトでした。payload は、data に加えて size と sha256 を含む dict を {"t":"m","v":…} のような型タグ付きの JSON にしたものでした。そのため、文字列長の 266,240 より大きくなっていました。

Lambda の呼び出しは wait の前と後に1回ずつの計2回でした。2回目の呼び出しでは make_payload は再実行されず、verify は checkpoint から復元された値を受け取りました。CloudWatch の DurableExecutionOperations は 4 で、Execution の開始 1、step 1、wait 1、step 1 の合計と一致しました。

料金

durable functions 固有の料金だけを試算します。Lambda のコンピューティング料金は別にかかります。

東京リージョンの durable functions の単価は、operation が 100万あたり USD 10.60 です。データ書き込みは 1 GB あたり USD 0.33、データ保持は 1 GB-月あたり USD 0.20 です。保持期間は 1〜90 日で設定でき、既定は14日です（AWS Lambda の料金）。

関数 A と B の料金を、この単価から試算しました。データ保持は1日分として試算しています。

まとめ

durable functions の上限が、operation 数は10倍の 30,000、checkpoint は4倍の 1 MB に拡張されました。

今回の検証では、旧上限を超える実行が正常に完了することを確認できました。

これまで旧上限のために durable functions の処理を分割していた方や、採用を見送っていた方は、改めて評価いただくことをおすすめします。