Lambda マネージドインスタンス(LMI)についての調査

はじめに

2025 年 11 月、AWS から「Lambda マネージドインスタンス（以下、LMI）」が発表されました。これは、Lambda 関数の開発・実行体験を保ちつつ、裏側の基盤として EC2 インスタンスを利用できる新しい仕組みです。（出典: AWS What’s New、2026-09-19 確認）。

一見すると「単なる Lambda のオプション拡張」に見えますが、実行基盤・セキュリティの隔離方法・課金モデルまで、従来の Lambda とは異なっています。

本記事では、LMI の基本的な特徴を踏まえつつ、従来の Lambda と何が違うのか、その全体像を整理していきます。

従来の Lambda と LMI の比較

従来の Lambda と LMI は、どちらも「Lambda 関数を実行する」点では共通していますが、以下に主な違いをまとめてみました。

項目	従来の Lambda	LMI
実行基盤	AWS が管理する共有フリート	自分のアカウントの EC2 インスタンス（Lambda が管理）
隔離	Firecracker の MicroVM	EC2 Nitro 上のコンテナ
セキュリティ境界	MicroVM（AWS が自動で分離。利用者が設定する単位は無い）	キャパシティプロバイダー
タイムアウト制限	最長 15 分	最長 90 分（非同期・ESM）/ 15 分（同期）
1 実行環境あたりの同時処理	1 件	複数（既定は Lambda が決定、vCPU あたり 64 まで）
呼び出しの合間	凍結	常時稼働
スケーリング	コールドスタートあり、ゼロまで縮小	定常運用ではコールドスタートなし、最小実行環境数まで縮小
料金体系	GB 秒 + リクエスト数	EC2 料金 + 管理費 15% + リクエスト数

（出典: Lambda Managed Instances、Best practices for Lambda Managed Instances、Understanding Lambda function scaling、LMI の実行環境、AWS Lambda 料金、2026-09-19 確認）

実行時間（タイムアウト）の注意点

LMI では最大 90 分の実行が可能ですが、これは 非同期呼び出し および イベントソースマッピング（ESM） で呼び出した場合のみ適用されます。そのため、すべての処理が 90 分まで伸ばせるわけではないというところに注意が必要です。

同期呼び出し: 従来通り最大 15 分
関数の初期化フェーズ: 最大 15 分（正確には 130 秒と設定したタイムアウト値の大きい方で、上限が 900 秒）
ESM の対応イベントソース: SQS / DynamoDB Streams / Kinesis Data Streams / MSK / セルフマネージド Kafka

呼び出し方式ごとの条件と、実行時間を延ばすときの注意点はLambda マネージドインスタンス(LMI)の 90 分タイムアウトについての調査で整理しています。

（出典: Configure Lambda function timeout、Best practices for Lambda Managed Instances、AWS What’s New（90 分タイムアウト）、LMI の実行環境、Lambda Managed Instances quotas、2026-09-20 確認）

LMI 設計における 3 つの考慮点

表で全体的な違いを整理しましたが、実際に LMI を利用・設定するにあたっては、従来の Lambda とは異なる挙動や考慮点が存在します。ここでは特に重要な 3 点（同時処理の仕組み・キャパシティプロバイダー・料金の注意点）について補足します。

1. 同時処理(Concurrency)の仕組み

LMI では、1 つの実行環境内で複数のリクエストを同時に処理します。ここで重要になってくるのが、「どうやって同時処理を実現しているか」がランタイム（言語）ごとに異なるという点です。

なぜランタイム(言語)ごとに仕組みが違うのか？

従来の Lambda の仕組み

AWS 側で 1 つの実行環境に対して同時に 1 件のリクエストを処理するように制御してくれていました。開発者は AWS が用意した環境で処理を実行するため、言語ごとの並行処理の仕様差やスレッドの競合について、ほとんど意識する必要がありませんでした。

LMI の仕組み

LMI は、EC2 のリソースを効率よく使うため、1 つのコンテナ内で複数のリクエストを同時に処理する設計になっています。もちろん、コンテナによる実行環境どうしの隔離がなくなったわけではありません。ただし、同じ実行環境の中で同時に動くリクエスト同士をどう扱うか（メモリを共有するか分離するか）は、各言語ネイティブの並行処理の仕組みに委ねられることになりました。

例えば Java や Node.js は単一プロセス内のスレッド等で処理するためメモリ空間を共有しますが、Python はマルチプロセスで処理するためリクエストごとにメモリ空間が分離されます。

リクエストの処理図

以下の図は、1 つの実行環境の中でリクエストがどう処理されるかを示しています。LMI では既定で 3 つの実行環境が起動するため、実際にはこの図が 3 つ並びます。

アクセス 1 件

1 件

従来の Lambda

1 環境あたり 1 件

この図は 1 vCPU の実行環境を前提

実行環境 1

Req 1

リクエスト 1 件 / 実行環境 1 個

実装時に気をつけるべき注意点

この仕様変更に伴い、アプリケーションコード側での考慮事項が大きく変わります。

マルチスレッド／非同期（Java, Node.js, .NET, Rust）
- 1 つのプロセス内で複数のリクエストが動くため、グローバル変数やインメモリキャッシュなどの共有状態はスレッドセーフに実装する必要があります。スレッドセーフとは、複数のリクエストが同時に届いても、お互いのデータが混ざったり上書きされたりしない状態を指します。
マルチプロセス（Python）
- リクエストごとにプロセスが分かれるためメモリ上の競合は起きにくいですが、/tmp ディレクトリなどの共有ファイルシステムリソースへの同時アクセスには注意が必要です。

スペックと割り当て規則

同時処理数は Lambda が自動で既定値を決定しますが、CPU 使用率が低い関数であれば手動で調整が可能です。

同時処理数の上限: vCPU あたり最大 64 まで引き上げ可能
スペック範囲: 最小 2 GB / 1 vCPU 〜最大 32 GB / 16 vCPU
メモリと vCPU の比率: 2:1・4:1・8:1 から選択可能

（出典: Lambda Managed Instances runtimes、Best practices for Lambda Managed Instances、AWS What’s New、2026-09-19 確認）

2. キャパシティプロバイダーの制約

LMI では、VPC 構成、インスタンス要件、スケーリング設定などの実行基盤や EC2 グループをまとめて「キャパシティプロバイダー」という単位で定義します。イメージとしては「VPC 内にデプロイされる、AWS 管理の ECS / Auto Scaling」のような構成になります。

自身の AWS アカウント内に構築はされますが、従来の EC2 とは運用ルールが大きく異なっています。

1. EC2 における手動操作不可

インスタンスは自身の VPC 上で動作しますが、通常の EC2 としては操作できません。インスタンスのライフサイクル、OS とランタイムのパッチ適用、負荷分散、オートスケールはすべて AWS が裏で制御しているため、操作できる範囲が通常の EC2 より狭くなっています。

手動削除・SSH 不可
- EC2 コンソールでの手動終了はできず、削除したい場合は「キャパシティプロバイダー」ごと削除する必要があります。
コンソールではデフォルト非表示
- 通常の EC2 一覧には表示されません。DescribeInstances の Operator フィールドや専用タグ（aws:lambda:capacity-provider）で識別できます。

2. 初回起動の遅延とスケーリングにおける遅延

関数をキャパシティプロバイダーに紐づけてバージョンを発行すると、インスタンスの起動プロセスが始まります。従来の Lambda とは異なり、関数が実際にリクエストを受け付けられるようになるまでには、コンテナや EC2 の準備による待機時間が発生します。

初回起動時の遅延
- アベイラビリティーゾーン（AZ）の冗長性を確保するため、新規で作成した場合は既定で 3 台のインスタンスが起動します。3 つの実行環境が準備できた時点で関数バージョンが ACTIVE になり、リクエストを処理できるようになります。
急激なスパイクへの注意
- 自動スケーリングが追従できる速さには既定値があります。5 分間でトラフィックが 2 倍になるペースまでです。この既定値は設定で調整できます。これを超える急激なアクセス増加ではインスタンスの追加が間に合わず、一時的にスロットル（呼び出しエラー）が発生する場合があります。

3. セキュリティ境界としての役割

キャパシティプロバイダーは、設定の単位であると同時にセキュリティ境界でもあります。従来の Lambda は Firecracker の MicroVM で実行環境どうしを隔離していました。LMI は EC2 Nitro インスタンス上のコンテナで隔離します（Firecracker そのものは前回の記事で扱いました）。

AWS は、互いに信頼できないワークロードの隔離をコンテナに頼らず、キャパシティプロバイダーを分けるよう書いています。同じキャパシティプロバイダーに載せる関数は、互いに信頼できる関係である必要があります。

（出典: Lambda Managed Instances、Best practices for Lambda Managed Instances、AWS What’s New、2026-09-19 確認）

3. EC2 ベースの料金体系

LMI の料金モデルは、従来の「実行時間（GB 秒）ベース」から「確保した EC2 インスタンスの稼働時間ベース」へと変わります。

以下の図は、1 日のアクセスの平均に合わせて容量を確保した場合の例です。確保する量は設定によって変わります。

アクセスがある時間だけ課金されます。アクセスがゼロの時間帯は課金されません。

料金の内訳

全体のコストは、主に以下の 3 つの要素で構成されます。

EC2 インスタンス料金（オンデマンド基盤）
- 確保している EC2 の稼働時間に対して課金されます。
- Savings Plans（Compute / EC2）およびリザーブドインスタンス（RI）が適用可能なため、長期利用で大幅なコスト削減が狙えます。
Lambda 管理手数料（15%）
- EC2 のオンデマンド価格に対して 15% の管理費が加算されます（※この 15% 分は Savings Plans 等の割引対象外）。
リクエスト料金
- 100 万リクエストあたり 0.20 USD の固定料金が発生します（※実行時間に対する課金は一切ありません）。

なお ESM でプロビジョンドのイベントポーラーユニット（EPU）を使う場合は、その分の料金が別に発生します。

（出典: AWS Lambda 料金、Lambda Managed Instances、Best practices for Lambda Managed Instances、2026-09-19 確認、us-east-1）

LMI の使い分けとユースケース

ここまで解説した「1. 同時処理(Concurrency)の仕組み」「2. キャパシティプロバイダーの制約」「3. EC2 ベースの料金体系」を踏まえると、それぞれの基盤は以下のように使い分けるのが良いかと考えました。

従来の Lambda が向いているケース
- アクセスが不定期で、リクエストがゼロになる時間帯が多い
- 15 分以内で完了する軽量な処理やイベント駆動（S3 イベント連携など）
- インフラやキャパシティの管理意識を少なくしたい
LMI が向いているケース
- 15 分を超える長時間の処理や、重いデータ処理・バッチ処理を行いたい
- コールドスタートによる遅延を避け、常時安定した応答速度がほしい
- 常時一定以上のトラフィックがあり、Savings Plans を適用してコストを最適化したい
通常の EC2 / ECS が向いているケース
- OS レベルでのカスタム設定や特殊なミドルウェアの直接インストールが必要
- 既存の Docker コンテナ環境や運用フローをそのまま活用したい

まとめ

本記事では、2025 年 11 月に登場した Lambda マネージドインスタンス（LMI）について、従来の Lambda との違いを整理しました。

名前に「Lambda」とついているものの、個人的にその実体は 「自分の VPC に構築した EC2 を基盤にして（管理は AWS 側）、Lambda を実行する仕組み」 です。

実行基盤と同時処理
- 1 実行環境が 1 件ずつ処理する形から、各ランタイムのネイティブな並行処理（マルチスレッド／マルチプロセス）へのシフト。隔離は EC2 Nitro 上のコンテナが担う
運用とスケーリング
- 手動操作不可のキャパシティプロバイダー管理と、初回起動・急拡大時の準備時間
コストモデル
- 実行時間（GB 秒）から、確保した EC2 稼働時間への移行

LMI は既存の Lambda をすべて置き換えるものではなく、「サーバーレスの開発体験」と「EC2 のリソースや制限緩和」を組み合わせた新しい選択肢です。

これまでのようにアクセスが不定期な処理には従来の Lambda、長時間の処理や常時一定のトラフィックがあるワークロードには LMI といったように、構築するシステムの要件や制約に合わせて、柔軟に基盤を選んでいく必要がありそうです。