AWS Lambda マネージドインスタンス
2025年11月末にAWS Lambda Managed Instances（Lambda マネージドインスタンス）が発表されました。
Amazon EC2上でAWS Lambda関数を実行できる機能だそうです。
https://aws.amazon.com/jp/blogs/news/introducing-aws-lambda-managed-instances-serverless-simplicity-with-ec2-flexibility/
Lambdaの特性について今一度確認したうえで、移行メリットを確認します。
※2026/02/14に確認しましたが、無料枠ではLambda マネージドインスタンスは使用できない可能性があります。
そもそもAWS Lambdaとは
サーバーレスで関数（コード）を実行できるAWSのコンピューティングサービスです。
※サーバーレス（＝自身がサーバーを管理しないという意味）
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html
よくサーバレスAPIとして次項の構成が挙げられるため、まずはこちらを用いてLambdaの特性を確認します。
Lambda × API Gateway
Lambda
Lambda>関数>関数を作成
一から作成を選んで作成。
サンプルコードを下記のように変更してデプロイします。
※わざとステートレスではない（=状態を持つ）コードを書いてみます。
let counter = 0;
export const handler = async (event) => {
counter++;
console.log("current counter:", counter);
return {
statusCode: 200,
body: JSON.stringify({
counter
}),
};
};
API Gateway
API>APIを作成>REST APIを作成
作成したLambdaをGETで呼び出すようにメソッドを設定します。
デプロイするとAPI エンドポイントが発行されます。
エンドポイントを叩くとLambdaが動きます。
今回のものは叩く毎にカウンタが+1され、その値が出力される仕組みになっています。
サーバーに一切触れることなく、コードの実行を完遂できました。
Lambdaの特性
コードはステートレスである必要がある
1時間放置後に同エンドポイントを叩くと、カウントがリセットされました。
これはLambdaの特性によるものです。関数の呼び出し数や実行環境の数に応じて自動でスケーリングが行われるので、同じ実行環境が用意される保証はありません。ゆえにステートレスである必要があります。
https://aws.amazon.com/jp/builders-flash/202308/learn-lambda-function-execution/
初期化が重いとコールドスタートが遅延する
※コールドスタート=コードのロード＋実行環境の準備時間の和。実行環境立ち上げ時に発生します。
Lambdaはイベント駆動＝トリガー時に都度関数が実行される作りになっているので、利用頻度が低い場合は都度コールドスタートの分だけロスすることになります。
頻度が高くても不意に遭遇することもあります。
長時間処理、常駐処理に向いていない
LambdaのタイムアウトがMAX15分です。
加えてAPI Gatewayのタイムアウトも基本29秒ですので、冒頭の構成だと思い処理は任せられません。
コンテナイメージ実行環境の性能カスタマイズに限界がある
添付画像のような設定はできますが、EC2ほどの豊富さではありません。
検証
LambdaからLambda マネージドインスタンスに乗せ換えると早くなるのか、確認してみます。
利用するソースコードは以下の通り。わざと初期化に時間がかかるようにしています。
import json, time, os
INIT_TS = time.time()
COLD = True
_boot = sum(i*i for i in range(200_000))
def lambda_handler(event, context):
global COLD
t0 = time.time()
work = sum(i*i for i in range(50_000))
body = {
"cold_start": COLD,
"uptime_ms": int((time.time() - INIT_TS) * 1000),
"handler_ms": int((time.time() - t0) * 1000),
"region": os.environ.get("AWS_REGION"),
"work": work,
}
COLD = False
return {"statusCode": 200, "headers": {"content-type": "application/json"}, "body": json.dumps(body)}
Lambdaに負荷をかける
前述のソースコードでLambda関数を作成して、関数URLを発行します。
後述のLambda マネージドインスタンスがメモリ2GBからなので、こちらも設定で2GBにしておきます。
また、API Gatewayを使用せずLambdaに直接エンドポイントを付与できる関数URLを使用します。
LambdaとLambda マネージドインスタンスの性能差を直接見るためです。
heyで負荷をかけます。
xxx:~$ $HOME/go/bin/hey -n 50 -c 5 https://{Lambda関数URL}.lambda-url.ap-northeast-1.on.aws/
Summary:
Total: 0.8530 secs
Slowest: 0.6190 secs
Fastest: 0.0227 secs
Average: 0.0833 secs
Requests/sec: 58.6162
Total data: 5381 bytes
Size/request: 107 bytes
Response time histogram:
0.023 [1] |■
0.082 [44] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.142 [0] |
0.202 [0] |
0.261 [0] |
0.321 [0] |
0.380 [0] |
0.440 [0] |
0.500 [0] |
0.559 [1] |■
0.619 [4] |■■■■
Latency distribution:
10%% in 0.0244 secs
25%% in 0.0260 secs
50%% in 0.0270 secs
75%% in 0.0294 secs
90%% in 0.5530 secs
95%% in 0.5938 secs
0%% in 0.0000 secs
Details (average, fastest, slowest):
DNS+dialup: 0.0232 secs, 0.0000 secs, 0.2331 secs
DNS-lookup: 0.0214 secs, 0.0000 secs, 0.2136 secs
req write: 0.0000 secs, 0.0000 secs, 0.0001 secs
resp wait: 0.0599 secs, 0.0225 secs, 0.3872 secs
resp read: 0.0001 secs, 0.0000 secs, 0.0003 secs
Status code distribution:
[200] 50 responses
CloudWatchに5つのログストリームが作成され、それぞれにInitのログが出ていました。
少なくとも5つの実行環境が新規に起動しており、それぞれで初回実行（コールドスタート）が発生していたことが確認できました。
INIT_START Runtime Version: python:3.14.v35 Runtime Version ARN: arn:aws:lambda:ap-northeast-1::runtime:xxx...
Lambda マネージドインスタンスに負荷をかける
比較用にLambda マネージドインスタンスの方でも同じ負荷を流します。
まずは公式ブログに従ってLambda マネージドインスタンスを設定してみます。
https://aws.amazon.com/jp/blogs/news/introducing-aws-lambda-managed-instances-serverless-simplicity-with-ec2-flexibility/
はじめにキャパシティプロバイダーを作成します。
※作成時にインフラストラクチャ運用者のロールに「ec2:...」が無くエラーになる場合は、別途追加する必要があります。
続いてLambda関数を作成します。
その他の設定でLambda マネージドインスタンスにキャパシティプロバイダーの選択肢が追加されているので、これを設定します。
関数URLをONにして作成し、通常Lambdaと同じコードをデプロイします。
heyで負荷をかけます。
xxx:~$ $HOME/go/bin/hey -n 50 -c 5 https://{Lambdaマネージドインスタンス関数URL}lambda-url.ap-northeast-1.on.aws/
Summary:
Total: 0.4861 secs
Slowest: 0.2045 secs
Fastest: 0.0199 secs
Average: 0.0461 secs
Requests/sec: 102.8568
Total data: 6207 bytes
Size/request: 124 bytes
Response time histogram:
0.020 [1] |■
0.038 [44] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.057 [0] |
0.075 [0] |
0.094 [0] |
0.112 [0] |
0.131 [0] |
0.149 [0] |
0.168 [0] |
0.186 [1] |■
0.205 [4] |■■■■
Latency distribution:
10%% in 0.0243 secs
25%% in 0.0265 secs
50%% in 0.0297 secs
75%% in 0.0348 secs
90%% in 0.1855 secs
95%% in 0.2039 secs
0%% in 0.0000 secs
Details (average, fastest, slowest):
DNS+dialup: 0.0139 secs, 0.0000 secs, 0.1394 secs
DNS-lookup: 0.0119 secs, 0.0000 secs, 0.1192 secs
req write: 0.0000 secs, 0.0000 secs, 0.0001 secs
resp wait: 0.0320 secs, 0.0196 secs, 0.0653 secs
resp read: 0.0001 secs, 0.0000 secs, 0.0003 secs
Status code distribution:
[200] 50 responses
数値比較
p50は大差なしでしたが、平均値は明らかに後者の方が早いです。p90ではLambda マネージドインスタンスの方が早く、遅いリクエストが出にくいようでした。
| 項目 | Lambda (2GB) | Lambda マネージドインスタンス |
|---|---|---|
| Average | 83.3 ms | 46.1 ms |
| p50 | 27.0 ms | 29.7 ms |
| p90 | 553.0 ms | 185.5 ms |
AWS Lambda マネージドインスタンスを選ぶ理由はあるか
本題のAWS Lambda マネージドインスタンスは冒頭にもある通り、Amazon EC2上でAWS Lambda関数を実行できる機能です。
公式ドキュメントを確認して実際に触ってみましたが、やはりEC2のパワーを借りられるLambdaであり、LambdaとEC2の境界線を揺るがす第三の選択肢というわけではありませんでした。
個人的見解は以下の通りです。
・呼び出し頻度が高い、あるいは処理速度が求められる場合はLambda マネージドインスタンスを選ぶメリットあり
・日中にポツポツと呼ばれるような軽量な処理であれば、従来のLambdaのままでも良い
「既存のLambdaでは性能面に不満があるが、EC2を運用するほどでもない」という状況があるなら、採用を考えても良いのだと思います。
おまけ：無料プランだとLambda マネージドインスタンスが使えない可能性がある
2026/02/14現在、無料プランだと下記のエラーが発生し、Lambda マネージドインスタンスを設定したLambda関数を新規作成できませんでした。
作成に失敗したものについて、CloudTrailのイベントレコードに以下の記載がありました。
"errorMessage": "The specified instance type is not eligible for Free Tier. For a list of Free Tier instance types, run 'describe-instance-types' with the filter 'free-tier-eligible=true'.",
（省略）
"instanceType": "m7i.xlarge",
Lambdaマネージドインスタンスは作成時に2GB以上のメモリを選択しなければならず、それを見てAWS側がm7i.xlargeを提供しようとしているようです。
これは無料プランでは選べないインスタンスなのでエラーになってしまいます。潔く有料プランへアップグレードして課金するしかありません。