Lambda Managed Instances が最大32GB/16vCPUに対応 ― メモリ:vCPU比の選択肢とファイルディスクリプタ4倍増を検証

AWSAWS LambdaLambda Managed Instancesサーバーレスコンピュート
AWS Lambda supports up to 32 GB of memory and 16 vCPUs for Lambda Managed Instances - AWS Discover more about what aws.amazon.com
Lambda Managed Instances - AWS Lambda Run Lambda functions on Amazon EC2 instances with automatic provisioning, scaling, and management wh... docs.aws.amazon.com
Introducing AWS Lambda Managed Instances: Serverless simplicity with EC2 flexibility | Amazon Web Services Run Lambda functions on EC2 compute while maintaining serverless simplicity—enabling access to speci... aws.amazon.com
Lambda Managed Instances Learn about the AWS Lambda Managed Instances that extends Lambda aws.amazon.com

AWS Lambda Managed Instances で、関数に割り当てられるリソースが最大32GBメモリ / 16vCPUまで拡張されました（2026年3月27日 AWS What’s New）。あわせて、メモリとvCPUの比率を 2:1、4:1、8:1 の3パターンから選べるようになっています。

従来のLambda（デフォルト）は最大10GBメモリ / 約6vCPUで、メモリ:vCPU比を選ぶことはできませんでした。この32GB / 16vCPUへの拡張は Lambda Managed Instances 専用で、従来のLambda（デフォルト）の上限は引き続き10GB / 約6vCPUのままです。Managed Instances を利用することで、ワークロードの特性に合わせてCPU寄り・メモリ寄りの構成を使い分けられるようになります。これは面白いですね。

さらに同時期に、Lambda Managed Instances のファイルディスクリプタ上限も 1,024 → 4,096 に4倍引き上げられています。マルチコンカレンシーで複数リクエストを同時処理する環境では、このあたりがボトルネックになりがちなので嬉しいアップデートです。

Lambda Managed Instances のおさらい

本題に入る前に、Lambda Managed Instances について簡単に振り返っておきます。

Lambda Managed Instances は2025年11月30日の re:Invent で発表されたLambdaの新しい実行形態です（2025年11月30日 AWS News Blog）。通常のLambdaがFirecracker microVM上で動作するのに対して、Managed InstancesではAWSが管理するEC2インスタンス上でLambda関数が実行されます。

従来のLambdaとの主な違いをまとめると以下のとおりです。

Lambda（デフォルト）Lambda Managed Instances
実行基盤Firecracker microVM（マルチテナント）EC2 Nitroインスタンス（自アカウント）
コンカレンシー1実行環境 = 1リクエスト1実行環境 = 複数リクエスト同時処理
コールドスタートあり事前プロビジョニングにより排除
スケーリングゼロからスケールCPU使用率ベースの非同期スケーリング（最低3インスタンス）
料金モデルリクエスト数 + 実行時間課金リクエスト数 + EC2インスタンス料金 + 管理費15%
EC2割引不可Compute Savings Plans / Reserved Instances 適用可

ポイントは、Lambdaのプログラミングモデルはそのままに、EC2の柔軟なインスタンスタイプやコスト最適化の恩恵を受けられるところです。インスタンスのライフサイクル管理、OSパッチ、ロードバランシング、オートスケーリングはすべてAWSが面倒を見てくれます。

今回のアップデート：メモリとvCPUの大幅拡張

何が変わったのか

公式のアナウンスには以下のように書かれています（AWS What’s New）。

AWS Lambda now supports up to 32 GB of memory and 16 vCPUs for functions running on Lambda Managed Instances, enabling customers to run compute-intensive workloads such as large-scale data processing, media transcoding, and scientific simulations without managing any infrastructure. Customers can also configure the memory-to-vCPU ratio — 2:1, 4:1, or 8:1 — to match the resource profile of their workload.

つまり、Lambda Managed Instances 上で動作する関数に限り、最大32GBメモリ/16vCPUが利用可能になり、メモリ:vCPU比を3パターンから選べるようになったということです。従来のLambda（デフォルト）は今回のアップデートの対象外で、上限は変わっていません。

両者の上限を比較します。

Lambda（デフォルト）Lambda Managed Instances
メモリ上限10,240 MB（約10GB）※変更なし32,768 MB（32GB）
vCPU上限約6 vCPU ※変更なし16 vCPU
メモリ:vCPU比固定（選択不可）2:1 / 4:1 / 8:1 から選択
ファイルディスクリプタ上限1,0244,096

メモリ:vCPU比の具体的な組み合わせ

32GBメモリを例にとると、vCPU比の選択によって以下のように構成が変わります。

メモリ:vCPU比32GBメモリ時のvCPU数向いているワークロード
2:116 vCPUCPU集約型（データ処理、科学計算、メディアトランスコーディング）
4:18 vCPUバランス型（Webバックエンド、一般的なバッチ処理）
8:14 vCPUメモリ集約型（大規模データセットのインメモリ処理、キャッシュ）

自分がまず気になったのは、ML推論のワークロードでこれがどう活きるかです。例えば SageMaker を使うほどではない軽量な推論（ONNXランタイムでの推論など）であれば、16vCPUを活用してCPU推論のスループットを上げる、という選択肢が現実的になります。32GBあればそこそこのサイズのモデルをメモリに載せることもできますし、期待が持てます。

CLIパラメータの構造を確認してみる

検証環境

  • AWS CLI: aws-cli/2.34.8
  • リージョン: ap-northeast-1（東京）

Capacity Provider の作成

Lambda Managed Instances を使うには、まず Capacity Provider を作成する必要があります。Capacity Provider は、Lambda関数が動作するEC2インスタンス群の設定を管理するリソースです。

aws lambda create-capacity-provider コマンドのJSON構造を確認してみます。

{
    "CapacityProviderName": "my-capacity-provider",
    "VpcConfig": {
        "SubnetIds": ["subnet-xxxxxxxxxxxxxxxxx"],
        "SecurityGroupIds": ["sg-xxxxxxxxxxxxxxxxx"]
    },
    "PermissionsConfig": {
        "CapacityProviderOperatorRoleArn": "arn:aws:iam::123456789012:role/LambdaCapacityProviderRole"
    },
    "InstanceRequirements": {
        "Architectures": ["arm64"],
        "AllowedInstanceTypes": ["c8g.xlarge", "c8g.2xlarge"],
        "ExcludedInstanceTypes": []
    },
    "CapacityProviderScalingConfig": {
        "MaxVCpuCount": 64,
        "ScalingMode": "Auto",
        "ScalingPolicies": [
            {
                "PredefinedMetricType": "LambdaCapacityProviderAverageCPUUtilization",
                "TargetValue": 70.0
            }
        ]
    }
}

VPC設定、IAMロール、インスタンスタイプの指定、スケーリング設定が必要です。InstanceRequirements で arm64（Graviton）を指定すれば、コスト効率の良いGraviton4インスタンスを利用できます。AllowedInstanceTypes を省略した場合は、Lambdaが最適なインスタンスタイプを自動選択するとのことです。

Lambda関数へのCapacity Provider割り当てとメモリ:vCPU比の設定

今回のアップデートの核心は、create-function（または update-function-configuration）の CapacityProviderConfig パラメータです。

{
    "CapacityProviderConfig": {
        "LambdaManagedInstancesCapacityProviderConfig": {
            "CapacityProviderArn": "arn:aws:lambda:ap-northeast-1:123456789012:capacity-provider:my-capacity-provider",
            "PerExecutionEnvironmentMaxConcurrency": 100,
            "ExecutionEnvironmentMemoryGiBPerVCpu": 2.0
        }
    }
}

ExecutionEnvironmentMemoryGiBPerVCpu が今回追加されたパラメータで、メモリ:vCPU比を指定します。

パラメータ値意味例（メモリ32GB指定時）
2.0メモリ2GB あたり 1vCPU16 vCPU
4.0メモリ4GB あたり 1vCPU8 vCPU
8.0メモリ8GB あたり 1vCPU4 vCPU

CLIヘルプによると、このパラメータの制約は min: 2.0、max: 8.0 です。つまり、2.0〜8.0の範囲で指定できます。What’s Newでは2:1、4:1、8:1の3パターンが紹介されていますが、CLI上は浮動小数点で指定できるため、例えば 3.0 のような中間値も指定可能かもしれません（この点は公式ドキュメントに明記されていないため、実際に試してみないと分かりません）。

PerExecutionEnvironmentMaxConcurrency は、1つの実行環境が同時に処理できるリクエストの最大数です。max: 1600まで設定でき、マルチコンカレンシーの恩恵を受けるための重要なパラメータです。

既存のCapacity Providerの確認

自分の環境でCapacity Providerの一覧を確認してみました。

aws lambda list-capacity-providers --profile your-profile
{
    "CapacityProviders": []
}

まだ作成していないので空です。実際にCapacity Providerを作成するとEC2インスタンスが起動し最低3台のインスタンスが常時稼働する形になるため、検証コストを考慮して今回はパラメータ構造の確認にとどめました。

ファイルディスクリプタ上限の4倍増

同時期に発表されたもう一つの重要なアップデートが、ファイルディスクリプタ上限の引き上げです。

通常のLambdaではファイルディスクリプタの上限が 1,024 ですが、Lambda Managed Instances では 4,096 に引き上げられました。

これが嬉しいのは、Lambda Managed Instances がマルチコンカレンシー（1つの実行環境で複数リクエストを同時処理）をサポートしているからです。同時に多くのリクエストを処理するとファイルディスクリプタの消費が一気に増えます。データベースコネクションプール、HTTP接続、ファイルI/Oなど、1リクエストあたり数個〜十数個のファイルディスクリプタを使うことは珍しくありません。

PerExecutionEnvironmentMaxConcurrency を高く設定してマルチコンカレンシーを活用する場合、1,024という上限はすぐに使い切ってしまう可能性がありました。4,096に引き上げられたことで、I/O集約型のワークロードでもより安心して運用できるようになります。

料金モデル

Lambda Managed Instances の料金は3つの要素で構成されています。

  1. リクエスト料金: $0.20 / 100万リクエスト（通常のLambdaと同じ）
  2. EC2インスタンス料金: プロビジョニングされたインスタンスのEC2オンデマンド料金
  3. コンピュート管理費: EC2オンデマンド価格の 15%（AWSによるインスタンス管理のプレミアム）

通常のLambdaとの大きな違いは、実行時間ごとの課金がない点です。代わりにEC2インスタンスの稼働時間に対して課金されます。

このため、リクエストが安定的に流れ続けるワークロードでは、マルチコンカレンシーによる効率化 + Compute Savings Plans / Reserved Instances の適用（最大72%割引）で、通常のLambdaより大幅にコストを下げられる可能性があります。SmugMug/Flickr が Graviton4 + Compute Savings Plans で最大80%のコスト削減を達成した事例も報告されています（AWS Lambda Managed Instances 製品ページ）。

一方で、最低3インスタンスが常時稼働するため、トラフィックが少ない時間帯にもコストが発生します。バースト的なワークロードや低頻度の処理には、従来のLambda（デフォルト）の方が適していると思います。

Terraformの対応状況

Terraform AWS Provider でも Lambda Managed Instances はすでにサポートされています。

  • v6.24.0（2025年12月2日）: aws_lambda_capacity_provider リソース追加、aws_lambda_function に capacity_provider_config 引数を追加（#45342）
  • v6.29.0（2026年1月28日）: aws_lambda_function の memory_size 上限を 10,240MB → 32,768MB に引き上げ（#46065）

IaCで管理したい場合もすでに対応済みなのはありがたいです。

利用可能なリージョン

Lambda Managed Instances は現在、以下のリージョンで利用可能です。

  • US East (N. Virginia)
  • US East (Ohio)
  • US West (Oregon)
  • Asia Pacific (Tokyo)
  • Europe (Ireland)

東京リージョン（ap-northeast-1）が含まれているので、国内のワークロードでもすぐに試すことができます。最新のリージョン対応状況は AWS Capabilities by Region で確認できます。

まとめ

Lambda Managed Instances のメモリ/vCPU拡張は、Lambdaで扱えるワークロードの幅を大きく広げるアップデートだと感じています。

特に自分が注目しているのは以下の点です。

  • メモリ:vCPU比の選択: ワークロードの特性に合わせてCPU集約型・メモリ集約型を使い分けられるのは、EC2でインスタンスファミリーを選ぶ感覚に近いです。Lambdaのサーバーレスな運用モデルのまま、この柔軟性が得られるのは大きいと思います
  • 32GB / 16vCPU: ML推論やデータ処理パイプラインをLambdaで完結させるハードルがかなり下がりました。SageMakerエンドポイントを立てるまでもない軽量〜中量の推論ワークロードには、良い選択肢になりそうです
  • ファイルディスクリプタ4倍増: マルチコンカレンシーを前提とした改善で、地味ですが実運用では効いてくるはずです

Lambda Managed Instances 自体が2025年11月に登場したばかりの新しい機能ですが、着実に強化が進んでいます。今後もインスタンスタイプの追加やリージョン拡大が期待されるので、引き続き動向を追っていきたいと思います。