2026/02/20   AWS re:Invent 2025 新機能「やってみた」報告会 〜コンピューティング編〜 クラスメソッド株式会社 浅野 晴輝 ⾮同期バッチ処理をLambda Durable Functionsのみでやってみる 

⾃⼰紹介 2 ● 最近やっていること ○ CDK ○ AWS環境構築⽀援など ○ アプリ開発⽀援 ● 好き‧興味のある技術 ○ コンテナ ○ サーバーレス ○ アプリ開発 ● 技術ブログ記載してます！ ● 名前（ニックネーム） ○ 浅野 晴輝 ● 所属 ○ クラスメソッド株式会社 ○ クラウド事業本部コンサルティング部 

Lambda Durable Functionsとは？ 

Lambda Durable Functionsとは？ 4 主な特徴 ● 最⼤１年間の実⾏が可能(条件あり) ● チェックポイント‧リプレイ機能⽅式 ● 使い慣れたプログラミング⾔語でワークフローの処理 が記述が簡潔に可能 ○ SDKによる豊富な機能(map,wait,callback) ○ if⽂による条件分岐など リリース情報(2026/02現在) ● re:Invent 2025で発表 ● 現時点で東京リージョンを含む15リージョンで対応 ● 対応ランタイム ○ Python 3.13 / 3.14 ○ Node.js 22 / 24 実⾏時間15分の壁を越えて複雑なワークフローを処理できる新しいLambda関数の実⾏⽅式！ Durable = 「耐久性のある」 

チェックポイントについて ● 「DurableContext」によって各操作を耐久性のある実⾏と して利⽤可能 ● context.step() や context.map() などの操作が完了する と、SDK が⾃動的にチェックポイントを作成 ● チェックポイントには操作の結果が保存され、Lambda が 内部で管理（ユーザー管理不要） ● チェックポイントのペイロードは 最⼤ 256KB（超過する と再実⾏される） ● datetime.now() や uuid.uuid4() など実⾏ごとに異なる値 を返す処理は、context.step()で囲まないと再試⾏時に異な る値になるので注意が必要(決定論的なコードの記述) Lambda Durable Functionsとは？ 5 チェックポイントによるリプレイ機能の仕組み from aws_durable_execution_sdk_python import durable_execution, durable_step, DurableContext # ステップ関数を定義 @durable_step def process_data(step_context, data: dict) -> dict: # 何らかの処理（この結果がチェックポイントに保存される） return {"processed": True, "id": data["id"]} @durable_execution def handler(event: dict, context: DurableContext): # ステップを呼び出し result = context.step(process_data(event)) return result コード例(Python SDK) 

Lambda Durable Functionsとは？ 6 ※画像は 公式ドキュメント から引⽤ チェックポイントによるリプレイ機能の仕組み 再試⾏（リプレイ） ● ランタイム障害や予期せぬエラーによって Durable Functoinが再試⾏され、コードが最初から評価され る仕組み ● 評価時にSDK がチェックポイントを参照し、完了済 みの操作はスキップされる（保存された結果を返 す） ● 再試⾏(リプレイ)されるタイミングは⼤きく分けて3 種類 ○ 特定のContext操作による処理(waitやcallback) ○ 各ステップ内でキャッチされない例外 ○ バックエンド側のシナリオ(インフラ障害、ラン タイムエラーなど) 

Lambda Durable Functionsとは？ バックエンドによる 再試⾏ ● インフラ障害‧ランタイムエ ラーによるサービス側要員 ● Invocation Timeoutによるタ イムアウト ● 制御は不可能(最⼤試⾏回数‧ バックオフ間隔など) 7 再試⾏(リプレイ)タイミングについて Durable Contextによる 特定の操作 ● 特定の待機(wait,callback等)で チェックポイントを作成 ● 無駄なコード実⾏を防⽌ ● 操作完了後にコード全体が再試 ⾏ ステップによる再試⾏ ● 各ステップでキャッチされない 例外を発⽣時 ● ステップごとに戦略設定が可能 (最⼤試⾏回数‧バックオフ間隔 ‧条件) 

Durable Functionsにおけるタイムアウト ● タイムアウトは２種類存在する ● 「Invocation Timeout」によって各関数がタイムアウト になると⾃動でDurable Functionsが再試⾏される ● 「Execution Timeout」は実⾏時に⾮同期呼び出し (InvocationType: Event)を⾏った時のみ最⼤1年間の実 ⾏が可能 タイムアウトになると「タイムアウト」として Durable Functionsが終了 ● 各ステップで⾏われる処理(関数呼び出しを含める) が 「15分以内」なら、「再試⾏を考慮して15分を超える処 理」も可能という意味 Lambda Durable Functionsとは？ 8 Durable Functionsにおける実⾏時間の理解 タイムアウト 実行時間 説明 Invocation Timeout 最大15分 各ステップで呼び出される Lambda関数実行時間（従来と 同じ） Execution Timeout 最大1年間 実行全体の合計時間（待機時 間含む） 

Lambda Durable Functionsとは？ 9 料⾦体系について 項目 料金 リクエスト $0.20 / 100万リクエスト 実行時間(x86_64) $0.0000166667 / GB / 秒 実行時間(Arm) $0.0000133334 / GB / 秒 項目 料金 Durable Functions操作 $10.60 / 100万操作 データ書き込み $0.33 / GB データ保持 $0.20 / GB / 月 通常Lambda関数の料⾦体系 Durable Functions特有の課⾦体系 通常のLambda実⾏料⾦ + Durable Functions特有の料⾦ ● Durable Functions操作に対する課⾦ ○ 「実⾏の開始」、「ステップ完了」、「待機」、 「コールバック作成」など Durable Contextによる操 作 ● データに対する課⾦ ○ 各操作による実⾏履歴のデータを「書き込む量」と 「保持する量」によって課⾦される ○ 保持期間「1 ~90⽇」までのユーザー側で設定可能 （デフォルト14⽇） ※東京リージョン単価 ※無料枠あり 

体系的な違い Lambda Durable Functionsとは？ 10 Step Functions との使い分け 観点 Step Functions Durable Functions 記述方式 ASL (JSON/YAML) Python / Node.js 学習コスト 高 低 実行単位 ステートマシン 単一のLambda関数 状態管理 サービス側で管理 SDKにて管理 各フローの可視化 フローのビジュアル確認可能 可視化機能はなし ランタイム管理 AWS管理 Lambda環境として管理必要 AWSサービスとの統合 220+ のAWSサービス Lambda 内で実装 料金体系 状態遷移回数 実行時間 + 操作回数 

それぞれのユースケースと強み Lambda Durable Functionsとは？ 11 Step Functions との使い分け Step Functionsが向くケース ● ワークフローの可視化が重要 ● 複数のAWSサービスとオーケストレーションが 必要 ● SDKなしでネイティブにAWSサービスと統合が したい ● Express Workflowsなどで⾼頻度実⾏がしたい Durable Functionsが向くケース ● 標準的なプログラミング⾔語と使い慣れたツー ルでワークフローを開発したい ● コードで実⾏状態を細かく制御したい ● アプリケーションロジックをLambda関数だけ で制御したい ● 管理項⽬を増やしたくない 

⾮同期バッチ処理をやってみる 

「とあるECサイトのその⽇の売上をまとめてレポートを⽣成する⾮同期なバッチ処理」を考えてみる ● その⽇の取引と売上に関するデータ(10,000件程度)が毎⽇S3にCSVファイルとして保存される ● ⽇次で各レコードを検証‧加⼯(税額計算)し、その⽇の売上に関するレポートを作成したい ● ⾼額取引(100万円以上)は管理者にて承認作業が必要である ● 承認された取引データのみを外部の会計システムAPIに連携したい ● 却下された取引データは振り返れるように別途レポートとしてS3にまとめたい ● できるだけサーバーレスで障害に堅牢なアーキテクチャを構成したい ⾮同期バッチ処理をやってみる 13 シチュエーション 

⾮同期バッチ処理をやってみる 14 要件の掘り下げ 1. ⼤量のデータを検証‧加⼯して効率的に処理したい → データをチャンクに分割して処理する機能 2. ⾼取引データには⼈間の承認が必要 →コールバック機能による外部からの返答(承認‧却下)を待つ機能 3. 会計システムAPIとの連携 → レート制限などを考慮して待機時間と呼び出しに失敗した時のリトライ機能 4. レポートをS3に保存したい → 「承認」と「却下」で正しいレポートを⽣成する機能 5. 障害時のリトライにて処理済みレコードを再処理したくない → 状態を管理して進捗を記録する機能 

● Step FunctionsのStateを正しく使⽤するために各処理を責 務毎にTaskとして分割して実⾏する → Lambda関数が増えてデプロイ単位が増える ● 状態を保持するためにDynamoDBなどを構成する必要があ る (もしくはStep Functionsの変数機能など) → 状態管理が複雑化 ● API連携などのリトライ戦略をStateで実装する必要がある → ASL(JSONPath, JSONata)記述しにくい？ ● アプリケーションロジックがStep FunctionsとLambdaで混 在している →仕様変更時の影響範囲が読みにくい →複数サービスを横断してロジック確認が必要 →テスト困難 ⾮同期バッチ処理をやってみる 15 従来の構成なら‧‧‧ 管理が⼤変！ 

⾮同期バッチ処理をやってみる 16 Durable Functionsを使⽤した構成 ● 各責務ごとにLambda関数を分割する必要がなく、単⼀の Durable Functionsでステップ関数を使って処理を分割 → デプロイ単位がDurable Functions⼀つに ● リプレイを考慮した状態管理はDurable Functionsが担って くれる → 独⾃構成(DynamoDB等)が不要 ● API連携などのリトライ戦略をSDKで簡潔に設定 → コード量が少なく済む ● 全てのアプリケーションロジックをDurable Functionsのみ で管理できる → 仕様変更時の影響範囲が読みやすい → Durable Functionsを確認すればそこに全てが記載 してある →ロググループ管理、X-Rayによるトレースなども設 定しやすい 

デモ⽤ソースコード ● https://github.com/haruki-0408/20260220-demo-durable-functions/ ⾮同期バッチ処理をやってみる 17 実際にやってみる‧‧‧ 

⾮同期バッチ処理をやってみる 18 まず売上データをS3に保存 id customer product amount quantity region category timestamp 00001 会社A 高級ドライヤー 85,000 2 東京 beauty 2025-01-15T00:00:00 00002 会社B 美容液セット 32,000 2 東京 beauty 2025-01-15T00:00:00 00003 会社C 業務用エステ 機器 1,200,000 2 東京 beauty 2025-01-15T00:00:00 00004 会社D シャンプー 15,000 2 東京 beauty 2025-01-15T00:00:00 00005 会社E 高級マッサージ チェア 1,800,000 2 東京 beauty 2025-01-15T00:00:00 ⾼額取引が点在 

⾮同期バッチ処理をやってみる 19 Durable Functionsのアップロード ~ 実⾏ ポイント ● 必ず関数のバージョンを発⾏して実⾏ ● 「invocation-type: Event」として⾮同期実⾏ ● 「永続実⾏」タブから実⾏状況を確認可能 #!/bin/bash FUNCTION_NAME="demo-durable-function" # Durable Functionsのアップデート zip -q function.zip lambda_function.py aws lambda update-function-code \ --function-name "$FUNCTION_NAME" \ --zip-file fileb://function.zip # バージョンの発⾏aws lambda publish-version \ --function-name "$FUNCTION_NAME" # Lambda関数の実⾏ aws lambda invoke \ --function-name demo-durable-function:20 \ --invocation-type Event \ --cli-binary-format raw-in-base64-out \ --payload '{"date": "2025-01-15"}' response.json 

⾮同期バッチ処理をやってみる 20 Durable Functionsの実⾏画⾯確認 ポイント ● Durable Context操作が「サブタイプ」として表⽰ ● タイムライン付きで現在の実⾏状態が確認可能 ● 承認待ちのコールバック待機が「開始」されている ● 各フローのビジュアル機能はなし 

⾮同期バッチ処理をやってみる 21 Durable Functionsに対してコールバックを返却する ポイント ● Durable FunctionsからコールバックIDを受け取る ● API ‧CLI等でコールバックIDとペイロードを返却 ● コールバックが「開始」→「成功」になること確認 # ⼈間による承認処理 コールバックID返却 CALLBACK_ID="XXXXXXXXXX" aws lambda send-durable-execution-callback-success \ --callback-id "$CALLBACK_ID" \ --result $(echo -n '{"approved_ids": ["00003", "00005"]}' | base64) \ --region ap-northeast-1 

⾮同期バッチ処理をやってみる 22 Durable Functionsの処理が成功したことを確認 ポイント ● 永続オペレーションのステータスが「成功」 ● 全体の処理時間が「15分」を超えて実⾏できること が確認 

⾮同期バッチ処理をやってみる 23 実⾏結果の確認 (却下レポート) { "date": "2025-01-15", "rejected_count": 50, "total_amount": 152577184, "records": [ {  "id": "00135",  "customer_name": "会社E6",  "product": "業務⽤美容機器セット",  "amount": 1164511,  "quantity": 2,  "region": "広島",   … // 省略,  "processed": true }, ….. // 省略 } 

⾮同期バッチ処理をやってみる 24 実⾏結果の確認 (承認を含めたサマリレポート) {   "date": "2025-01-15",  "summary": {    "total_approved": 9950, "total_rejected": 50, "approved_sales": 321790602, "rejected_sales": 152577184 } } 

まとめ 25 ● Lambda関数単体で、最⼤1年間のステートフルなワークフロー実⾏が可能 ● チェックポイントとリプレイ機能により、状態管理と障害復旧をSDKが⾃動化 ● 従来のStep Functionsと複数Lambdaの組み合わせに⽐べアーキテクチャが⼤幅にシンプル化 ● コード中⼼で複雑なロジック、リトライ戦略、⼈間による承認を含むフローの制御に最適。 ● 通常のLambda料⾦に加え、DurableFunctions特有の操作とデータ量に対して課⾦される。 ● ログ管理⽅法、テスト⽅法に関してもSDKにて提供されている ● 設計次第でリプレイを含め実⾏が15分を超えるワークフローも実現できるが、それ⽬的で使⽤しない⽅が良さそう 複雑なワークフローにぜひ「Lambda Durable Functions」をご検討ください！ 

参考リンク 26 ● AWS Lambda Durable Functions 公式ドキュメント ● GitHub SDK (Python) ● AWS News Blog - Durable Functions 発表記事 

No content