blog.tetutetu214.com

GRAPH

ノードをドラッグ · ホイールでズーム · 背景をドラッグして移動

グラフを読み込んでいます

← 記事一覧へ

Lambda マネージドインスタンス(LMI)の 90 分タイムアウトについての調査

90 分にできるのはどの呼び出し方か、長く動かすと何の前提が変わるのかを整理し、Lambda の中で長時間処理をどこに置くかを判断できるようにする。

公開日

はじめに

2026 年 9 月、AWS Lambda（以下、Lambda）の関数タイムアウトの上限が、従来の 15 分から 最長 90 分（6 倍）へと大幅に引き上げられました。

ただし、対象は Lambda マネージドインスタンス（以下、LMI）上で動かすこと に加え、呼び出し方式にも条件があります。 （出典: AWS What’s New、2026-09-19 確認）

LMI の基本構造については前回の記事で整理しました。

本記事では、「どの呼び出し方なら 90 分化できるのか」という条件整理と、実行時間を延ばす際に何に気をつける必要があるのかを整理していきます。

構成図

どの呼び出し方の場合 LMI を 90 分にできるのかを以下の図にまとめました。

結論として、以下 2 つ 「非同期呼び出し」 および 「ESM（Event Source Mapping）」 において、LMI での 90 分の設定が可能となります。※Amazon MQ・Amazon DocumentDB を除く

Lambda の呼び出し経路と LMI でのタイムアウト上限の構成図。同期は 15 分のままで、Amazon API Gateway が LMI 上の Lambda 関数を呼んで応答を待つ。非同期は 15 分から 90 分になり、Amazon S3 が Lambda 管理の非同期呼び出しキューへ渡してすぐ戻る。ESM も（Amazon MQ・DocumentDB を除き）15 分から 90 分になり、イベントポーラーが Amazon SQS を取りに行き、関数を呼んで完了を待つ。
図を押すと別タブが開きます。

呼び出し方式ごとのタイムアウト上限

LMI にて 90 分タイムアウトが適用されるかどうかは、原則として「同期・非同期・ESM」の分類によって決まります。

分類 代表的なサービス タイムアウト上限 誰が応答を待つか
同期 API Gateway、Invoke（RequestResponse） 15 分（従来通り） 外部のクライアント
非同期 S3 イベント、EventBridge、Invoke（Event） 最大 90 分 なし（キューに入れた時点で戻る）
ESM SQS, Kinesis, DynamoDB Streams 最大 90 分（Amazon MQ・DocumentDB は 15 分） Lambda 内部のイベントポーラー

1. 同期呼び出し（RequestResponse）

API Gateway、あるいは SDK 等から直接 RequestResponse モードで呼び出す形式です。

外部のクライアント（ブラウザや他システム）がレスポンスを待つ構造で、タイムアウトの上限は 15 分のままです。

2. 非同期呼び出し（Event）

S3 や EventBridge などのトリガー、または SDK から Event モードで呼び出す形式です。 S3 や EventBridge は「トリガー（プッシュ型）」と呼ばれ、イベントを発行する側のサービスが主体となって Lambda を呼び出します。

呼出された Lambda では、内部キューにイベントを投入した時点で呼び出し元へレスポンスを返します。そのため、呼び出し元は Lambda の処理完了を待ちません。LMI では、この非同期呼び出しにおける関数のタイムアウト上限を最大 90 分としています。

3. ESM（Event Source Mapping）

ESM は API モードではなく、Lambda 側のリソースです。 Lambda 内のポーラーが SQS や Kinesis 等を監視して、データを都度参照し取得(ポーリング処理)、取得したバッチで Lambda 関数を同期的に呼び出します。

ESM も裏側の動作としては同期呼び出しを行っていますが、応答を待つのは外部のクライアントではなく Lambda のイベントポーラーで、上限は 90 分です（Amazon MQ・DocumentDB を除く）。

（出典: Lambda invoke modes、How Lambda processes records from stream and queue-based event sources、Event source mappings with durable functions、2026-09-19 確認）

ESM(Event Source Mapping) 対象リソース一覧

ESM（Event Source Mapping）の対象となる 7 つのサービスのうち、Amazon MQ と Amazon DocumentDB の 2 つは LMI 上であっても 15 分制限のまま 据え置かれています。

サービスごとの対応状況を以下にまとめました。

# サービス LMI での上限
1 Amazon SQS 最大 90 分
2 Amazon Kinesis Data Streams 最大 90 分
3 Amazon DynamoDB Streams 最大 90 分
4 Amazon MSK 最大 90 分
5 セルフマネージド Apache Kafka 最大 90 分
6 Amazon MQ 最大 15 分（90 分にできない）
7 Amazon DocumentDB 最大 15 分（90 分にできない）

（出典: How Lambda processes records from stream and queue-based event sources（2026-09-19 確認）、Configure Lambda function timeout、Lambda Managed Instances quotas（2026-09-24 確認））

実行時間を延ばすときの注意点

実行時間が 6 倍になると、前提が変わるものがあります。 主な注意点は 4 つです。

1. タイムアウト後も動き続けるコード（タイムアウト処理のハンドリング）

LMI では、設定したタイムアウト時間を過ぎると Lambda は「処理失敗（タイムアウト）」と判定しますが、実行中のプログラム（プロセス）自体を強制終了しません。

従来の Lambda はエラーの後に実行環境をリセットしますが、LMI は 1 つの実行環境（コンテナ）で複数の呼び出しを同時に処理しているため、タイムアウトした呼び出しがあっても実行環境を止めず、ほかの呼び出しもそのまま動かし続けるためです。

この挙動により、以下の問題が発生します。

  • Lambda 側の判定: タイムアウトに達したため「失敗」と扱われ、非同期呼び出しでは Lambda が、ESM ではイベントソースの設定に従って再試行（リトライ）する。
  • 実際のプログラム: タイムアウト後もコンテナ内でコードが動き続け、遅れて処理（DB 書き込みや通知）を最後まで完了させてしまう。

その結果、 「裏で動き続けていた 1 回目の処理」 と 「再試行された 2 回目の処理」 が重なり、データの二重書き込みや重複通知が発生してしまいます。 タイムアウトを検知してプログラム側で安全に処理を中断・終了させるのは開発者側の責任となります（残り時間は context.get_remaining_time_in_millis() 等で取得可能です）。

（出典: Understanding the Lambda Managed Instances execution environment、2026-09-25 確認）

2. 同期呼び出し時の 15 分上限（ガードレール）

LMI でタイムアウトを 90 分に設定している関数であっても、SDK や API Gateway 等から同期（RequestResponse）で呼び出した場合は、Lambda によって 15 分のタイムアウト制限が強制適用 されます。

そのため、1 つの関数に対して「普段は非同期や ESM で 90 分バッチとして動かしつつ、管理用や例外時に同期呼び出しでも使えるようにしておく」といった共通化設計を行う場合は注意が必要です。 同期呼び出し経路を経由すると 15 分を超えた時点でエラーとなるため、長時間処理を行う関数は呼び出し方式を限定（または切り分け）して設計する必要があります。

（出典: AWS Compute Blog、2026-09-19 確認）

3. 非同期呼び出しの再試行（リトライ）と冪等性

非同期呼び出しでは、関数がエラーを返すと デフォルトで 2 回の再試行（初回と合わせて最大 3 回実行） が行われます。

仮に 90 分近く動いた末に失敗する処理が 2 回再試行された場合、最大で約 4 時間半（270 分） にわたり実行環境のスロットを占有し続けることになります。これにより、LMI のリソース圧迫や予期せぬコスト増加、後続処理の遅延といった大きな影響が発生します。

そのため、長時間実行する関数では以下の設計・設定をあらかじめ定めておくことが不可欠です。

  • 再試行回数の見直し: 必要に応じて設定を「0 回」や「1 回」に削減する、または DLQ（デッドレターキュー）/ Destination へ逃がす
  • 冪等性（Idempotency）の担保: 途中まで処理が進んだ状態で再試行されても、データが二重処理・破壊されない設計にする

AWS 公式ドキュメントでも「Lambda は exactly-once（正確に 1 回）を保証しない。関数が長く動くほど、再試行やメッセージ重複配信のウィンドウ（発生リスクの窓）が広がる」と注意喚起されています。

（出典: How Lambda handles errors and retries with asynchronous invocation（2026-09-10 確認）、Best practices for Lambda Managed Instances（2026-09-19 確認））

4. 接続とキューの設定（SQS・NAT ゲートウェイ・データベース）

実行時間を最長 90 分へ延ばす場合、Lambda 関数本体だけでなく、連携する周辺インフラやミドルウェア側の設定値も合わせて見直す必要があります。

  • SQS の可視性タイムアウト（Visibility Timeout）: ESM で SQS を利用する場合、キューの可視性タイムアウトは 関数タイムアウトの 6 倍以上（90 分設定なら 9 時間以上）に設定することが推奨されます。ESM 作成時には Lambda 側でチェックが入りますが、作成後にキューや関数のタイムアウト設定を個別に変更した際の不整合までは自動で防止されないため、運用時の変更に注意が必要です。

  • NAT ゲートウェイのアイドルタイムアウト: VPC 内から NAT ゲートウェイ経由で外部通信を行う場合、 350 秒（約 6 分）無通信が続くと TCP 接続が自動切断 されます。長時間処理の途中で通信が切れないよう、アプリケーション側で TCP Keep-alive 等を有効化する対策が必要です。

  • データベース接続・一時認証情報の有効期限: RDS や ElastiCache 等のミドルウェアにおける「アイドル接続タイムアウト」や、IAM ロール・STS から取得する「一時クレデンシャル（AssumeRole で取得した場合、既定の有効期限は 1 時間）」の失効にも配慮が必要です。90 分の処理途中で認証切れが発生しないよう、セッションの有効期間や自動再取得の実装を見直す必要があります。

（出典: Best practices for Lambda Managed Instances（2026-09-19 確認）、AssumeRole（AWS STS API リファレンス）（2026-09-25 確認））

Lambda での選択肢を比較

2025 年末以降、Lambda には実行時間の上限が異なる新しい選択肢が追加されています。 実行できる時間の長さで整理すると、以下のようになります。

選択肢 実行時間の上限 実行モデル 主な用途・使い分け
従来の Lambda 15 分 イベント駆動（単一ハンドラ） 短時間の軽量処理・Web API
LMI 90 分（非同期・ESM）※1 / 15 分（同期） イベント駆動（常時稼働環境で並行処理） 途中で止められない 15〜90 分の一括処理
Lambda MicroVMs 8 時間（RUNNING と SUSPENDED の合計） 常駐アプリへ HTTPS 接続 利用者・AI 等と対話的に状態を保持する sandbox
Lambda Durable Functions 実行全体で最長 1 年（非同期呼び出し）※2 チェックポイントとリプレイで多段実行 待機や承認を挟む長期間の多段ワークフロー

※1 Amazon MQ・Amazon DocumentDB の ESM は、LMI 上でも 15 分です。

※2 Durable Functions の補足: 「1 年」はワークフロー全体の上限であり、1 ステップが連続実行できる時間は関数自体のタイムアウト（LMI なら 90 分、従来なら 15 分）に従います。なお、ESM から呼び出す場合は全体上限も関数タイムアウトと同じになります。

（出典: Lambda MicroVMs デベロッパーガイド（2026-09-04 確認）、Configure Lambda durable functions、Event source mappings with durable functions、AWS What’s New（2026-09-19 確認））

まとめ

今回は、AWS Lambda（LMI）で関数タイムアウトが 90 分へと緩和された仕様とその条件について整理しました。

  • 90 分化の対象: LMI 上で動作する「非同期呼び出し」および「ESM（Event Source Mapping）」のみ ※Amazon MQ・Amazon DocumentDB を除く
  • 据え置き（15 分制限）: 同期呼び出し（RequestResponse）および従来の Lambda

タイムアウトの上限が伸びたからといって、単に設定の数字を変更するだけで完結するわけではありません。

  • タイムアウト後もコード自体はプロセス内で動き続けるリスク
  • リトライ（再試行）の発生によって実行時間が累積・膨張する点
  • SQS（可視性タイムアウト）や NAT ゲートウェイ、各種データベース接続設定の見直し

上記のような、長時間実行特有の設計・運用上の考慮がより強く求められるようになることも学びになりました。

個人的に最も興味深かったのは、「15 分の壁」を突破したのが従来の Lambda ではなく、EC2 インフラを土台とした LMI 側だったところです。

従来の Lambda は 15 分の上限制限が維持されたまま、LMI 側だけが 90 分へと拡張されました。単に設定上限が伸びたというより、「Lambda の裏側で動いているインフラ構造の違い」がそのまま実行時間の上限に表れたものだったと学びました。

← 記事一覧へ