AWS Lambda Managed Instances を試してみた

はじめに

re:Invent真っ最中のリリース。ざっくり、「LambdaをEC2で動かせる」ということらしいですが、これだけだと何がうれしいのかわかりません。上記リリースを読んでわかる普通のLambdaとの違いは：

• 広帯域のネットワーキング
• インスタンスが揮発しないので、共有リソースが長生き
• ワークロードに適切なハードウェアを選べる（GPUが利用できるかはわからない）
• 1つのインスタンスが複数の処理を並行で実行できる（通常のLambdaは1つのインスタンスは同時に1つの処理しかしない）

ユースケースに思いを馳せてみると、（WebAPIとして使ってるとして）コンテナを使っている場合はECSを使えばいいので、それ以外のランタイムで動かしていることが前提となるんだろうと思います。個人的に、Lambdaはコストとインフラのことをあまり考えずともスケールするシンプルさが好きなので、さてManaged Instanceはどうかな…という気持ちです。

ということで検証してみます。なお執筆時点（2025-12-01）ではap-northeast-1には降ってきていなかったのでus-east-1で検証しています。

Capacity Providerを定義

Lambdaを動かすEC2を定義する部分はCapacity Providerと呼ばれます。Lambdaに計算資源を供給するもの、ということでよいでしょう。

設定できる項目：

• ネットワーク（VPC,サブネット、セキュリティグループ）
• Infrastructure operator role（https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-operator-role.html ）
• CPUアーキテクチャ
• インスタンスタイプ（指定しなければ、自動的に適切なものが選ばれるらしい）
• 最大vCPU
• スケーリング設定（自動か、CPU使用率ベースの手動設定）

Infrastructure operator roleを作成する

ドキュメントによれば、AWSLambdaManagedEC2ResourceOperatorなるマネージドポリシーを利用するといいらしい。てきとうに作っておく。

このIAMロールを使うことにして、他はデフォルトっぽい設定で。

作成されたCapacity Provider

Capacity Provider自体をモニタリングできる。

関数を作成する

Capacity ProviderとLambdaでCPUアーキテクチャが違ったら何が起きるんだろうという悪戯心は見ないふりをして、もろもろ設定。なんだかvCPUとRAMの比率を設定できるらしい。この辺の設定ってCapacity Provider側にあってもいい感じがするんだけど、AWSムズカシイ。雑に動作検証するために関数URLを利用。

concurrencyがどんな感じかわかればとsleepと、負荷をかけるためにちょっとCPUを回す処理を入れてみる。

// index.mjs
function heavyCalculation() {
  let sum = 0;
  for (let i = 0; i < 50_000_000; i++) {
    sum += i;
  }
  return sum;
}

function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

export const handler = async (event) => {
  const start = Date.now();

  console.log('Request received:', {
    path: event.rawPath,
    method: event.requestContext?.http?.method,
  });

  const calcResult = heavyCalculation();

  await sleep(2000);

  const end = Date.now();

  const responseBody = {
    message: 'Hello from Lambda Function URL!',
    calcResult,
    elapsedMs: end - start,
  };

  return {
    statusCode: 200,
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(responseBody),
  };
};

k6で負荷検証してみると、この関数だと秒間50リクエストを超えたあたりからエラーが発生するようになった（スロットリングが発生しているようす）。vCPUあたりの同時実行数のチューニングが必要なのだろうか？わからない。

なおこんな感じにCapacity Providerのメトリクスを見ることができる。

ふとEC2を見てみると…

ちょっと気になってEC2を見てみるとー

なんか強いインスタンスが2つ作られている…。これらはそのまま課金されてしまうのか…？こわい…。

Capacity Providerを削除するとー

消えた。つまりCapacity Providerを作るとEC2が自動的に作成される（今回のリリースの中身からしてそれはそう）。

全部デフォルト設定にしてたけど台数やインスタンスタイプが制御できないのは、実際の運用例などでコスト感がわかるまでは怖い感じがする。たぶんそれでもコストメリットが出るような大規模なケースを想定した機能なのではないかと思いました。Lambdaを大規模に動かしていてコストがかかっている場合に、Managed InstanceとSaving Planなどを組み合わせると安くなることがあるのかもしれません。既存のLambdaコードに大きく手を入れなくて済みそうなのもうれしそうです。