2026.09.24 インフラ

Lambda Managed Instancesとは？料金の実額・90分実行・標準Lambdaとの使い分け【2026年9月】

Adureを利用したインフラ構築

Lambda Managed Instancesは、自分のAWSアカウント内のEC2インスタンス上でLambda関数を動かす実行形態です。2025年11月30日に発表され、東京リージョンでも提供が始まりました。関数の書き方やイベント連携はLambdaのまま、課金はEC2料金に15%の管理手数料を乗せた形に変わり、1つの実行環境が複数のリクエストを同時に処理します。この記事では、AWS公式ドキュメントと東京リージョンの料金データをもとに、仕組み・料金の実額・CLIでの構築手順・コードの注意点を整理し、標準のAWS Lambdaから移すかどうかの判断基準を示します。

まとめ：Lambda Managed Instancesの要点と標準Lambdaから移すかの結論

Lambda Managed Instancesは「Lambdaの運用のまま、EC2の料金体系とハードウェアを選べる」形態です。コールドスタートは無く、実行時間ではなくインスタンスの稼働時間に課金されます。そのかわりトラフィックが無くてもゼロまで縮まず、既定で3つの実行環境が常に立ち上がっています。

結論を先に書きます。昼夜を問わず一定以上のリクエストが流れ続けるAPIやキュー処理なら、標準Lambdaより安くなる余地があります。東京リージョンのm7g.xlargeで試算すると、3台構成の床コストは月額約531ドルで、標準Lambda（arm64・2GB）を平均7〜8本の同時実行で常時動かし続けるのと同水準です。これを下回る負荷や、夜間にほぼ止まる業務システムでは、標準Lambdaのほうが安く済みます。

もう1点、Savings Plansの割引はEC2部分にしか効かず、管理手数料はオンデマンド価格の15%で固定です。3年のCompute Savings Plansで72%引きになっても、合計の割引率は6割台に留まります。見積の段階でこの差を織り込んでください。

Lambda Managed Instancesの仕組みと標準Lambdaとの5つの違い

仕組みの核は「キャパシティプロバイダー」という新しいリソースです。関数をどのVPC・どのインスタンスで動かすかを、関数とは別に定義します。

キャパシティプロバイダーと関数バージョン公開で動き出す3段階の構成

構築の流れは3段階です。最初にキャパシティプロバイダーを作り、サブネット・セキュリティグループ・EC2を操作させるIAMロールを指定します。次に通常どおり関数を作ってキャパシティプロバイダーに紐づけ、最後に行うのが関数のバージョン発行です。バージョンを発行した時点で、Lambdaはアカウント内にインスタンスを起動し、アベイラビリティーゾーンの冗長性のために既定で3台、実行環境を3つ立ち上げてから関数を ACTIVE にします。

起動したインスタンスは Amazon EC2 の通常のインスタンスとして課金されますが、手動で停止や削除はできません。EC2コンソールでは既定で非表示になっており、aws:lambda:capacity-provider タグで識別します。消したいときはキャパシティプロバイダーごと削除します。2026年7月24日からは、インスタンスの起動・終了・ヘルスチェックを記録するキャパシティプロバイダーログがCloudWatch Logsへ既定で出力されるようになりました。

同時実行・分離方式・課金・スケール・向く負荷で比べた実行形態の比較表

公式の比較表をもとに、実装への影響が大きい順に並べました。

項目 標準のLambda Lambda Managed Instances
同時実行 1環境で1リクエストずつ 1環境で複数リクエストを同時処理
スケール 空きなしでコールドスタート・ゼロまで縮む CPU使用率・同時実行飽和度で増減（下限あり）
課金 リクエスト数＋実行時間（GB秒） リクエスト数＋EC2料金＋管理手数料15%
分離方式 Firecracker MicroVM（共有） 自アカウントのEC2 Nitro上のコンテナ
タイムアウト上限 900秒 同期900秒・非同期とESMは5,400秒
向く負荷 スパイクがあり、ゼロまで縮めたい処理 量が多く予測しやすい定常負荷

標準Lambdaは共有フリート上で動き、空き環境がなければ新しい環境を起動するコールドスタートが発生します。Managed Instancesの増減は非同期で行われ、実行環境数は設定された最小数を下回りません。表の上2行が設計を最も大きく変えます。同時実行の違いはコードの書き方に、スケールの違いは料金の床に直結するため、以降の章で個別に扱います。

Lambda Managed Instancesの料金を東京リージョンの実額で試算する手順

公式の料金ページによると、課金はリクエスト料金・EC2インスタンス料金・管理手数料の3つです。標準Lambdaの実行時間課金（GB秒）はかかりません。

管理手数料15%がオンデマンド価格に掛かる計算式と東京の単価表

リクエスト料金は100万件あたり0.20ドルで、標準Lambdaと同額です。管理手数料は「EC2オンデマンド価格の15%」と定義されています。ここが見落とされやすい箇所で、Savings PlansやリザーブドインスタンスでEC2料金を下げても、手数料の計算元は割引前のオンデマンド価格のままです。東京リージョンの手数料をAWSのPrice List API（2026年9月19日版）で取り出した値が次の表です。

インスタンス vCPU／メモリ 管理手数料（1時間） オンデマンド価格（手数料から逆算）
m7g.large 2／8GiB 0.01581ドル 0.1054ドル
m7g.xlarge 4／16GiB 0.03162ドル 0.2108ドル
m8g.xlarge 4／16GiB 0.034785ドル 0.2319ドル
c7g.xlarge 4／8GiB 0.027285ドル 0.1819ドル

右端の列は手数料を0.15で割り戻した値です。EC2の請求額そのものはEC2側の料金表で確認してください。

Savings Plans適用で手数料の比率が35%まで上がる試算結果

m7g.xlargeを1台、月730時間動かした場合を比べます。割引率72%は、料金ページの計算例（バージニア北部・3年のCompute Savings Plans）の数字を当てはめた仮定です。東京の実際の割引率はSavings Plansの料金表で確かめてください。

条件 EC2料金／月 管理手数料／月 合計／月 手数料の比率
オンデマンド 153.88ドル 23.08ドル 176.97ドル 13%
Savings Plans 72%引き（仮定） 43.09ドル 23.08ドル 66.17ドル 35%

EC2部分は72%下がっても、合計では63%引きに留まります。公式の計算例でも、EC2料金91.40ドルに対して管理手数料は48.96ドルと、半分を超える額が乗っていました。社内の稟議でSavings Plansの割引率をそのまま掛けた見積を出すと、実請求との差が毎月生じます。標準Lambda側の単価と付帯課金の内訳はLambdaの料金を東京リージョンの実額で計算する記事で扱っています。

最低3環境の床コストと標準Lambdaとの損益分岐になる平均同時実行数

標準Lambdaの東京リージョンの単価は、arm64で1GB秒あたり0.0000133334ドルです。2GBの関数を1本、1か月休まず動かし続けると約70.08ドルになります。Managed Instancesのm7g.xlargeはオンデマンドで1台176.97ドルなので、1台だけなら平均2.5本の常時実行で並びます。

ただし既定の最小は3環境で、Lambdaは複数のゾーンに分けて配置します。3台がそのまま立ち上がる構成なら床コストは約531ドル、標準Lambdaの平均同時実行で約7.6本分です。インスタンス種別はLambdaが負荷を見て選ぶため、実際の台数と種別は構築後にEC2側のタグで確かめる必要があります。

判断の目安は「平均同時実行が1桁前半なら標準Lambda、2桁が続くならManaged Instancesの試算に進む」です。1環境が複数のリクエストをさばけるI/O待ち中心の処理ほど、1台あたりの処理量が増えて分岐点は手前に来ます。

CLIでキャパシティプロバイダーと関数を作成して呼び出す手順

公式の開始手順に沿って、AWS CLIで最小構成を作ります。事前にIAMロールが2つ要ります。関数の実行ロールと、LambdaにEC2を操作させるオペレーターロールです。

オペレーターロールとVPCを用意してから実行する作成コマンド

オペレーターロールには管理ポリシー AWSLambdaManagedEC2ResourceOperator を付けます。アカウントで初めてキャパシティプロバイダーを作るときは、サービスリンクロールの作成権限 iam:CreateServiceLinkedRole も必要です。サブネットは最大16個まで指定でき、基本の構成としてゾーンをまたいで複数渡します。以下はarm64を指定し、キャパシティプロバイダー全体の上限を30vCPUに絞った例です。

# 1) キャパシティプロバイダーを作成する（arm64・最大30vCPU）
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=ap-northeast-1

aws lambda create-capacity-provider \
  --capacity-provider-name api-prod-trusted \
  --vpc-config SubnetIds=[subnet-aaaa,subnet-bbbb,subnet-cccc],SecurityGroupIds=[sg-1111] \
  --permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::${ACCOUNT_ID}:role/MyCapacityProviderOperatorRole \
  --instance-requirements Architectures=[arm64] \
  --capacity-provider-scaling-config MaxVCpuCount=30

# 2) 関数を作成してキャパシティプロバイダーに紐づける（最小2GB・1vCPU）
aws lambda create-function \
  --function-name orders-api \
  --runtime python3.13 \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://function.zip \
  --role arn:aws:iam::${ACCOUNT_ID}:role/MyLambdaExecutionRole \
  --architectures arm64 \
  --memory-size 2048 \
  --capacity-provider-config LambdaManagedInstancesCapacityProviderConfig={CapacityProviderArn=arn:aws:lambda:${REGION}:${ACCOUNT_ID}:capacity-provider:api-prod-trusted}

# 3) バージョンを発行する（ここでインスタンスが起動する）
aws lambda publish-version --function-name orders-api

# 4) 発行したバージョンを指定して呼び出す
aws lambda invoke --function-name orders-api:1 --payload '{"id": "42"}' \
  --cli-binary-format raw-in-base64-out response.json

関数のアーキテクチャは、キャパシティプロバイダーで指定したものと揃えます。$LATEST のままでは動かず、手順3のバージョン発行が必須です。作成には数分かかります。

メモリ対vCPU比と同時実行上限を決める2つの設定値の指定範囲

関数側で調整する値は、メモリ量のほかに2つあります。ExecutionEnvironmentMemoryGiBPerVCpu はvCPU1つあたりのメモリで、2.0から8.0の範囲です。PerExecutionEnvironmentMaxConcurrency は1環境に送る同時リクエストの上限で、APIリファレンス上は1から1,600まで指定できます。

関数の最小サイズは2GB・1vCPUで、1vCPU未満にはできません。Pythonの既定の同時実行上限はvCPUあたり16です。Pythonは同時実行の数だけプロセスを立てるため、重いライブラリを読み込む関数では、メモリ比を4対1や8対1に上げるか同時実行上限を下げます。インスタンス種別を絞る場合の考え方はEC2インスタンスタイプの選び方が参考になりますが、公式は種別の指定を狭めると確保できる台数が減るとして、Lambdaに任せることを推奨しています。

マルチ同時実行への移行で壊れるコードと90分タイムアウトの適用範囲

標準Lambdaで問題なく動いていた関数が、Managed Instancesへ移しただけで壊れることがあります。原因の大半は、1つの実行環境に複数のリクエストが同時に入る点です。

/tmpの共有とグローバル変数で起きる競合をランタイム別に避ける書き方

対応ランタイムはJava 21以降・Python 3.13以降・Node.js 22以降・.NET 8以降と、provided.al2023 を使うRustです。同時実行の実装はランタイムごとに違います。

  • Java：1プロセスの複数スレッドで同じハンドラーを同時に実行するため、共有オブジェクトはスレッドセーフにする
  • Node.js：ワーカースレッドに振り分け、各スレッドも非同期で複数件を処理する。モジュール直下の変数に状態を持たせない
  • Python：リクエストごとに別プロセスで動くため、メモリ上の変数は混ざらない。ただし /tmp は全プロセスで共有
  • .NET：Taskで非同期に並行処理する。共有状態の扱いはJavaと同じ注意が要る

Pythonで見落とされやすいのが /tmp です。Pythonランタイムの解説は、同じファイル名への同時書き込みでデータが壊れうるとして、ファイルロックかリクエストごとに一意なファイル名を使うよう求めています。固定名の作業ファイルを使っている関数は、次のように書き換えます。

import os
import tempfile

def lambda_handler(event, context):
    # 固定名（/tmp/work.csv）は同時実行中の別リクエストと衝突する
    fd, path = tempfile.mkstemp(dir="/tmp", prefix=f"{context.aws_request_id}-", suffix=".csv")
    try:
        with os.fdopen(fd, "w") as f:
            f.write(build_csv(event))
        upload(path)
    finally:
        os.remove(path)  # 残すと共有の/tmpを使い切る
    return {"statusCode": 200}

ログも1つのストリームに複数リクエスト分が混ざります。Managed Instancesの関数は常にJSON形式の構造化ログで出力され、requestId が各行に入るため、調査時はこの値で絞り込みます。

非同期とESMだけが5,400秒まで延びた2026年9月の変更と同期の上限

2026年9月9日の発表で、Managed Instancesの関数は非同期呼び出しとイベントソースマッピング（ESM）経由の呼び出しに限り、タイムアウトを90分まで設定できるようになりました。タイムアウト設定のページには、上限5,400秒のうちAmazon MQとAmazon DocumentDBのESMは対象外と書かれています。

同期呼び出しは従来どおり900秒です。API Gateway経由のAPIや RequestResponse での呼び出しは15分で打ち切られるため、「Managed Instancesにすれば90分動く」と一括りにすると設計を誤ります。長い処理はSQSやEventBridgeを挟んで非同期に切り替えるか、待機の多いワークフローならLambda Durable Functionsで長時間ワークフローを組む方法を比べてください。

Lambda Managed Instancesを採用する条件と見送るべき案件の線引き

判断を言い切ります。Managed Instancesは標準Lambdaの上位版ではなく、定常負荷に寄せた別の料金モデルです。

採用してよい条件とキャパシティプロバイダーを信頼境界で分ける前提

次の条件がそろう場合は、試算と検証に進む価値があります。

  • 平均同時実行が2桁で推移し、夜間や休日も負荷がゼロにならない
  • I/O待ちが長く、1環境で複数リクエストを並行処理する効果が大きい
  • Graviton4や高帯域ネットワークなど、標準Lambdaでは選べないハードウェアが要る
  • EC2のSavings Plansを既に購入しており、その枠へ寄せられる

前提として、キャパシティプロバイダーは信頼境界として扱います。公式ドキュメントは、同じキャパシティプロバイダー上の関数どうしはコンテナで分けられているだけで、強い分離にはならないと明記しています。顧客ごとのコードや外部から持ち込まれる処理を扱うなら、キャパシティプロバイダー自体を分けてください。VPC設計・IAM・コスト試算を含めて移行の可否を判断したい場合は、AWSを含むインフラ構築支援で既存のLambda構成の見直しから相談できます。

標準Lambdaのままにすべき3つの場面と移行時に踏む失敗の具体例

1つ目は、稼働がまばらな業務システムです。社内の申請処理や夜間に止まるAPIは、ゼロまで縮む標準Lambdaの課金が最も効きます。Managed Instancesに移すと、使っていない時間も3環境分のインスタンス料金が流れ続けます。

2つ目は、5分以内にトラフィックが2倍を超える急増がある処理です。スケーリングの解説によると、Managed Instancesは既定で5分以内の倍増までを吸収する余力を持ちますが、それを超える増え方ではスロットリングが起きえます。キャンペーン開始直後に集中するECの注文APIなどは、標準Lambdaのほうが安全です。

3つ目は、グローバル変数や固定名ファイルに状態を持たせたコードが多く、改修の工数を確保できない場合です。移行でよく起きる失敗は、単価の比較だけで決めて、同時実行による不具合を本番で初めて踏むことです。移す前に、同じ関数を並行で叩く負荷試験を必ず通してください。

よくある質問

Lambda Managed Instancesについて検索されることの多い質問に、公式ドキュメントで確認できる範囲で答えます。

Lambda Managed Instancesは東京リージョンで使えますか？

使えます。2025年11月30日の提供開始の発表で、バージニア北部・オハイオ・オレゴン・アイルランドとともに東京が対象に含まれていました。東京リージョンの管理手数料はPrice List APIにも掲載されており、m7g.xlargeで1時間0.03162ドルです。

トラフィックが無いときにゼロまでスケールインできますか？

自動ではゼロになりません。負荷が無くても最小の実行環境数（既定3）を保ちます。止めたい場合は put-function-scaling-config で最小と最大をともに0に設定すれば、関数を削除せずに無効化できる仕組みです。自動では再開しないため、再開も同じコマンドで0以外の値を設定します。EventBridge Schedulerで夜間停止と朝の再開を組む例が公式に載っています。

標準のLambdaからコードを変えずに移行できますか？

書き方の形は同じですが、そのまま動く保証はありません。1環境に複数のリクエストが同時に入るため、JavaとNode.js、.NETでは共有状態の扱いを、Pythonでは /tmp の使い方を見直す必要があります。Python向けのPowertools for AWS Lambdaは3.23.0以降が必要です。移行前に並行実行の負荷試験を通してください。

Provisioned Concurrencyとの違いは何ですか？

Provisioned Concurrencyは、標準Lambdaの実行環境を事前に温めておく仕組みで、1環境が1リクエストずつ処理する点は変わりません。Managed Instancesは実行基盤そのものを自アカウントのEC2に置き換え、1環境で複数リクエストを処理し、EC2のSavings Plansも使えます。コールドスタート対策だけが目的ならProvisioned Concurrency、定常負荷の単価を下げたいならManaged Instancesが比較の出発点です。

1つのキャパシティプロバイダーに何個まで関数を載せられますか？

クォータ一覧では、1つのキャパシティプロバイダーに紐づけられる関数バージョンは100個までで、引き上げはできません。キャパシティプロバイダーはアカウントあたり1,000個、vCPUは1つあたり15,000個が上限です。作成や更新の書き込みAPIは毎秒1回に制限されているため、IaCで大量に作る場合は並列度を下げます。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る