AWS Lambda で、関数のタイムアウトを最大90分まで設定できるようになった。対象は、Lambda Managed Instances(LMI) 上で動く関数の非同期呼び出しと、イベントソースマッピング(ESM)経由の呼び出しだ。Lambda durable functions の中の呼び出しにも、延長後のタイムアウトが適用される。同期呼び出しの上限は15分のまま据え置かれる。AWS が2026年9月9日付の What’s New で告知した。
15分の上限に合わせてアーキテクチャ側で回避策を組んできたチームが最初に見るべきなのは、関数がどこで動いているかと、どう呼ばれているかだ。どちらかが条件から外れていれば、非同期と ESM に向けた90分の上限は使えない。
上限を決めるのは実行環境と呼び出し方式の組み合わせ
発表文の条件を組み合わせごとに並べ直すと、次のようになる。従来の上限は15分で、90分はその6倍にあたる。
| 対象 | 条件 | タイムアウトの上限 |
|---|
| LMI 上の関数 | 非同期呼び出し | 90分 |
| LMI 上の関数 | ESM 経由の呼び出し | 90分 |
| LMI 上の関数 | 同期呼び出し | 15分(従来どおり) |
| LMI 以外の Lambda 関数 | 呼び出し方式を問わず | 今回の発表の対象に含まれていない |
| durable functions 内の呼び出し | LMI が前提かは明記なし | 延長後のタイムアウトを適用 |
| durable functions の多段の実行 | 非同期で起動した場合 | 最大1年 |
出典:AWS What’s New「AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances」(2026年9月9日)
見落としやすいのは3行目だ。LMI に載せていても、呼び出し元が結果を待つ同期呼び出しは 15分の上限から動かない。同期のまま90分まで引き延ばす方法は、この発表には含まれていない。
1つの関数を同期と非同期の両方から呼んでいる場合は、もう一段の注意が要る。タイムアウトは関数に設定する値だが、上限は呼び出し方式で分かれ、同期の側は15分のままだ。90分を設定した関数が同期で呼ばれたときに具体的にどう扱われるかまでは、発表文は踏み込んでいない。呼び出し経路が混在している関数は、その挙動が分かるまで90分への変更を急がないほうがよい。
90分を使う前提は LMI 上で動いていること
AWS が長い連続実行の例に挙げるのは、データ処理、メディアのトランスコード、モンテカルロシミュレーションのような金融計算、AI 推論、バッチ処理だ。これらは15分の上限のためにアーキテクチャ上の回避策を必要としてきたが、今後はアプリケーションを作り直さずに Lambda で走らせられる、と発表は説明している。
条件と照らし合わせると、この説明が素直に当てはまるのは、関数がすでに LMI 上にあり、非同期か ESM で呼ばれている場合だ。LMI 以外で動かしている関数なら、少なくともこの発表の範囲では、90分を使うために実行環境を LMI へ移すことが前提になる。移し替えの手順や、そのとき料金がどう変わるかは発表文に書かれていない。
発表文は LMI の特徴として、1つのインスタンスで複数のリクエストを同時に処理できること、用途に特化した計算構成を使えること、EC2 の料金面の利点でコスト効率を上げられること、インフラを管理せずに済むことを挙げている。
durable functions では90分と1年を別の数字として読む
延長後のタイムアウトは、Lambda durable functions の中の呼び出しにも適用される。durable functions は、長く続く呼び出しのためにステップをチェックポイントしてリプレイできる仕組みだ。非同期で起動した場合、多段の durable execution は最大1年続けられる。
90分と1年では、測っているものが違う。90分は1回の呼び出しが途切れずに走れる長さで、1年は複数のステップからなる実行全体の長さだ。連続で90分を超える計算は、1回の呼び出しには収まらない。ステップに区切れる処理なら、durable functions の多段の実行として組み、非同期で起動すれば最大1年まで続けられる。
はっきりしない点も残る。発表文はこの適用を LMI の説明の流れの中で書いているが、durable functions で延長後のタイムアウトを使うのに LMI 上で動かすことが条件になるのかは明記していない。1年という上限が今回の変更で決まったものか、以前からの durable functions の仕様なのかも、文面からは区別できない。
引き上げの前に確かめる条件と設定の経路
90分への引き上げを検討するなら、まず手元の関数が次の条件に当てはまるかを見る。
- 関数が Lambda Managed Instances 上で動いているか
- 長く走らせたい処理が、非同期呼び出しか ESM 経由で呼ばれているか
- 使っているリージョンで LMI が提供されているか
リージョンについては、LMI が使えるすべての AWS リージョンでこの機能が使えると発表は書いている。すべて当てはまれば、関数のタイムアウトを最大90分まで設定できる。
設定の経路として発表文が挙げるのは、AWS Lambda コンソール、AWS CLI、Lambda API、Infrastructure as Code のツール、Agent Toolkit for AWS だ。どの経路でも、変えるのは関数のタイムアウト値である。
発表は最大90分を設定できるようになったと書いており、既存の関数の設定が自動で変わるとは書いていない。条件に当てはまらない関数や、処理が15分に収まっている関数には、今日やることはない。