LambdaでもGPUが使える？！Lambda Managed Instancesが発表されました
リテールアプリ共創部@大阪の岩田です。
2025/12/1付けのアップデートでLambda Managed Instancesという新機能が発表されました！
すごくざっくり言うとECS Managed Instances のLambda版です。従来Lambdaのコンピューティング環境はユーザーから隠蔽されており、Lambdaのコンピューティング基盤を支えるEC2がどこでどのように動いているかは完全なブラックボックスでした。MicroVM単位では分離されているものの、基盤となるEC2インスタンス上では他のAWSアカウントAのLambda Functionが相乗りしているかもしれないし、AWSアカウントBのLambda Functionが相乗りしているかもしれないという状況でした。
今回登場したLambda Managed Instancesを利用すると、ある程度ユーザー側がEC2の環境を制御できるようになります。
ユーザーは事前作成したEC2インスタンスのフリート上でLambdaを実行可能になり、ワークロードに応じて最適なコンピューティング環境でLambda Functionを実行できるようになります。例えばですが、セキュリティ要件によって専用ハードウェア上での実行が要求されるようなユースケースであってもベアメタルEC2インスタンスのフリートを用意してセキュリティ要件を満たせるようになりました。
また、これまでLambdaではGPUがサポートされていませんでしたが、Lambda Managed Instancesを利用するとGPUをサポートするEC2インスタンス上でLambda Functionを起動できるようになるためLambdaでGPU処理が可能になると思われます。これは未検証のため検証できしだい追記します。
LambdaがGPUをサポートしていないのはLambdaの基盤で利用されているVMM FirecrackerがGPUをサポートしていないことが要因だと思われますが、Lambda Managed Instancesにおいてはセキュリティ境界にFirecrackerを利用していないことがドキュメントに記載されています。自AWSアカウントでEC2インスタンスを占有できるのでFirecrackerのセキュリティ境界は不要ということでしょう。
Lambda (default) compute type is multi-tenant, making use of Firecracker microVM technology to provide isolation between execution environments running on shared Lambda fleets. Lambda Managed Instances run in your account, providing the latest EC2 hardware and pricing options. Managed Instances use containers running on EC2 Nitro instances to provide isolation rather than Firecracker. Capacity providers serve as the security boundary for Lambda functions. Functions execute in containers within instances.
やってみる
さっそくLambda Managed Instancesを試してみましょう。
キャパシティプロバイダー用のIAMロールの作成
Lambda Managed Instancesを利用するにはECSでもおなじみの「キャパシティプロバイダー」が必要です。このキャパシティプロバイダーを作成する際に必要になるので、事前にIAMロールを作成しておきましょう。このIAMロールはlambda.amazonaws.comから引き受けられるよう信頼ポリシーを設定し、アクセス許可にはAWS管理のポリシーAWSLambdaManagedEC2ResourceOperatorをアタッチしておきましょう。これで必要な権限が付与されます。
ちなみにAWSLambdaManagedEC2ResourceOperatorの中身は以下の通りです。キャパシティプロバイダーの定義に沿って必要なEC2インスタンスを起動するための権限が含まれているようです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateTags",
"ec2:AttachNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"StringEquals": {
"ec2:ManagedResourceOperator": "scaler.lambda.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAvailabilityZones",
"ec2:DescribeCapacityReservations",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeInstanceTypes",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:image/*"
],
"Condition": {
"StringEquals": {
"ec2:Owner": "amazon"
}
}
}
]
}
キャパシティプロバイダーの作成
続いてLambda Functionを実行する環境としてキャパシティプロバイダーを作成します。
いつの間にかLambdaのマネコンにキャパシティプロバイダーというメニューが増えていますね。
まず「キャパシティプロバイダー設定」でVPC、サブネット、セキュリティグループを指定し、インフラストラクチャ運用者のロールには先程作成したIAMロールを指定します。
「詳細設定」では細かい指定が可能になっています。今回はインスタンスタイプとしてm5.largeを指定し、他のタイプのインスタンスが起動しないよう設定してみました。インスタンスタイプの設定によってメモリ重視やCPU重視など、ワークロードに応じた調整ができそうですね。
ちなみにドキュメント上はまだ記載が見つけられていないのですが、t3.micro等のインスタンスタイプは指定できなかったので、指定可能なインスタンスタイプにはある程度制限がありそうです。
Lambda Functionの作成
キャパシティプロバイダーが作成できたら、このキャパシティプロバイダー上で実行するLambda Functionを作成します。
見慣れた画面に「コンピューティングタイプ」の選択が増えていますね。キャパシティプロバイダー ARNに先程作成したキャパシティプロバイダーを指定します。
メモリについては通常のLambda Functionとは異なり最低2GBからの指定となっています。さらに Execution environment memory (GiB) per vCPU ratio という項目が存在し、この項目によってメモリサイズに比例したvCPUの割当を調整できるようになっています。メモリサイズが最低2GBなので2:1を指定するとvCPUを1つ利用するという設定になります。
「関数を作成」をクリックすると「関数 xxx を作成中です」と表示され、しばらく待ち状態になります。
これに合わせてEC2のマネコンを表示するとm5.largeのインスタンスが自動起動しているのが分かります。
テスト実行
しばらく待ってEC2インスタンスの起動が完了したらテスト実行してみましょう。
無事に実行できました！
一応ログも確認しておきましょう。CW Logsからログが確認できるのは通常のLambdaと同様ですが、"initializationType": "lambda-managed-instances",となっているのが特徴的ですね。
EC2の情報を確認してみる
一応自動起動したEC2の情報も確認しておきましょう。
オペレーターがscaler.lambda.amazonaws.comとなっていたり、停止保護・終了保護がエラーで表示できないなど普通のEC2インスタンスとは少し毛色が違いますね。
見知らぬAMI IDでしたが、どうもキャパシティプロバイダーが自動的にAMIを作成して管理しているようですね。AMIの一覧を表示するとAWS所有のAMIが増えていました。自分でOSパッケージを導入したEC2のAMIなど利用できると便利そうですが、今のところそういった機能は用意されていないようです。
通常のLambdaとは異なり基盤となるEC2のメトリクスも確認できます。
気になる点としてはEC2にアタッチされたセキュリティグループが確認できませんでした。エラーメッセージによるとsg-0400469354b8d8475というセキュリティグループがアタッチされてそうなのですが、これがAWS管理のセキュリティグループなので見れないとかですかね？
ちなみにSSMは...
接続不可のようです。中身を色々と覗いてみたかったのですが、残念です...
注意点
Lambda Managed Instancesを利用する場合、プログラミングモデルは従来と変わりませんが通常のLambdaと全く同じように扱わないように注意が必要です。詳細はサポートされているランタイム毎にドキュメントに記載されているのですが、/tmpディレクトリが共有される点などは特に注意が必要でしょう。こういった注意点については今後検証してブログにしていきたいと思います。
料金
Lambda Managed Instancesを利用する場合はNWの転送料などを除くと大きく以下の料金が発生します。
- Lambdaリクエスト料金
- 100万リクエストあたり0.20USD ※これは通常のLambdaと変わりません
- キャパシティプロバイダーが起動するEC2の料金
- 当たり前のことですが、キャパシティプロバイダーによって起動されるEC2に対して料金が発生します
- 通常のEC2と同様にリザーブドインスタンスや Savings Plans による値引の恩恵が受けられます
- 15%の管理料金
- EC2のオンデマンド料金の15%に対して管理料金が発生します。Lambda Managed Instancesの裏側ではEC2を利用していますが、ユーザー側ではOSやミドルウェアのパッチ適用といった管理を行わず(と言うか行えません)AWSに管理をお任せする形になります。その管理コストとしてAWSに料金を支払う形になります。
通常のLambdaと比較した場合、実行時間に対しての課金が発生しないのはメリットではありますが、リクエストに対する課金は変わらず発生するのでその点は認識しておきましょう。
AWSとしては各種イベントをトリガーにLambdaをInvokeする部分は変わらないので、当然といえば当然かもしれません。
Lambdaに実行時間に対する課金がネックになるような大規模な環境であれば通常のLambdaと比較してもコストメリットが出せそうですね。コストを理由にLambdaからEC2に移行したものの、EC2の管理に悩まされている...といったユースケースにはLambda Managed Instancesがハマるかもしれません。
まとめ
Lambda Managed Instancesに関してまずは速報です。
これから色々検証していきたいと思います。
