Lambdaのタイムアウト、15分から90分になったらしい!これで重いバッチも全部Lambdaでいけるな
半分だけ正解Lambda の実行時間の上限が15分から90分になった半分正解
普通の Lambda()の上限は2018年から変わらず15分(900秒)のまま。AWS 自身も、同期呼び出しやオンデマンドで長いタイムアウトが欲しい人は要望を寄せてほしい、という書き方をしています。つまり「まだそこまでは対応していない」ということです。
Lambdaのタイムアウト、15分から90分になったらしい!これで重いバッチも全部Lambdaでいけるな
半分だけ正解2026年9月、AWS Lambda のが最大90分に延びたというニュースが流れました。ただし対象は (LMI)という特定の実行形態だけ。多くの人が普段使っている Lambda は、今も15分が上限です。
この記事では、ありがちな勘違いをひとつずつ確かめながら、何が変わって何が変わっていないのかを整理します。
下線と「?」がついた用語は、タップすると解説が出ます。
同じ「Lambda」でも、どこで動かしてどう呼び出すかで上限が変わります。90分になるのは一番下の組み合わせだけです。
90分まで設定できるのは、次の条件がすべてそろったとき
Lambda の実行時間の上限が15分から90分になった半分正解
普通の Lambda()の上限は2018年から変わらず15分(900秒)のまま。AWS 自身も、同期呼び出しやオンデマンドで長いタイムアウトが欲しい人は要望を寄せてほしい、という書き方をしています。つまり「まだそこまでは対応していない」ということです。
今ある関数も、タイムアウトを5400秒にすれば90分動く誤解
いつもの Lambda では、タイムアウトに設定できるのは900秒までです。90分を使いたければ、まず関数を LMI で動かす構成に変える必要があります。
LMI は「設定項目がひとつ増えた」のではなく、関数をインスタンス上で動かす別の実行形態です。その違いは4つ目の勘違いで詳しく見ます。
LMI にすれば、API Gateway の裏で長い処理を動かせる誤解
API Gateway、ALB、関数URL からの呼び出しはです。同期呼び出しは LMI でも15分のまま。タイムアウトを5400秒に設定していても、同期で呼ばれると15分で打ち切られます。
さらに API Gateway には、それより前に切れるがあります。REST API はデフォルトで29秒です。「画面からボタンを押して90分の処理を待つ」ような作りは、今回の変更では実現できません。長い処理は非同期に切り出し、結果はあとから受け取る形にするのが基本です。
LMI って、設定をひとつ切り替えるだけでしょ?誤解
LMI は「Lambda の使い勝手のまま、実体は自分のアカウントの EC2 で動かす」形態です。コードはほぼ同じでも、動き方と料金は別物と考えたほうが安全です。
使われていなくてもません(コールドスタートがない代わりに、インスタンス代がかかり続けます)。料金はリクエスト課金ではなく EC2 ベース。さらに1つの環境で複数件を同時にさばくで動くため、グローバル変数に処理中データを置くような書き方は見直しが要ります。
向いているのは「量が多く、流量が読みやすい定常的な処理」。たまにしか動かない長時間バッチのためだけに移すと、待機中のインスタンス代が割に合わないこともあります。
SQS などの ESM 経由なら、どれでも90分いける条件つき
LMI が前提なのは同じです。そのうえで、SQS・Kinesis・DynamoDB Streams・Amazon MSK・セルフマネージドの Kafka は90分まで伸びますが、Amazon MQ と Amazon DocumentDB の ESM は15分のままです。
SQS を使う場合は、キューのを関数タイムアウトの6倍以上にするよう求められています。5400秒なら32400秒、つまり9時間です。長く動かすほど再試行や重複配信の影響も大きくなるので、処理をにしておくことも大切になります。
構成を選ぶと、関数タイムアウトの上限が表示されます。
どこで動かしている?
どう呼び出している?
ESM のイベントソースは?
15分まで
いつもの Lambda で15分に収まらない処理は、これまでどおり次のような方法で対応します。LMI への移行は、その選択肢がひとつ増えたと考えるのが実態に近いです。
コードをほぼそのままに、非同期・ESM なら90分まで伸ばせる。
常にインスタンスが動く料金体系。定常的な処理量がないと割高になりやすい。
いつもの Lambda でも使える。処理をステップに分け、全体では最大1年まで動かせる。
1回の呼び出しは15分以内(LMI なら90分)。ステップに分けられる処理であることが前提。
15分以内の関数を順番・分岐・並列で組み合わせ、長いワークフローにできる。
1つの処理を分割できないと使えない。ワークフローの設計が必要。
コンテナで動かすので Lambda のような15分の制限がない。分割しにくい長時間処理向き。
コンテナイメージの用意など、Lambda より準備することが増える。
いつもの Lambda は、今も15分。90分は 上で、非同期か ESM で呼んだときだけ。