Lambda Managed Instances（LMI）は、Lambda 関数を自分のアカウントの EC2 で動かす実行方式です。2026 年 10 月時点で最大 32 GB / 16 vCPU、非同期と ESM なら 90 分まで動かせ、Graviton5 も選べます。料金は EC2 代＋15% の管理料＋リクエスト料。常に負荷がある処理に向き、まばらなトラフィックには通常の Lambda が向きます。
SNSでシェアして、他のエンジニアにも教えてあげましょう
Lambda Managed Instances（LMI）は、Lambda の関数を自分の AWS アカウントの EC2 インスタンスの上で動かす実行方式です。デプロイやイベント連携は今までの Lambda のまま、料金は「EC2 の料金＋15% の管理料＋リクエスト料」になり、1 つの実行環境が複数のリクエストを同時に処理します。2026 年 10 月時点で、最大 32 GB のメモリと 16 vCPU、非同期呼び出しとイベントソースマッピング（ESM）なら最大 90 分の実行、Graviton5 のインスタンスに対応しています。この記事では、Lambda Managed Instances の仕組みと発表の経緯、通常の Lambda との違い、料金の考え方、どんなワークロードで選ぶべきかを、AWS の公式情報をもとに整理します。
Lambda Managed Instances は、Lambda の使い勝手のまま、EC2 のハードウェアと料金体系を使える実行方式です。AWS は 2025 年 11 月 30 日に発表しました1。関数のコードやイベントソースの設定は通常の Lambda と同じで、違うのは「どこで動くか」と「どう課金されるか」です。
通常の Lambda（公式ドキュメントでは「Lambda (default)」）は、AWS が持つ共有のフリートの上で、Firecracker という microVM で関数ごとに分けて動きます。Lambda Managed Instances は、自分のアカウントの VPC の中に EC2 インスタンスが立ち、その上のコンテナで関数が動きます2。インスタンスの起動・停止、OS とランタイムのパッチ、リクエストの振り分け、スケーリングは Lambda が行うので、EC2 を自分で運用する必要はありません。
仕組みの中心は「キャパシティプロバイダー」です。
インスタンスは自分のアカウントにありますが、EC2 のコンソールの一覧には既定で出ず、手で終了させることもできません。消すときはキャパシティプロバイダーを削除します2。
発表から約 10 か月で、上限や対応リージョンが大きく広がったからです。特に 2026 年 9 月の 90 分タイムアウトと Graviton5 対応で、「Lambda では時間やメモリが足りないので ECS や EC2 に移す」という判断の前に、検討できる選択肢になりました。
| 日付 | 内容 |
|---|---|
| 2025-11-30 | 発表。Java・Node.js・Python・.NET に対応。米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド）で提供開始1 |
| 2026-03-27 | 最大 32 GB のメモリと 16 vCPU に対応。メモリと vCPU の比を 2:1・4:1・8:1 から選べるようになる3 |
| 2026-05-12 | Amazon EventBridge Scheduler によるスケジュールスケーリングに対応4 |
| 2026-06-08 | イスラエル（テルアビブ）、中東（バーレーン、UAE）、アジアパシフィック（オークランド）を除く全商用リージョンに拡大（AWS What's New） |
| 2026-09-09 | 非同期呼び出しと ESM で最大 90 分のタイムアウトに対応5。Graviton5 の C9g・C9gd・M9g・M9gd に対応6 |
| 項目 | 通常の Lambda | Lambda Managed Instances |
|---|---|---|
| メモリ（GB） | 10 | 32 |
| vCPU（個） | 6 | 16 |
| タイムアウト（分） | 15 | 90 |
AWS の発表によると、32 GB / 16 vCPU 対応の前は、Lambda の実行環境はメモリ 10 GB・約 6 vCPU が上限で、メモリと vCPU の比も選べませんでした3。通常の Lambda は今も 128 MB〜10,240 MB で、1,769 MB で 1 vCPU 相当になるように、メモリに比例して CPU が割り当てられます7。
90 分（5,400 秒）まで延ばせるのは、Lambda Managed Instances の関数を、非同期呼び出しかイベントソースマッピングで呼んだときだけです5。ここを取り違えると設計を誤るので、条件を表にまとめます。
| 呼び出し方 | 最大タイムアウト（LMI） |
|---|---|
同期呼び出し（API Gateway、関数 URL、aws lambda invoke など） | 15 分のまま5 |
非同期呼び出し（InvocationType=Event、S3 や EventBridge からの通知など） | 90 分5 |
| ESM（SQS、Kinesis、DynamoDB Streams、MSK、セルフマネージド Kafka） | 90 分5 |
| ESM のうち Amazon MQ と Amazon DocumentDB | 15 分のまま5 |
| 初期化（Init）フェーズ | 最大 15 分5 |
追加料金はなく、LMI の通常の料金のままです5。設定は通常の Lambda と同じ Timeout で、AWS CLI なら次のとおりです5。
aws lambda update-function-configuration \
--function-name my-data-processor \
--timeout 5400
SQS から呼ぶ場合は、キューの可視性タイムアウトを関数のタイムアウト以上にしておきます。そうしないと、処理中のメッセージが再び見えるようになり、二重に処理されます。
AWS CLI と AWS CDK の両方で作れます。どちらも、VPC が必要で、IAM ロールが 2 つ（関数の実行ロールと、Lambda が EC2 を操作するためのオペレーターロール）要る点が通常の Lambda と違います8。
公式の手順を要約すると次の流れです8。オペレーターロールには AWS 管理ポリシー AWSLambdaManagedEC2ResourceOperator を付けます。
# 1. キャパシティプロバイダー（VPC・オペレーターロール・アーキテクチャ・最大 vCPU）
aws lambda create-capacity-provider \
--capacity-provider-name my-capacity-provider \
--vpc-config SubnetIds=[$SUBNET_ID],SecurityGroupIds=[$SECURITY_GROUP_ID] \
--permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::${ACCOUNT_ID}:role/MyCapacityProviderOperatorRole \
--instance-requirements Architectures=[x86_64] \
--capacity-provider-scaling-config MaxVCpuCount=30
# 2. 関数（--capacity-provider-config で割り当てる）
aws lambda create-function \
--function-name my-managed-instance-function \
--package-type Zip \
--runtime python3.13 \
--handler lambda_function.lambda_handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::${ACCOUNT_ID}:role/MyLambdaExecutionRole \
--architectures x86_64 \
--memory-size 2048 \
--capacity-provider-config LambdaManagedInstancesCapacityProviderConfig={CapacityProviderArn=arn:aws:lambda:${REGION}:${ACCOUNT_ID}:capacity-provider:my-capacity-provider}
# 3. バージョンを発行すると、インスタンスと実行環境が起動する
aws lambda publish-version --function-name my-managed-instance-function
作成には数分かかります8。インスタンスは起動した時点から課金されるので、試したあとは関数とキャパシティプロバイダーを削除してください。
aws-cdk-lib 2.272.0 には lambda.CapacityProvider が入っています。次は、Graviton（arm64）のキャパシティプロバイダーに Node.js 22 の関数を割り当て、SQS から 90 分まで処理できるようにしたスタックです。デプロイはしていませんが、npx cdk synth が通り、テンプレートに Timeout: 5400 と実行環境の最小・最大が出ることを確かめました。
import * as path from 'node:path';
import * as cdk from 'aws-cdk-lib/core';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as sqs from 'aws-cdk-lib/aws-sqs';
import { SqsEventSource } from 'aws-cdk-lib/aws-lambda-event-sources';
export class LmiStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// LMI のインスタンスは自分の VPC の中で動く
const vpc = new ec2.Vpc(this, 'Vpc', { maxAzs: 3, natGateways: 1 });
const sg = new ec2.SecurityGroup(this, 'CapacityProviderSg', { vpc });
// キャパシティプロバイダー: どの EC2 で動かすか（Graviton = arm64）
const cp = new lambda.CapacityProvider(this, 'CapacityProvider', {
subnets: vpc.privateSubnets,
securityGroups: [sg],
architectures: [lambda.Architecture.ARM_64],
maxVCpuCount: 64,
});
// 90 分（5,400 秒）のタイムアウトは非同期呼び出しと ESM（ここでは SQS）だけで使える
const fn = new lambda.Function(this, 'BatchFunction', {
runtime: lambda.Runtime.NODEJS_22_X,
architecture: lambda.Architecture.ARM_64,
handler: 'index.handler',
code: lambda.Code.fromAsset(path.join(__dirname, '../handler')),
memorySize: 8192,
timeout: cdk.Duration.minutes(90),
});
cp.addFunction(fn, {
executionEnvironmentMemoryGiBPerVCpu: 4, // メモリ:vCPU = 4:1（8 GB なら 2 vCPU）
perExecutionEnvironmentMaxConcurrency: 8,
latestPublishedScalingConfig: { minExecutionEnvironments: 3, maxExecutionEnvironments: 30 },
});
// SQS の可視性タイムアウトは関数のタイムアウト以上にする
const queue = new sqs.Queue(this, 'Jobs', { visibilityTimeout: cdk.Duration.minutes(90) });
fn.addEventSource(new SqsEventSource(queue, { batchSize: 1 }));
}
}
synth すると「キャパシティプロバイダーの設定は関数から外せず、変更しかできない」という注記が出ます。CDK の README にも、一度キャパシティプロバイダーを使った関数からは設定を外せない、と同じ内容が書かれています。通常の Lambda に戻すときは、関数を作り直す前提で考えてください。
CDK で AI エージェントにインフラを書かせる進め方は AWS CDK を Claude Code で書く で扱っています。
一番大きな違いは、スケーリングの仕方と課金の単位です。通常の Lambda はリクエストが来て空きが無ければ実行環境を増やし（コールドスタート）、使われなければ 0 まで減ります。LMI は CPU の使用率とマルチコンカレンシーの飽和度を見て非同期に増減し、コールドスタートは起きない代わりに、トラフィックが無くても最小数の実行環境が残ります4。
| 観点 | 通常の Lambda | Lambda Managed Instances |
|---|---|---|
| 動く場所 | AWS の共有フリート（Firecracker microVM） | 自分のアカウントの EC2（Nitro）上のコンテナ2 |
| 同時実行 | 1 つの実行環境で 1 リクエストずつ | 1 つの実行環境で複数のリクエストを同時に処理2 |
| スケーリング | リクエストに応じて増やす。0 まで減る | CPU 使用率と同時実行の飽和度で非同期に増減。既定の最小は 3 実行環境4 |
| コールドスタート | あり | 無い（その代わり急増に弱い） |
| メモリ・vCPU | 128 MB〜10,240 MB。CPU はメモリに比例7 | 最小 2 GB・1 vCPU、最大 32 GB・16 vCPU。比は 2:1・4:1・8:134 |
| タイムアウト | 15 分 | 同期 15 分、非同期・ESM 90 分5 |
| 料金 | リクエスト数＋実行時間（GB 秒） | リクエスト数＋EC2 の料金＋管理料 15%2 |
| 割引 | Compute Savings Plans | EC2 の Savings Plans・リザーブドインスタンスも使える（管理料には効かない）2 |
| ネットワーク | VPC は任意 | VPC が必須8 |
LMI では 1 つの実行環境に複数のリクエストが同時に入るので、グローバル変数の共有や / の使い方に注意が要ります。実装はランタイムごとに違います9。
| ランタイム（2026 年 10 月時点の対応版） | 同時実行の実装 | 気をつけること |
|---|---|---|
| Java 21 以降 | 1 プロセスの OS スレッド | 共有する状態をスレッドセーフにする |
| Python 3.13 以降 | リクエストごとに別プロセス | / など共有の資源。メモリ比を 4:1 や 8:1 に上げる必要がある場合も4 |
| Node.js 22 以降 | ワーカースレッド＋非同期 | ワーカー内でも並行に動く。モジュールスコープの状態に注意 |
| .NET 8 以降 | Task による非同期 | 共有の状態を安全に扱う |
Rust（provided.al2023） | Tokio の非同期タスク | ハンドラは Clone + Send にする |
公式の対応言語の一覧に Go は載っていません（2026 年 10 月時点）9。provided.al2023 で動かす言語として記載があるのは Rust だけなので、Go で使う場合は対応状況を公式ドキュメントで確かめてから検討してください。
調整できるのは、関数側の「メモリと vCPU」「実行環境あたりの最大同時実行数（vCPU あたり最大 64）」「実行環境の最小数と最大数」と、キャパシティプロバイダー側の「目標の CPU 使用率」「インスタンスの種類」の 5 つです4。実行環境の最小・最大は 0〜15,000 で、両方を 0 にすると関数を消さずに停止できます4。
aws lambda put-function-scaling-config \
--function-name my-lmi-function \
--qualifier '$LATEST.PUBLISHED' \
--function-scaling-config MinExecutionEnvironments=5,MaxExecutionEnvironments=20
2026 年 5 月からは、この設定を EventBridge Scheduler で時間に合わせて変えられます4。公式ドキュメントでは、Scheduler のユニバーサルターゲットとして PutFunctionScalingConfig API を呼ぶ例が載っています4。たとえば営業時間の前に最小数を上げ、夜は両方を 0 にして止める、という運用ができます。ただし 0 にした関数はトラフィックが来ても自動では戻らないので、再開のスケジュールも必ず作ります4。
料金は「リクエスト 100 万件あたり 0.20 ドル」「EC2 インスタンスの料金」「EC2 オンデマンド料金の 15% の管理料」の 3 つの合計です10。Savings Plans やリザーブドインスタンスの割引は EC2 の部分だけに効き、管理料はオンデマンド料金を基準に計算されます2。
公式の料金ページは、米国東部（バージニア北部）の m7g.xlarge（4 vCPU・16 GiB）を例にしています。オンデマンドは 1 時間 0.1632 ドル、3 年の Compute Savings Plans で 0.0457 ドル、管理料は 0.1632 × 0.15 = 0.02448 ドルです10。これを 1 か月（730 時間）動かし続けた場合を、通常の Lambda の Arm（1 GB 秒あたり 0.0000133334 ドル）で 1 vCPU 相当（1,769 MB）を 1 か月休まず動かした場合と比べたのが次の表です。
| 構成（米国東部、1 か月 730 時間、リクエスト料は除く） | 計算式 | 月額 | 1 vCPU あたり |
|---|---|---|---|
| 通常の Lambda（Arm・1,769 MB を 1 本、常に処理中） | 1,769 ÷ 1,024 GB × 2,628,000 秒 × 0.0000133334 | 60.53 ドル | 60.53 ドル |
| LMI・m7g.xlarge 1 台（オンデマンド） | (0.1632 + 0.02448) × 730 | 137.01 ドル | 34.25 ドル |
| LMI・m7g.xlarge 1 台（3 年 Compute Savings Plans） | (0.0457 + 0.02448) × 730 | 51.23 ドル | 12.81 ドル |
（筆者計算。元データ: AWS Lambda 料金ページの単価と LMI の料金例、2026-10-05 参照）
通常の Lambda では 1 つの実行環境が 1 リクエストしか処理しないのに対し、LMI では 1 vCPU の上で複数のリクエストを同時に処理できます。I/O 待ちの多い処理ほど、LMI の 1 vCPU あたりの処理量は増えます。逆に、LMI は既定で 3 つの実行環境（AZ ごとのインスタンス）を常に動かすので、トラフィックがほとんど無い関数では最低料金が先に立ちます2。比べるときは「平均してどれだけ CPU を使い続けるか」で判断してください。
試算には、AWS が公開している LMI の料金計算ツールも使えます2。
結論は、負荷が一日中ある、または予測できる処理は LMI、まばらで急に跳ねる処理は通常の Lambdaです。AWS の公式ドキュメントも、LMI を「急なスパイクの少ない、量が多く予測しやすいワークロード」向けとし、通常の Lambda を「バーストがあり、コールドスタートを許容できる、または 0 までのスケールが嬉しい」関数向けとしています2。
| ワークロード | おすすめ | 理由 |
|---|---|---|
| 一日中リクエストがある Web API・マイクロサービス | LMI | マルチコンカレンシーで I/O 待ちを詰められ、Savings Plans も効く |
| 15 分を超えるバッチ・ETL・動画の変換（SQS や非同期で起動） | LMI | 非同期・ESM なら 90 分まで動ける。32 GB・16 vCPU も使える |
| 高帯域のネットワークや最新 CPU（Graviton5）が要る処理 | LMI | インスタンスの種類を選べる。Graviton5 は Graviton4 より最大 25% 高い計算性能6 |
| 規制で VPC や配置を管理したい処理 | LMI | 自分のアカウントの VPC で動く |
| 夜間や休日はほぼゼロになる社内ツール | 通常の Lambda | 0 まで縮み、使った分だけの課金 |
| 5 分以内にトラフィックが 2 倍以上に跳ねるイベント | 通常の Lambda | LMI はトラフィックが 5 分以内に倍を超えるとスロットリングが起きうる4 |
| 15 分以内で終わる同期 API | どちらでも | 量と平均の CPU 使用率で比べる |
| 15 分を超える同期 API | どちらも不向き | 同期は LMI でも 15 分まで。ECS や非同期の設計に変える |
もう 1 つの選択肢として、Lambda の「Durable Functions」は、複数のステップに分けてチェックポイントを取りながら、非同期なら最大 1 年まで続くワークフローを書けます57。1 回の処理が長いなら LMI、待ち時間を含めて全体が長いなら Durable Functions、と分けて考えると整理しやすくなります。
Lambda と他のサーバーレスの比較は Cloudflare Workers と AWS Lambda の比較 にまとめています。
ConcurrencyThrottles・CPUThrottles・MemoryThrottles・DiskThrottles のメトリクスで、どの資源が足りないかを見分けます4まずは開発用のアカウントで、小さなインスタンスに絞ったキャパシティプロバイダーを作り、既存の SQS のワーカーを 1 つ載せて CPU 使用率と料金を測るところから始めてください。
AWS は 2025 年 11 月 30 日に発表しました（re:Invent 2025 の時期）1。提供開始時は Java・Node.js・Python・.NET に対応し、東京を含む 5 つのリージョンで使えました。2026 年 6 月 8 日に、一部を除く全商用リージョンへ広がっています。
使えません。90 分まで延ばせるのは、Lambda Managed Instances の関数を非同期呼び出しかイベントソースマッピングで呼んだときだけです5。API Gateway や関数 URL のような同期呼び出しは 15 分のままです。ESM でも Amazon MQ と Amazon DocumentDB は 15 分です5。
リクエスト 100 万件あたり 0.20 ドル、EC2 インスタンスの料金、EC2 オンデマンド料金の 15% の管理料の合計です10。Savings Plans やリザーブドインスタンスの割引は EC2 の部分に効きますが、管理料はオンデマンド料金を基準にするので割引されません2。
リクエストを受けてから実行環境を起動する、という意味のコールドスタートはありません。CPU の使用率と同時実行の飽和度を見て、先に実行環境を増やします4。その代わり、トラフィックが 5 分以内に 2 倍を超えて増えると、増設が間に合わずスロットリングが起きることがあります4。
2026 年 10 月時点の公式の対応言語一覧は、Java 21 以降、Python 3.13 以降、Node.js 22 以降、.NET 8 以降と、provided.al2023 での Rust です9。Go は一覧に載っていないので、使う前に公式ドキュメントで最新の対応状況を確認してください。
Announcing AWS Lambda Managed Instances, a capability to run functions on your Amazon EC2 instances — AWS What's New, 2025-11-30（2026-10-05 参照） ↩ ↩2 ↩3
Lambda Managed Instances — AWS Lambda Developer Guide（2026-10-05 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
AWS Lambda supports up to 32 GB of memory and 16 vCPUs for Lambda Managed Instances — AWS What's New, 2026-03-27（2026-10-05 参照） ↩ ↩2 ↩3
Scaling Lambda Managed Instances — AWS Lambda Developer Guide（2026-10-05 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15
Announcing 90-minute function timeout on AWS Lambda Managed Instances — AWS Compute Blog, 2026-09-09（2026-10-05 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13
AWS Lambda now supports Graviton5-powered EC2 instances on Lambda Managed Instances — AWS What's New, 2026-09-09（2026-10-05 参照） ↩ ↩2
Lambda quotas — AWS Lambda Developer Guide（2026-10-05 参照） ↩ ↩2 ↩3
Getting started with Lambda Managed Instances — AWS Lambda Developer Guide（2026-10-05 参照） ↩ ↩2 ↩3 ↩4 ↩5
Lambda Managed Instances runtimes — AWS Lambda Developer Guide（2026-10-05 参照） ↩ ↩2 ↩3
AWS Lambda 料金 — Amazon Web Services（2026-10-05 参照） ↩ ↩2 ↩3