AWSは2026年9月9日、AWS Lambda Managed Instances（LMI）で、非同期呼び出しとイベントソースマッピングの最大実行時間を15分から90分へ拡大しました。

上限は5,400秒で従来の6倍です。ETL、動画変換、金融計算、AI推論など、15分制限のためコンテナやワークフローへ分割していた処理を、Lambdaのハンドラー形式のまま実行できる可能性があります。

ただし、通常のオンデマンドLambdaや同期呼び出しは15分のままです。LMIはEC2ベースの専用キャパシティであり、従来Lambdaの「呼び出した時間だけ課金」とも異なります。

Lambda Managed Instancesとは

LMIはLambda関数を、ユーザーのVPC内にあるAWS管理のEC2インスタンス上で実行する方式です。Lambdaがインスタンスのプロビジョニング、OS更新、ルーティング、負荷分散、スケール、ライフサイクルを管理します。

1台のインスタンスで複数要求を同時処理でき、EC2のインスタンスタイプ、Savings Plans、Reserved Instancesを利用できます。突発的で短い処理より、定常的で高負荷な処理に向く位置付けです。

何が新しいのか

LMI上の関数は、非同期および多くのイベントソースマッピング（ESM）でTimeout: 5400を指定できます。ランタイム、ハンドラー、IAM実行ロール、VPC設定は従来と同じです。

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Runtime: python3.12
    Handler: app.handler
    Timeout: 5400
    MemorySize: 10240

CLIなら次の設定です。

aws lambda update-function-configuration \
  --function-name my-data-processor \
  --timeout 5400 \
  --region ap-northeast-1

変更後の呼び出しから適用されます。ESMへの伝播には数分かかる場合があります。CloudWatch、CloudTrail、X-Rayは既存構成のまま呼び出し全体を記録します。

対応範囲を間違えない

• 非同期呼び出し：最大90分。
• SQS、Kinesis、DynamoDB Streams、Kafka系ESM：最大90分。
• 同期呼び出し：最大15分のまま。
• 初期化フェーズ：最大15分のまま。
• Amazon MQとAmazon DocumentDBのESM：最大15分のまま。
• 通常のオンデマンドLambda：最大15分のまま。

関数設定が90分でも同期実行では15分で打ち切られます。API Gatewayのような同期経路を90分処理へ流用する機能ではありません。

Durable Functionsとの違い

90分タイムアウトは、1回の関数呼び出しが連続して動ける時間です。Durable FunctionsのExecutionTimeoutは、待機や複数ステップを含む処理全体の経過時間を管理します。

Durable Functionsはstep()やwait()でチェックポイントを保存し、障害後に完了済みステップを飛ばして再生します。非同期のDurable実行全体は最長1年、各LMI呼び出しは最大90分です。

SQSでは可視性タイムアウトを見直す

AWSはSQSのVisibility Timeoutを関数タイムアウトの最低6倍にするよう案内しています。90分関数なら計算上は540分、つまり9時間です。

これは、前のバッチ処理中にスロットルされた場合の再試行時間を確保するためです。ESM作成時は検証されますが、その後に関数やキュー設定だけを変更すると不整合を作れるため、Infrastructure as Codeで同時管理します。

複数レコードのうち1件だけ失敗したとき、全バッチを再処理しないようPartial Batch Failure Reportingも有効にします。SQS、Kinesis、DynamoDB Streams、Amazon MSK、自己管理Kafkaで利用できます。

料金は従来Lambdaと別物

90分化そのものの追加料金はありませんが、LMI料金は次の3要素です。

1. 100万要求当たり0.20ドル。
2. 使用するEC2インスタンス料金。
3. EC2オンデマンド価格の15%に相当する管理料金。

関数ごとの実行時間に対するGB秒課金はありません。AWS公式の例では、m7g.xlargeを約2,000時間、3年Compute Savings Planで使用し、1億要求を処理する月額を160.36ドルと試算しています。これは仮定に基づく例で、為替、リージョン、稼働率、インスタンスタイプで変わります。

編集上の推論として、90分処理を少数回だけ実行する場合、常時キャパシティを持つLMIよりAWS BatchやFargateの方が安い可能性があります。実行時間だけでなく月間稼働率を比較してください。

向く用途

• 数GB単位のETLと外部データ取り込み。
• 動画・音声の変換、字幕生成、品質チェック。
• モンテカルロ法、債券価格、ポートフォリオリスク計算。
• 長い推論時間を要するAIモデル評価。
• 低速な外部サービスからのファイル転送。
• 15分を少し超える既存Lambdaの移行回避。

一方、常駐サービス、対話型同期API、90分を超える単一処理、GPU必須ジョブではECS/Fargate、AWS Batch、SageMakerなども比較します。

長時間化で増える運用リスク

1. 失敗コスト：85分で失敗すると再実行が高価。チェックポイントと冪等性を設計する。
2. 資格情報の期限：一時認証情報や署名済みURLが処理中に失効しないか確認する。
3. 接続切断：DB、HTTP、ストリーム接続を長時間保持せず、再接続可能にする。
4. スロット占有：長時間処理が実行ワーカースロットを占有し、他要求を遅らせる。
5. タイムアウト後の副作用：LMIではタイムアウト応答後もコードが進み、通知などを実行する例をAWSが説明している。残り時間を確認して早めに停止する。
6. ログ量：90分の詳細ログでCloudWatch費用と調査量が増える。

導入チェックリスト

• P50/P95実行時間が15〜90分に収まるか。
• 非同期または対応ESMで呼び出しているか。
• 再実行しても二重更新にならないか。
• SQS可視性タイムアウトを6倍以上にしたか。
• 部分バッチ失敗を有効にしたか。
• 30〜60分間隔より細かいチェックポイントが必要か。
• EC2＋15%管理料と代替サービスを比較したか。
• 80〜85分でアラートを出し、安全終了できるか。

今後注目すべき点

現在15分のまま残る同期呼び出し、Amazon MQ、DocumentDB ESM、通常Lambdaへ90分枠が広がるかが焦点です。また、LMIの対応リージョン・インスタンスタイプと、Durable Functionsのチェックポイント費用・復旧時間も実測が必要です。

「Lambdaだから短時間」という前提は変わりましたが、「長く動かせるから1関数へ全部入れる」のは危険です。障害境界、再試行単位、費用単位を分ける原則は残ります。

参照元

• AWS Compute Blog：Announcing 90-minute function timeout on AWS Lambda Managed Instances
• AWS What's New：AWS Lambda now supports 90-minute function timeout
• AWS Lambda Docs：Configure Lambda function timeout
• AWS Lambda Docs：Best practices for Lambda Managed Instances
• AWS Lambda Pricing

最終確認日：2026年9月14日