AWS Lambda Managed Instances の「メモリ割り当て/vCPU 比率」のパターンにより起動するインスタンスタイプを確認してみた
こんにちは、製造ビジネステクノロジー部の若槻です。
AWS Lambda Managed Instances (LMI) では、スケーリング動作を制御する要素として以下の関数設定があります。
- メモリ割り当て (Memory size)
- 設定可能範囲:
2GB ～32GB
- 設定可能範囲:
- メモリ対 vCPU の比率 (Execution environment memory (GiB) per vCPU ratio)
- 設定可能値:
2:1、4:1、8:1
- 設定可能値:
マネジメントコンソール上だと次の箇所の設定になります。
これらをアプリケーションのメモリや CPU の利用特性に応じてカスタマイズすることで、効率的なインスタンス利用が可能となります。加えて、構成最小化を目指すことで、開発・検証環境におけるコスト削減も期待できます。
ということで、LMI で「メモリ割り当て/vCPU 比率」のパターンにより起動するインスタンスタイプを確認してみました。
前提
- リージョン: 東京リージョン (
ap-northeast-1) - インスタンスタイプの指定: なし（AWS 側で自動選定）
- アーキテクチャ: X86
確認してみた
リソースの作成には AWS CDK を使用しました。
VPC は予め作成したものを使用します。
VPC 定義コード
import * as ec2 from "aws-cdk-lib/aws-ec2";
import { Construct } from "constructs";
/**
* VPC 実装
*
* MEMO: VPC から各種 AWS サービスへのネットワーク経路確保のために NAT Gateway を配置する
*/
export class VpcConstruct extends Construct {
public readonly vpc: ec2.Vpc;
constructor(scope: Construct, id: string) {
super(scope, id);
this.vpc = new ec2.Vpc(this, "Default", {
subnetConfiguration: [
/**
* NAT Gateway を配置するためのパブリックサブネット
*/
{
name: "Public",
subnetType: ec2.SubnetType.PUBLIC,
},
/**
* Lambda 関数を配置するためのプライベートサブネット
*/
{
name: "PrivateWithEgress",
subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
},
],
});
}
}
デフォルト設定
そもそもデフォルトの設定はどうなっているのでしょう？AWS CDK で LMI 用の Capacity Provider および Lambda 関数をデフォルト値で作成してみます。
LMI 作成定義コード
import * as cdk from "aws-cdk-lib";
import * as ec2 from "aws-cdk-lib/aws-ec2";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as lambda_nodejs from "aws-cdk-lib/aws-lambda-nodejs";
import { Construct } from "constructs";
import { VpcConstruct } from "./constructs/vpc";
export class SampleStack extends cdk.Stack {
constructor(scope: Construct, id: string, props: cdk.StackProps) {
super(scope, id, props);
/**
* VPC 作成
*/
const vpcConstruct = new VpcConstruct(this, "Vpc");
const vpc = vpcConstruct.vpc;
/**
* セキュリティグループ作成
*/
const securityGroup = new ec2.SecurityGroup(this, "SecurityGroup", {
vpc,
});
/**
* Capacity Provider 作成
*/
const capacityProvider = new lambda.CapacityProvider(
this,
"CapacityProvider",
{
subnets: vpc.selectSubnets({
subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
}).subnets,
securityGroups: [securityGroup],
},
);
/**
* LMI 用 Lambda 関数作成
*/
const lmiFunction = new lambda_nodejs.NodejsFunction(this, "LmiFunction", {
entry: "src/handler.ts",
runtime: lambda.Runtime.NODEJS_24_X, // LMI では Node.js 22.x 以上が必須
});
/**
* Capacity Provider に Lambda 関数を追加
*/
capacityProvider.addFunction(lmiFunction);
}
}
作成された関数は下記の設定となりました。
- メモリ割り当て:
2GB - メモリ対 vCPU の比率:
2:1
メモリ割り当て値は basic settings 側からも確認できます。（変更はこちら側しか行えない点に注意）
ドキュメントによると、サポートされる最小の関数サイズは 2GB と 1vCPU になるので、デフォルトで最小構成になるようですね。
Choose the memory size and vCPU allocation for your function. The smallest supported function size is 2GB and 1vCPU.
起動したインスタンスは次のようになりました。
- インスタンスタイプ:
m7a.large(2 vCPU、8 GB メモリ) - インスタンス台数:
3
メモリ割り当てを増やした場合（3GB）
下記の設定で関数を作成します。
- メモリ割り当て:
3GB - メモリ対 vCPU の比率:
2:1
/**
* LMI 用 Lambda 関数作成
*/
const lmiFunction = new lambda_nodejs.NodejsFunction(this, "LmiFunction", {
entry: "src/handler.ts",
runtime: lambda.Runtime.NODEJS_24_X, // LMI では Node.js 22.x 以上が必須
memorySize: 3072, // メモリ割り当てをデフォルト 2 GB から 3 GB に増やす
});
/**
* Capacity Provider に Lambda 関数を追加
*/
capacityProvider.addFunction(lmiFunction);
デプロイ後、関数の設定は下記の通りとなりました。期待通りの設定です。
起動したインスタンスは次のようになりました。
- インスタンスタイプ:
c7a.2xlarge(8 vCPU、16 GB メモリ) - インスタンス台数:
3
メモリ割り当てを増やした場合（4GB）
下記の設定で関数を作成します。
- メモリ割り当て:
4GB - メモリ対 vCPU の比率:
2:1
/**
* LMI 用 Lambda 関数作成
*/
const lmiFunction = new lambda_nodejs.NodejsFunction(this, "LmiFunction", {
entry: "src/handler.ts",
runtime: lambda.Runtime.NODEJS_24_X, // LMI では Node.js 22.x 以上が必須
memorySize: 4096, // メモリ割り当てをデフォルト 2 GB から 4 GB に増やす
});
/**
* Capacity Provider に Lambda 関数を追加
*/
capacityProvider.addFunction(lmiFunction);
デプロイ後、関数の設定は下記の通りとなりました。期待通りの設定です。
起動したインスタンスは次のようになりました。
- インスタンスタイプ:
c7a.2xlarge(8 vCPU、16 GB メモリ) - インスタンス台数:
3
インスタンス台数が始めは 4 台になっていましたが、しばらくすると 3 台に落ち着きました。実行環境も同様に 4 から 3 に落ち着きました。
vCPU 比率を減らした場合（4:1）
下記の設定で関数を作成します。
- メモリ割り当て:
4GB - メモリ対 vCPU の比率:
4:1
/**
* LMI 用 Lambda 関数作成
*/
const lmiFunction = new lambda_nodejs.NodejsFunction(
this,
"LmiFunction",
{
entry: "src/handler.ts",
runtime: lambda.Runtime.NODEJS_24_X, // LMI では Node.js 22.x 以上が必須
memorySize: 4096, // メモリ割り当てをデフォルト 2 GB から 4 GB に増やす
},
);
/**
* Capacity Provider に Lambda 関数を追加
*/
capacityProvider.addFunction(lmiFunction, {
executionEnvironmentMemoryGiBPerVCpu: 4, // vCPU あたり 4 GiB メモリ
});
デプロイ後、関数の設定は下記の通りとなりました。期待通りの設定です。
起動したインスタンスは次のようになりました。
- インスタンスタイプ:
m7a.xlarge(4 vCPU、8 GB メモリ) - インスタンス台数:
3
トラブルシュート
下記のパターンで vCPU 比率をカスタマイズしようとしました。
- メモリ割り当て:
2GB - メモリ対 vCPU の比率:
8:1
するとデプロイ時に下記エラーが発生しました。
Memory ratio of 8192.0MB per CPU exceeds function's total memory of 2048MB. Supported memory-to-CPU ratios are 2GB, 4GB, or 8GB per CPU.
vCPU を 1 以下にできないため、vCPU 比率が 8:1 の場合はメモリ割り当てを最低でも 8 GB にする必要があるようです。
まとめ
ここまでの確認結果をまとめると、下記の通りとなりました。
| メモリ割り当て | メモリ対 vCPU の比率 | インスタンスタイプ | インスタンス時間単価（東京リージョン） |
|---|---|---|---|
2 GB |
2:1 |
m7a.large (2 vCPU、8 GB) | $0.022455 |
3 GB |
2:1 |
c7a.2xlarge (8 vCPU、16 GB) | $0.07752 |
4 GB |
2:1 |
c7a.2xlarge (8 vCPU、16 GB) | $0.07752 |
4 GB |
4:1 |
m7a.xlarge (4 vCPU、8 GB) | $0.044925 |
またインスタンス台数はいずれのパターンでも 3 台でした。
本検証により次のような知見が得られました。
得られた知見
-
デフォルト設定（2GB、2:1）が最もコスト効率が良い
- インスタンスタイプ: m7a.large
- 時間単価: $0.022455
- ただし、m6a.large など LMI がサポートする X86 最安のインスタンスタイプは自動で選定されない模様
- 第 4 世代 Gen AMD EPYC プロセッサが優先される？
- インスタンスタイプ: m7a.large
-
メモリ割り当てはコストに大きく影響する
- 2GB → 3GB でコストが 約3.5倍に増加
- 3GB と 4GB では同じインスタンスタイプのため、4GB の方が割安
- 3GB など、2進数以外のメモリ割り当ては避けるべき
-
vCPU 比率の調整でコスト最適化が可能
- 同じ 4GB のメモリ割り当てでも：
- 2:1 → c7a.2xlarge（$0.07752）
- 4:1 → m7a.xlarge（$0.044925、約42%削減）
- 同じ 4GB のメモリ割り当てでも：
-
インスタンス台数は自動管理される
- いずれのパターンでも 3 台で固定されており、設定による制御はできない
- パターンの違いによるリソース調整は、スケールアウト/インではなく、スケールアップ/ダウンで対応している模様
推奨される設定方針
上記知見をまとめると、以下のような設定方針が推奨されることが分かります。
| ユースケース | 推奨設定 | 理由 |
|---|---|---|
| コスト重視・軽量ワークロード | 2GB、2:1（デフォルト） | 最小コストで運用可能 |
| メモリ必要・CPU 軽量 | 4GB 以上、4:1 または 8:1 | 無駄な vCPU を削減してコスト効率化 |
| CPU 重視のワークロード | 必要メモリ、2:1 | より多くの vCPU を確保 |
結論
アプリケーションの特性に応じて vCPU 比率を適切に調整することで大幅なコスト削減が可能です。特にメモリは必要だが CPU 負荷が低いワークロードでは、vCPU 比率を 4:1 や 8:1 に設定することで、効率的なリソース利用とコスト最適化を両立できます。
おわりに
AWS Lambda Managed Instances の「メモリ割り当て/vCPU 比率」のパターンにより起動するインスタンスタイプを確認してみました。
デフォルト設定 (2GB、2:1) が最もコスト効率が良い。CPU 軽量アプリの場合は vCPU 比率の調整でコスト最適化が可能、という結論が得られました。また、当たり前ではありますがメモリよりも vCPU のコスト影響が高いことが分かりました。
定常リクエスト処理などのワークロードにおいて従来 Lambda よりもコスト効率の良い LMI ですが、「メモリ割り当て/vCPU 比率」のパターンを適切に選定することで、さらにコスト最適化が可能となります。ぜひ皆さんのユースケースに合わせて設定を検討してみてください。
参考
インスタンスタイプごとの vCPU とメモリの組み合わせ
LMI オンデマンドインスタンスの価格
以上
