月初の集計だけが毎回落ちる。ログには処理中で切れた記録が残り、再実行すると途中まで登録済みのデータが二重になる。15分の実行時間上限に当たっている処理は、こうした形で見つかることがあります。
AWSは2026年9月9日に、Lambda Managed Instancesでの90分タイムアウトを発表しました。従来の15分から6倍です。ただしどの呼び出しでも延びるわけではありません。ここを取り違えると、設計会議が噛み合わなくなります。
延びる呼び出しと、延びない呼び出し
AWSの発表とドキュメントでは、対象はLambda Managed Instances（LMI）上での非同期呼び出しと、イベントソースマッピング（ESM）経由の呼び出しです。ただし、Amazon MQとAmazon DocumentDBのイベントソースマッピングは15分のままです。同期呼び出しの上限も15分に据え置かれ、関数のタイムアウトを15分より長く設定していても、同期で呼び出すと15分で打ち切られます。LMIが使えるリージョンはすべて対象です。
APIの裏側でそのまま待たせる形の処理は、これまでどおり15分で切れます。つまり「Lambdaが90分になった」の一言では、自社の困っている処理が救われるかどうかは判断できません。まず、落ちている処理がどの呼び出し方なのかを確認してください。
| 処理の形 | 上限 | 置き場所の候補 |
|---|---|---|
| APIの応答を待たせる同期処理 | 15分のまま | 受付だけ返し、本体を非同期へ切り出す |
| キュー・イベント起点の非同期処理 | 条件付きで最大90分（Amazon MQ・DocumentDB起点は除く） | LMIでの実行を検討 |
| 数時間かかる一括処理 | 90分でも足りない | バッチ基盤・コンテナ実行へ |
長時間化すると、増える宿題がある
実行時間が延びると、短時間の関数では意識しなくてよかった前提が効いてきます。AWSの解説記事でも、一時的な認証情報やトークンが実行時間いっぱい有効かを確かめるか途中で取り直すこと、再試行や重複した配信で同じ処理が二度走っても結果が変わらないようにすること（冪等性）が注意点として挙げられています。
具体的には、次の4点を設計時に決めます。
- 接続の寿命。データベースや外部APIの接続が、90分の間に切れたときの再接続と再開位置
- 認証情報の期限。処理の途中で期限を迎える前提で、取り直す仕組みを持つ
- 冪等性。同じイベントが再送されたときに、二重登録・二重課金が起きない作り
- 再開の単位。全件やり直しか、途中から再開かを、失敗時のコストで決める
3と4は、長時間バッチで事故につながりやすい部分です。「落ちたらもう一度実行する」運用のまま実行時間だけ延ばすと、失敗時の被害も6倍の時間分に広がります。
LMIには、もう1つ前提の違いがあります。ドキュメントによると、タイムアウトしても関数のコードは強制終了されず、実行環境の中で動き続けます。呼び出し元には失敗が返るため、再試行と重なると同じ書き込みが二度行われることがあります。残り時間を確かめて、処理の区切りごとに止められる作りにしておくことが前提になります。
監視の作りも変わります。15分で終わる前提なら、失敗の検知はタイムアウトや異常終了で足りました。90分動く処理では、途中で止まっているのか進んでいるのかを外から判断できる必要があります。処理件数の進捗をログや指標として出し、想定時間を超えた時点で気付ける形にしてから移してください。
課金の形が変わる点を見落とさない
LMIは、Lambdaの関数をマネージドなEC2インスタンス上で動かす形態です。料金ページによると、用意したEC2インスタンスの料金に管理手数料とリクエスト料金が加わる形で、リクエストごとの実行時間には課金されません。実行時間に対する課金が中心の通常のLambdaとは、費用の出方が変わります。稼働率が高い処理ほど有利になり、たまにしか動かない処理では割に合わないことがある、という方向で考えるのが実態に近い判断です。
具体的な金額は契約リージョンとインスタンスの種類で変わるため、この記事では数字を置きません。移行を検討する場合は、公式の料金ページで現在の条件を確認し、現行構成の実測値と並べて比較してください。ベンダーの事例値をそのまま自社の削減額として扱わないことをお勧めします。
移す前に、落ちている理由を確かめる
15分に当たっている処理でも、時間がかかっている理由が取得し直しや無駄なループにあることは珍しくありません。置き場所を変える前に、処理時間の内訳を取ります。サーバーレスへの移行そのものの判断材料はLambda Web Adapterでの移行、状態を持つ処理の扱いはmicroVMとステートフルな処理にまとめています。
処理の本数が増えてきた段階では、置き場所よりも順序と再実行の管理が問題になります。その手前の判断はワークフロー基盤を持つか持たないかで扱いました。
2026年9月24日にWeb検索でAWSの発表、解説記事、ドキュメント、料金ページを確認して整理した調査記事です。LMIでの90分実行や費用の実測は行っていません。上限・対象・料金は変更される場合があるため、構成を決める前に公式ドキュメントで確認してください。
長時間バッチの置き場所や、再実行に耐える設計の見直しは、グリームハブへご相談ください。
