TITLE

AWS Lambdaのタイムアウト上限が90分に拡張、伸びるのは「LMI上の非同期・ESM呼び出し」だけ

投稿日:2026.09.16

CATEGORY

  • Web開発
AWS Lambdaのタイムアウト上限が90分に拡張、伸びるのは「LMI上の非同期・ESM呼び出し」だけ

AWSは2026年9月9日、AWS Compute Blogで、Lambda Managed Instances (LMI) 上で実行される関数の非同期呼び出し(Asynchronous invocation)とイベントソースマッピング(ESM。SQS・Kinesis・DynamoDB Streams・MSKなど)経由の呼び出しについて、関数タイムアウトの上限を15分(900秒)から90分(5,400秒)に拡張したと発表しました。6倍の拡張です。ただし対象は限定的で、同期呼び出し(Synchronous invocation)の上限は従来どおり15分のまま変わりません。

対象は「LMI上の非同期・ESM呼び出し」限定、同期は15分のまま

今回拡張されたのは、Lambda関数全般のタイムアウトではありません。条件は2つ重なっています。1つは実行環境がLambda Managed Instances (LMI) であること、もう1つは呼び出し方式が非同期呼び出しかESM経由であることです。AWSの定義によれば、LMIは複数の並行リクエストを処理でき、専用のコンピュート設定にアクセスでき、インフラを管理せずにEC2の価格面のメリットを活かせるサーバーレスコンピュートの形態です。

この2条件をどちらも満たさない呼び出し、つまり同期呼び出し(API GatewayやALBの背後で即座にレスポンスを返す使い方など)は、LMI上であっても15分の上限が維持されます。「Lambdaのタイムアウトが90分になった」という見出しだけを見ると全呼び出しが対象に見えますが、実態は非同期・ESMという2つの呼び出し方式に絞った拡張です。

同期呼び出しは900秒(15分)のまま、非同期・ESM呼び出しは5,400秒(90分)まで6倍に伸びたことを、同じ横幅の物差しで並べた棒グラフで示す図。非同期・ESMの対象はLMI上に限る旨を付記。

durable functionsと組み合わせるとワークフロー全体は最大1年まで動く

拡張された90分という数字は、1回の非同期呼び出し単位の上限です。AWSはこれをdurable functions(耐久関数)と組み合わせる使い方もあわせて説明しています。durable functionsはチェックポイント機能で処理の進捗を追跡し、失敗した場合は直前のチェックポイントから自動的に復旧します。この仕組みと組み合わせると、個々の非同期呼び出しは最大90分のまま、ワークフロー全体としては最大1年まで実行を続けられます。つまり90分は「1回の呼び出しの上限」であり、「一連の処理全体の上限」ではありません。

想定ユースケースと設定方法 — コード変更は不要

フィルムリールの映像が変換され、コンパクトな動画ファイルになる様子を描いたフラットイラスト。動画トランスコードのようなメディア処理ユースケースを表す。

AWSが挙げる想定ユースケースは、データ処理・ETLパイプライン、メディア処理(音声からテキストへの変換、動画のトランスコード)、金融計算(モンテカルロシミュレーション、ポートフォリオ分析)、AI推論、Webスクレイピングや大容量ファイル転送です。いずれも「1回の処理が15分を超えることがある」非同期系の処理です。

設定に必要な作業はコードの変更ではなく、タイムアウト値の変更だけです。AWS CLIであれば次のように指定します。

aws lambda update-function-configuration --function-name my-data-processor --timeout 5400

CloudFormationやSAMのテンプレートを使っている場合は、該当関数の定義に Timeout: 5400 を指定するだけで反映されます。

この分岐をLambda運用の判断軸にする

この発表がもたらす実務的な意味は、90分という数字そのものより、「同期か非同期・ESMか」という分岐が新たに設計判断の基準になった点にあります。これまでLambdaで長時間処理を組もうとすると、15分という上限のためにStep Functionsで複数のLambda呼び出しに分割するか、ECS/Fargateに処理を移すかという二択を早い段階で迫られていました。今回の変更後は、その処理が非同期呼び出しかESM経由で組めるなら、LMI上でLambdaのまま90分まで粘れる選択肢が増えたことになります。

一方で、API Gateway経由の同期呼び出しのように「呼び出し元が応答を待つ」構成のままでは、この拡張の恩恵を受けられません。長時間処理をLambdaに残すかどうかを検討する際は、まず自社の呼び出し方式が同期か非同期・ESM経由かを確認するところから始めるのが、今回の変更を正しく活かす順序です。

まとめ

次にLambdaの構成を見直す機会があれば、確認の順番は「呼び出し方式(同期か、非同期・ESMか)→実行環境(LMIかどうか)→必要な処理時間(15分に収まるか、90分が要るか)」の3ステップです。同期呼び出しのまま15分の壁にぶつかっている処理は、今回の変更では救われません。非同期・ESM経由に組み替えられる処理であれば、LMI上でLambdaのまま処理時間を確保する選択肢が増え、durable functionsと組み合わせればワークフロー全体を最大1年まで延ばすこともできます。同期は15分のまま、非同期・ESMだけ90分。この条件を先に見極めることが、Step FunctionsやECSへ処理を逃がすかどうかを決める最初の分岐点になります。

関連

AI エージェントを業務で回すときの設計と運用については、CTO の note に書いています。

出典

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)

AI

AI導入やシステム開発の ご相談を承っています。

お気軽にお問い合わせください

無料相談する

お問い合わせには1営業日以内にご返信します