「この処理、Lambdaだと15分で落ちるので無理です」。先輩がそう言って、夜間バッチ用のサーバーを別に立てるのを横で見ていた経験はないでしょうか。ログの変換や月次の集計は、15分で終わらないことのほうが多いからです。
この記事では、2026年9月にAWSが発表したLambdaの90分タイムアウトを整理します。何がどこまで変わったのか、自分の現場のバッチを載せ替えられるのかが分かります。
結論から言うと、上限は15分から90分へ6倍になりました。ただし条件が二つあります。Lambda Managed Instances(LMI)という新しい実行環境で動かすこと、そして呼び出し方が非同期であることです。画面から呼ぶような同期の処理は、これまでどおり15分で止まります。
Lambdaの15分の壁が90分になったとは?何がどこまで変わったのか
2026年9月9日、AWSはLambdaの関数タイムアウトを最大90分(5,400秒)まで設定できるようにしました。従来の上限である15分(900秒)の6倍です。
この数字が大きいのは、15分が長いあいだ設計の分かれ目だったからです。15分を超える処理は、Step Functionsで細かく分割するか、コンテナやサーバーに逃がすしかありませんでした。処理の中身ではなく、時間の都合だけで構成が決まっていたわけです。
AWSが想定する使い道として挙がっているのは、次のような処理です。
- 動画の変換や音声の文字起こしといったメディア処理
- 大量データの変換やETLパイプライン
- 金融の計算(モンテカルロ法によるシミュレーションなど)
- AIの推論やWebスクレイピング
どれも「1件あたりが重い」処理です。これまでは作り替えが必要だったものが、Lambdaの基本的な仕組みのまま動かせる可能性が出てきました。
設定の変え方も拍子抜けするほど単純で、タイムアウトの値を5,400にするだけです。AWSは公式ブログで「コードを変更する必要はない」と明記しています。CloudFormationやSAMならTimeout: 5400の1行で、テンプレート側から指定できます。
なぜLambdaで90分が可能になったのか｜LMIという新しい土台
90分が実現したのは、Lambda Managed Instances(LMI)という実行環境が土台にあるからです。ここが今回の話の中心です。
LMIは、1つのインスタンスで複数のリクエストをまとめて処理する実行モードです。AWSの公式ドキュメントは、LMIの関数が「自分のアカウント内のEC2マネージドインスタンス上で動く」と説明しています。サーバーレスの手軽さを保ちつつ、EC2の価格体系とハードウェアの選択肢を使えるようにしたもの、という位置づけです。
たとえるなら、従来のLambdaは注文が入るたびに屋台を出して、終わったら畳む方式でした。LMIは店舗を借りて営業時間のあいだ開けておく方式です。開けっぱなしだからこそ、90分かかる仕込みも途中で追い出されません。
開けっぱなしの代金は誰が払うのか
この違いは料金に直結します。90分タイムアウト自体に追加料金はありませんが、土台であるLMIの課金の形が標準のLambdaとは別物だからです。
公式ドキュメントは、LMIの料金をEC2インスタンスの料金に管理費15%を上乗せしたものと定めています。実行時間(GB-秒)ではなく、インスタンスに対する課金です。
そして効いてくるのがスケーリングの既定値です。公式のスケーリング解説によれば、キャパシティプロバイダーを指定して関数バージョンを発行すると、Lambdaはアベイラビリティゾーンの冗長性のためにインスタンスを既定で3つ起動し、実行環境を3つ立ち上げてから、そのバージョンをACTIVEにします。実行環境の最小数は既定で3、最大値に既定はありません。
つまり、誰も呼んでいない時間もこの3つは動き続けます。「呼ばれなければ0円」という標準のLambdaの感覚のままでは合いません。止める手段はあり、最小と最大をどちらも0にすれば関数バージョンを削除せずに停止できます。ただし公式は、停止した関数はトラフィックが来ても自動では戻らず、明示的に設定し直すまで動かないと明記しています。月に数回の棚卸しバッチのために、この切り替えを毎回人手で回す価値があるかどうかは、また別の判断です。
課金の形が変わったことは、ログにも表れます。AWS Japanの有志によるZennの検証記事では、20分走らせた関数のログに、標準のLambdaなら必ず出るはずの請求対象時間(billedDuration)の行が無かったことが報告されています。時間で買う仕組みではなくなった、ということです。
導入の手間も見積もりに入れてください。LMIにはキャパシティプロバイダーの作成とVPCの指定が要り、関数はバージョンを発行して修飾ARNで呼ぶ形になります。インスタンスは自分のアカウントにありながら、Fargateと同じで中に入って操作することはできません。
Lambdaの90分タイムアウトが効かない場面｜同期呼び出しは15分のまま
ここが一番の注意点です。90分になるのは非同期呼び出しと、イベントソースマッピング(ESM)経由の呼び出しに限られます。
理由は、同期呼び出しでは呼んだ側が結果を待ち続ける必要があるからです。90分も接続を維持する前提は、現実的ではありません。
具体的には、次の3つが従来どおり15分のままです。
- Amazon MQ と DocumentDB のイベントソースマッピング
- 関数の初期化フェーズ(コードの読み込みなど起動時の処理)
とくに同期の挙動は、設定画面を見ても気づけません。公式ブログは「タイムアウトを15分より大きく設定して同期で呼び出した場合、Lambdaは15分のタイムアウトを適用し続ける」「GetFunctionConfiguration APIは設定された値のほうを返す」と書いています。設定値には5,400と表示されているのに、実際には15分で打ち切られるということです。数字だけを見て「もう大丈夫」と判断しないでください。
Lambdaを90分で回す前に確認したい3点｜SQS・NAT・リトライ
実行時間が延びると、これまで表に出てこなかった時間の制限が顔を出します。移行前に確認したいのは次の3点です。
1つ目は、キューの設定です。SQSをイベント源にする場合、可視性タイムアウト(処理中のメッセージを他から見えなくする時間)が短いと、まだ動いている最中に同じメッセージが再配信されます。AWSは関数タイムアウトの6倍以上を案内しています。作成時には検証されますが、あとからキューや関数の設定を変えて食い違いが生まれるのは防いでくれないと公式が明記しているので、変更のたびに自分で確かめる必要があります。
2つ目は、通信経路のアイドル時間です。NAT Gatewayは350秒(約6分)で無通信の接続を切ります。90分の処理の中に、外部への接続を張ったまま何も流さない時間があると、そこで途切れます。RDSやElastiCache、外部APIのアイドルタイムアウトも同じ目で見ておきましょう。
3つ目は、リトライの掛け算です。非同期呼び出しは既定で最大2回やり直します。90分の処理が失敗し続けると、合計で4時間半ぶん動く計算になります。公式も「Lambdaは1回だけの実行を保証しない。実行時間が延びるほど、リトライと重複配信の窓は広がる」と注意しています。同じ処理を2回流しても壊れない作り(べき等性)と、認証トークンの有効期限は、必ず先に確認しておきましょう。
運用1〜3年目がLambdaの90分化から学ぶべきこと
ここからは筆者の考えです。今回の変更で本当に動いたのは、上限の数字ではなく「選び方の基準」だと見ています。
これまでの判断はとても単純でした。15分を超えるならLambdaは外す。時間という一本の線で、サーバーレスかコンテナかが決まっていたわけです。新人が先輩から最初に教わるのも、たいていこの線でした。
その線が消えると、残る判断材料は頻度とコストになります。定常的に長いジョブが走る現場ならLMIは噛み合いますが、月に数回の棚卸しバッチなら、常時確保される3つの実行環境の料金が重くのしかかります。散発的な処理はStep Functionsでの分割やECSのほうが素直です。
つまり、これから問われるのは「何分かかるか」ではなく「どれくらいの頻度で、いくらかけて回すか」です。時間で切る癖のままだと、選択肢を1つ取り違えます。
まとめ｜Lambdaの90分タイムアウトで押さえる3点
- 上限は15分から90分へ。ただしLMI上で、非同期またはESM経由の呼び出しに限られる
- 同期呼び出し、Amazon MQとDocumentDBのESM、初期化フェーズは15分のまま。設定値が5,400でも同期なら15分で切れる
- LMIはEC2料金＋管理費15%で、既定では実行環境を3つ保ち続ける。散発的なジョブではコストが見合わないことがある
まずは自分の現場の夜間バッチを一覧にして、所要時間と実行頻度を並べて書き出してみてください。90分に載せる価値があるかどうかは、その2列を見れば判断できます。
参考リンク
- Announcing 90-minute function timeout on AWS Lambda Managed Instances | AWS Compute Blog（発表の一次情報。2026年9月9日）
- Lambda Managed Instances – AWS Lambda Developer Guide（EC2マネージドインスタンス上で動くこと・管理費15%の出典）
- Scaling Lambda Managed Instances – AWS Lambda Developer Guide（既定で3つ起動すること・最小0での停止と再有効化の出典）
- AWS Lambda の90分タイムアウト検証 – Zenn（AWS Japanの有志publicationに掲載された個人の検証記事。20分実行のログに請求対象時間が出ない点を参照した）
コメント