AWS Lambda Managed Instances 本番運用ガイド｜EC2実行モデルとコスト最適化

1. この記事について

1-1. 本記事のゴール

本記事を読み終える頃には、Lambda Managed Instancesがなぜ「永続EC2インスタンス上でLambda関数を実行する」という新しい実行モデルなのか、それが標準Lambdaのリクエスト単位分離モデルやProvisioned Concurrencyの事前ウォームモデルとどう違うのかを、仕組みのレベルで理解できる状態になります。具体的には、1つの実行環境が複数リクエストを継続的に処理する挙動、AWSがinstance lifecycle・OSパッチ・load balancing・auto-scalingを丸ごと管理する運用モデル、そしてリクエスト課金 + EC2インスタンス料金 + 管理手数料という3要素で構成される課金モデルを、Terraformによるインフラ定義とあわせて手を動かしながら習得します。

さらに、Managed Instancesは既存の標準Lambda・Provisioned Concurrencyと機能的に重複する部分があるため、コスト構造・実行環境の性質・専用ハードウェアの有無・運用管理の分担という観点から3モデルを比較し、自分のワークロードにどのモデルが適しているかを根拠を持って判断できる設計力を養うことをゴールとします。読了後は、Compute Savings PlansやReserved Instancesによる最大72%のコミット割引を、どのワークロードに適用すべきかもコストと運用負荷の両面から自力で判断できるようになります。

本記事で習得するスキルは、大きく次の4つに整理できます。

• 実行モデルの理解: 永続EC2インスタンス上でLambda関数が動作する仕組みと、標準Lambda・Provisioned Concurrencyとの構造的な違い
• 課金モデルの試算: リクエスト課金 ($0.20/100万リクエスト) + EC2インスタンス料金 + 管理手数料 (オンデマンド価格の15%) の3要素をもとにした本番コスト試算
• Capacity Provider設計: VPC/subnet/SG・インスタンスタイプ包含除外・最大vCPU・auto-scalingを含むCapacity ProviderのTerraform実装
• 使い分け判断: 標準Lambda/Provisioned Concurrency/Managed Instancesの3モデルから、定常・高トラフィック・専用ハードウェア要件の有無に応じて最適なモデルを選ぶ判断基準

これら4点を、Terraformでのインフラ定義・課金モデルの試算・使い分け判断基準の整理という3ステップで一通り体験し、本番投入の判断材料を持ち帰れる内容を目指します。

本記事の構成は、§2で前提環境と課金モデルの基本を整理したうえで、§3でManaged Instancesの実行モデルそのものを掘り下げ、§4でCapacity ProviderのTerraform実装、§5でコスト最適化と使い分け判断という順に進みます。§6では低頻度ワークロードへの誤適用やauto-scaling設計ミスといった詰まりポイントを、§7では既存のLambda関連記事へのクロスリンクを含むまとめを扱います。

標準Lambda・Provisioned Concurrency・Managed Instancesの位置づけを概観すると、以下の通りです (詳細な選択基準は §5 で解説します)。

なお、Capacity Providerの構築はCloudFormation・SAM・CDK・Terraformのいずれにも対応しています。本記事では既存のServerless本番運用シリーズ・Compute本番運用シリーズと構成を揃える目的でTerraformを採用しますが、既にCDKやSAMでLambdaを運用しているチームでも、Capacity Providerの設定項目自体は共通のため、そのままTerraformの記述をご自身のIaCツールに読み替えて適用できます。

なお、本記事が扱う範囲は以下の通りに限定します。

• SnapStart・Container image・Durable Functionsといった「関数レベル」の最適化・実装パターンは既存記事で解説済みのため、本記事では再掲せずクロスリンク委譲します
• EC2/Gravitonのインスタンスファミリー自体の基礎知識、Compute Savings Plans/Reserved Instancesの購入戦略そのものは既存記事 (Compute本番運用シリーズ/Cost最適化シリーズ) に委譲し、本記事ではManaged Instances固有の設定に絞って解説します
• 対応インスタンスファミリーの詳細な世代比較や、container image/zipパッケージ形式ごとの対応可否の網羅的な検証は範囲外とし、本番運用開始時点で判断が必要な範囲に絞ります

なお本記事は、標準LambdaおよびTerraformでのLambda運用経験を前提にはしていますが、SnapStart・Container image・Durable Functionsの各記事を未読でもManaged Instances単体の実装・使い分け判断は理解できるよう構成しています。関数レベルの最適化まで深掘りしたい場合は、あわせてそれぞれの記事を参照してください。

1-2. 読者像

本記事の主な読者は、すでにLambdaを本番環境で運用しており、高トラフィックや定常的なワークロードにおける実行時間課金のコスト、あるいは専用ハードウェア (Graviton4等) を活用したいという要求に課題を感じているサーバーレス開発者・SREです。標準Lambdaの運用簡素性には価値を感じつつも、EC2インスタンスを直接管理するほどの複雑さは避けたい、しかしコミット割引による大幅なコスト削減は取り込みたいという層を想定しています。

また、Provisioned Concurrencyを導入してコールドスタート対策を行っているものの、維持コストと実行時間課金の両方がかさみ、より効率的な課金モデルを模索しているチームにも有用です。TerraformでLambda関数やVPCリソースをIaC管理した経験があり、EC2のインスタンスタイプやCapacity Provider (ECSの文脈で) の概念に馴染みがある読者を前提とします。

具体的には、以下のような課題意識を持つ読者に特に役立ちます。

• 高トラフィック・定常ワークロードでLambdaの実行時間課金が積み上がり、EC2への移行も検討したが運用の複雑さがネックになっている
• Provisioned Concurrencyの維持コストと実行時間課金の二重負担に課題を感じている
• Graviton4等の専用ハードウェアをLambdaのサーバーレス運用モデルのまま活用したい
• 新しいAWSサービスをすぐに採用するのではなく、既存の標準Lambda/Provisioned Concurrency運用からの移行コストとメリットを定量的に比較してから判断したい

本記事の想定読者像を整理すると、以下の通りです。

一方で、Lambdaを初めて触る読者、あるいは低頻度・バースト性の高いワークロードしか扱わない読者には、本記事の内容はオーバースペックです。低頻度ワークロードではManaged Instancesの常時起動コストが標準Lambdaを上回るケースが多く、まずは標準Lambdaでの運用を固めてから本記事に戻ることを推奨します。

想定読者の多くは、現時点で以下のようなアーキテクチャを本番運用している段階にあると考えられます。

• 標準Lambdaで高トラフィックAPIを運用しており、実行時間課金の総額がEC2ベースの構成を上回り始めている構成
• Provisioned Concurrencyでコールドスタート対策済みだが、維持コストが継続的に発生している構成
• コンテナ (ECS/EKS) でも同様のワークロードを運用しており、LambdaとEC2/コンテナのどちらを主軸にすべきか判断がつかない構成

こうした構成をすでに運用している読者であれば、本記事の実装例をそのまま自身の環境に適用しやすいはずです。逆に、まだLambdaのコスト構造を意識したことがない、あるいはワークロードが低頻度・バースト性中心という段階であれば、Managed Instancesの導入判断そのものは不要なケースが多いため、本記事は一旦読み飛ばして差し支えありません。

1-3. なぜ今これを書くか

AWS Lambda Managed Instancesは2025年11月、re:Invent 2025のタイミングでGAしました。提供リージョンはUS East (N. Virginia/Ohio)・US West (Oregon)・Asia Pacific (Tokyo)・Europe (Ireland) の4リージョンで、東京 (ap-northeast-1) が含まれているため、日本のプロダクション環境でも即座に採用検討できる状態です。これにより、標準Lambdaのサーバーレス運用簡素性とEC2の専用ハードウェア・コミット割引という、これまで二者択一だった選択肢の中間を埋める新モデルが加わりました。

Managed Instancesの概要とリージョン展開は以下の通りです。

課金3要素のうち、実行時間 (duration) に応じた課金が発生しない点は標準Lambdaとの大きな違いです。標準Lambdaは実行時間 × メモリ設定に応じて課金される一方、Managed Instancesは起動しているEC2インスタンス自体に課金されるため、リクエスト処理時間の長短がコストに直接影響しません。処理時間が長く、かつ高頻度に呼び出されるワークロードほど、この課金モデルの違いがコストメリットとして表れやすくなります。

既存のLambda関連記事はSnapStart (コールドスタート最適化)・Container image (パッケージング)・Durable Functions (steps/waitsによるワークフロー制御) を扱ってきましたが、いずれも「関数レベル」の挙動を最適化する記事であり、Managed Instancesが扱う「実行基盤 (compute substrate) と課金モデル」というインフラ層は、これらのどの記事でも一切カバーしていない完全な空白領域でした。標準Lambda/Provisioned Concurrencyとの使い分けに迷う読者が今後増えることを見越し、GAから日が浅い今のタイミングで本番運用の観点から先取りして解説する意義があると判断しました。

AWSの公式発表では、Managed Instancesは「サーバーレスの簡素性とEC2の柔軟性を両立する」機能と位置づけられています。永続EC2インスタンスであればinstance lifecycle・OSパッチ・load balancing・auto-scalingをAWSが管理しつつ、専用ハードウェア (Graviton4等) を選択でき、さらにEC2のコミット割引プログラムをそのまま適用できるため、高トラフィック・定常ワークロードを持つチームにとってはコスト構造そのものを変える可能性があります。この「サーバーレスの運用簡素性を保ったままEC2のコスト構造を得られる」という組み合わせこそが、GA直後の今このタイミングで本番運用ノウハウを整理しておく価値だと考えています。

具体的には、既存のLambda関数をそのままCapacity Providerに紐付けるだけで導入でき、EC2インスタンスをコンソールやTerraformで直接プロビジョニングしたり、load balancerやauto-scaling groupを自前で設計したりする必要がありません。この「既存のLambda関数への追加設定」という導入形態の軽さが、EC2への移行を躊躇していたチームにとっての現実的な選択肢になり得ると考え、本記事のテーマとして取り上げました。

これまで高トラフィック・定常ワークロードのコスト最適化を検討するチームには、Lambdaの運用簡素性を捨ててEC2/ECS/Fargateへ移行するか、コストを許容して標準Lambdaのまま運用を続けるかという二択が実質的な選択肢でした。移行にはload balancer・auto-scaling group・OSパッチ運用といった新たな責務が伴うため、チームの運用負荷が増える判断は簡単には下せません。Managed Instancesは、この移行判断そのものを不要にする位置づけとして登場しており、既存のLambdaベースの開発フローとデプロイパイプラインを変えずにEC2のコスト構造だけを取り込める点が、他の選択肢と一線を画す部分です。本記事では、この位置づけを踏まえたうえで、実際にCapacity Providerを構築しながらコスト試算までを一気通貫で解説します。

Compute Savings Plans の基礎はこちら

2. 前提・環境・準備

2-1. 前提環境

本記事を実践するにあたって、以下の環境・知識を前提とします。

AWS 環境前提

• AWS アカウント (Lambda・EC2・IAM・VPC の操作権限を持つロール、または Administrator)
• Managed Instances 対応リージョンのいずれか (US East (N. Virginia / Ohio)・US West (Oregon)・Asia Pacific (Tokyo)・Europe (Ireland))。本記事のサンプルは ap-northeast-1 (東京) での動作を前提に記述します
• 既存の VPC と、複数 AZ にまたがるサブネット (Capacity Provider の VpcConfig はサブネットを最低 1 つ・最大 16 個まで指定でき、可用性のため複数 AZ のサブネット指定が推奨されます)
• セキュリティグループ (未指定の場合は VPC のデフォルト SG が適用されます)
• Capacity Provider が EC2 リソースを管理するための IAM ロール (CapacityProviderOperatorRoleArn)

ローカル開発環境確認

なお、標準 Lambda および Provisioned Concurrency の運用経験、Terraform での VPC・セキュリティグループ・IAM ロール管理経験は §1 で述べた通り前提とします。Managed Instances 固有の設定である Capacity Provider の作成権限 (lambda:CreateCapacityProvider 等) が付与されたロールを事前に用意しておくと、§4 のハンズオンにそのまま進められます。

既存 Lambda 関数への適用について

Managed Instances は、既存の標準 Lambda 関数のコードをそのまま流用できます。関数ロジック自体に変更は不要で、新しい関数バージョンを発行し、そのバージョンに Capacity Provider を紐付けるだけで Managed Instances 実行環境に切り替えられます。ただし、以下の点は事前に確認しておく必要があります。

• ハンドラーコードが multi-concurrency (1 実行環境で複数リクエストを並行処理) を前提とした設計になっているか (グローバル変数やコネクションの共有方法に注意。詳細は §3 で扱います)
• 関数のメモリ設定を Managed Instances の下限である 2GB 以上に引き上げる必要があるか
• 既存のタイムアウト前提のロジックが、後述する「タイムアウト後も処理が継続する」という Managed Instances 特有の挙動と衝突しないか (§3 で詳述)

本記事のハンズオンでは、新規に Lambda 関数を作成する前提で進めますが、既存関数を Managed Instances に移行する場合も §4 以降の Capacity Provider 設定手順はそのまま適用できます。

アーキテクチャ選択

Capacity Provider は関数の実行アーキテクチャとして x86_64 (デフォルト) と arm64 のいずれかを選択できます。Graviton4 等の Arm ベースの専用ハードウェアを利用したい場合は arm64 を明示的に指定する必要があります。

なお、対応インスタンスファミリーの詳細な世代比較や GPU (p/g 系列) インスタンスの対応可否については、本記事執筆時点 (2026-07-15) の AWS 公式ドキュメント (Capacity providers ページ) 上で明記された記述が確認できませんでした。第三者ブログでは GPU インスタンスを Capacity Provider に指定できるとする記述も見られますが、公式一次情報での裏取りができていないため、本記事では断定を避け、GPU ワークロードでの採用を検討する場合は必ず最新の公式ドキュメントで対応状況を確認することを推奨します。

Capacity Provider のクォータ

Capacity Provider に紐付く関数バージョンが 1 つでも残っている状態では、その Capacity Provider を削除できません。§4 で構成を変更する際は、この制約を踏まえてバージョンを管理します。

必要な IAM アクション

Capacity Provider の作成・運用に最低限必要な IAM アクションを整理します。実際のポリシー例 (JSON) は §4 の Terraform 実装内で示します。

これらのアクションは、Capacity Provider を作成する側の IAM ロールと、EC2 リソースの管理を担うオペレーターロール (CapacityProviderOperatorRoleArn) という、2 つのロールに分かれます。両者を混同すると、Capacity Provider 自体は作成できても、実際のインスタンス起動時に権限エラーが発生するため注意してください。

2-2. 課金モデルの理解

Managed Instances の課金は、標準 Lambda や Provisioned Concurrency とは構造が異なります。まず、課金を構成する 3 要素を整理します。

重要な点として、実行時間 (duration) に応じた課金は発生しません。標準 Lambda はリクエストの処理時間 × メモリ設定で課金されますが、Managed Instances は起動している EC2 インスタンス自体に課金されるため、1 リクエストあたりの処理時間の長短がコストに直接影響しません。

標準 Lambda・Provisioned Concurrency・Managed Instances の課金構造を比較すると、以下の通りです。

Managed Instances の関数設定には下限があり、メモリは最低 2GB に固定されています。vCPU も最低 1 に固定されています。これは、1 つの実行環境が複数リクエストを同時並行処理する multi-concurrency を前提としているためで、c インスタンスファミリーの最小メモリ:vCPU 比率 (2:1) に合わせた制約です。Python のように multi-concurrency の扱いでメモリ消費が大きくなりやすいランタイムでは、4:1 や 8:1 といったより高いメモリ比率が推奨されるケースもあります。

Compute Savings Plans や Reserved Instances によるコミット割引は、Managed Instances が起動する EC2 インスタンスにもそのまま適用できます。定常的に稼働し続けるワークロードほど、この割引の恩恵を受けやすくなります。具体的な試算方法は §5 で扱います。

簡易試算のイメージ

月間 100 万リクエストを、c インスタンスファミリー相当のオンデマンド料金が 1 時間あたり $0.20 のインスタンス 1 台で処理し続けた場合の概算は以下の通りです (実際のインスタンスタイプ・稼働台数は Lambda が自動決定するため、あくまで内訳理解のためのイメージです)。

ここに Compute Savings Plans (最大 72% 割引) を EC2 インスタンス料金部分に適用すると、②が最大 $40.88 まで圧縮され、③の管理手数料もオンデマンド価格の 15% を基準に計算されるため大きくは変わらず、合計コストを大幅に下げられます。厳密な試算は稼働インスタンス数・インスタンスタイプ・割引プログラムの契約内容によって変動するため、§5 で AWS Pricing Calculator を用いた具体的な試算手順を扱います。

課金モデル上の注意点 (コストフロア)

Managed Instances は関数バージョンを発行すると、トラフィックがゼロの状態でも AZ 冗長性のためのデフォルト最小実行環境数 (後述 2-5) に応じた EC2 インスタンスが起動し続けます。そのため、低頻度・バースト性の高いワークロードでは、リクエストが少なくてもインスタンス起動分の②③のコストが恒常的に発生する点に注意が必要です。この特性が §6 で扱う「低頻度ワークロードへの誤適用」というアンチパターンの根本原因になります。

なお、本記事に記載する価格・料率は執筆時点 (2026-07-15) の AWS 公式情報に基づく参考値です。実際の請求額はリージョン・インスタンスタイプ・為替レートによって変動するため、本番導入前には必ず AWS Pricing Calculator または AWS マネジメントコンソールの最新料金表で確認してください。

コスト配分タグの活用

Capacity Provider は、起動する EC2 インスタンス・EBS ボリューム・ENI にタグを自動伝播する設定 (PropagateTags) を持ちます。プロジェクト単位・環境単位でコストを可視化したい場合は、Capacity Provider 作成時にタグ伝播を有効化し、Cost Explorer 側でコスト配分タグとして有効化しておくと、Managed Instances 由来のコストを他のワークロードと区別して追跡できます。この設定は §4 の Terraform 実装に含めます。

2-3. ゴール状態の定義

本記事を完走した時点で、以下の成果物が揃っている状態をゴールとします。

本記事の Terraform コードは ap-northeast-1 にそのまま terraform apply できる形式で提供します。実際の本番投入にあたっては、IAM ロールの権限を最小権限の原則に沿って絞り込むこと、CloudWatch アラームによる監視を追加することを推奨します (§6 で触れます)。

2-4. 用語整理

Managed Instances 固有の用語を事前に整理しておきます。§3 以降で前提知識として使用します。

これらの用語は §3 以降で繰り返し登場します。特に Router / Scaler / Lambda Agent の役割分担は §3 のスケーリング挙動の理解に直結するため、あわせて押さえておくとよいでしょう。

2-5. スケーリングの基本要素

Managed Instances のスケーリング挙動は、以下の 5 つの設定項目で調整します。Terraform での具体的な実装は §4 で扱いますが、ここでは各項目が何を制御するのかを事前に整理しておきます。

特に 3 の実行環境数の下限は、関数バージョン発行時に Lambda が AZ 冗長性のためデフォルトで 3 つの Managed Instance を起動し、3 つの実行環境を起動した状態で関数バージョンを ACTIVE にするという既定動作に対応します。この既定動作が、2-2 で述べた「コストフロア」の直接の原因です。

また、Managed Instances は標準 Lambda と異なり、リクエスト到着時のコールドスタートに応じたスケール (invocation-triggered scaling) を行いません。代わりに、実行環境の CPU 使用率と multi-concurrency の飽和状況という 2 つのリソース消費シグナルに基づいて非同期にスケールします。この違いの詳細は §3 で扱います。

5 分以内のトラフィック倍増 (2 倍超の急増) 時には、スケールアウトの遅延により throttle (ConcurrencyThrottles / CPUThrottles / MemoryThrottles / DiskThrottles) が発生することがあります。予測可能なピークを事前に見込める場合は、Amazon EventBridge Scheduler で MinExecutionEnvironments / MaxExecutionEnvironments をスケジュールに応じて事前に引き上げる運用が有効です。この運用パターンは §6 でも詳しく扱います。

2-6. 動作確認の準備

§4 のハンズオンへ進む前に、以下の項目を確認しておくとスムーズです。

これらの確認がすべて完了した状態を、§4 のハンズオン開始条件とします。特に 1 の CLI 確認は、権限不足や未対応リージョンでの作業を早期に検知できるため、最初に実行することを推奨します。

ここまでで、Managed Instances を導入するための前提環境・課金モデル・用語・スケーリングの基本要素を整理しました。次の §3 では、これらの前提知識をもとに、Managed Instances がなぜ「永続 EC2 インスタンス上で Lambda 関数を実行する」という新しい実行モデルなのかを、標準 Lambda・Provisioned Concurrency との違いという観点から仕組みレベルで掘り下げます。

3. 仕組み — 標準Lambda / Provisioned Concurrencyとの違い

本章は本記事の差別化の中核です。Managed Instances がなぜ「永続 EC2 インスタンス上で Lambda 関数を実行する」という第三の実行モデルなのか、標準 Lambda・Provisioned Concurrency とどう違うのかを、実行環境のライフサイクル・スケーリングの仕組み・セキュリティ境界という 3 つの観点から掘り下げます。

3-1. Managed Instances の実行モデル概要

Managed Instances の実行基盤は、Router・Scaler・Lambda Agent という 3 つのコンポーネントで構成される分散アーキテクチャです。関数バージョンを Capacity Provider に紐付けて発行すると、Lambda は AZ 冗長性のためデフォルトで 3 つの Managed Instance をアカウント内に起動し、それぞれで実行環境を起動した状態で関数バージョンを ACTIVE にします。

各実行環境は、標準 Lambda のように 1 リクエストを処理するたびに凍結されることはなく、継続的に稼働し続けます。実行環境の内部には複数の Runtime Worker が存在し、Router から届いたリクエストは空いている Runtime Worker に割り当てられます。これにより、1 つの実行環境が複数のリクエストを同時並行 (multi-concurrency) に処理できます。

【標準Lambdaの実行環境ライフサイクル】
リクエスト到着 → (空き環境なし・cold start) 実行環境準備 → Init フェーズ (JVM起動等) → invoke
→ 実行環境をfreeze (凍結) → 次のリクエストで再開 (warm) または一定時間後に破棄

【Managed Instancesの実行環境ライフサイクル】
関数バージョン発行 → 最低3つのManaged Instanceを起動 → 各インスタンス上で実行環境が継続的に稼働
→ Router がリクエストを実行環境内の空きRuntime Workerに割り当て → 複数Workerが並行してリクエストを処理
→ (freezeなし・実行環境は稼働し続ける)

3-2. 標準Lambdaとの違い — リクエスト単位分離 vs 継続稼働

標準 Lambda の実行環境は Firecracker MicroVM 単位で分離されており、1 つの実行環境は基本的に 1 リクエストを処理したら次のリクエストが来るまで凍結されます (warm 状態での再利用はありますが、同時に処理できるリクエストは実行環境あたり 1 つです)。スケールが必要になるのは、リクエストが到着した時点で空いている実行環境がない場合、つまり cold start が発生するタイミングです。

Managed Instances はこの前提そのものが異なります。実行環境は継続的に稼働し、複数の Runtime Worker を通じて複数リクエストを並行処理するため、cold start という概念自体が存在しません。スケールは「リクエストが到着したかどうか」ではなく、実行環境の CPU 使用率と multi-concurrency の飽和状況という 2 つのリソース消費シグナルに基づいて、Scaler が非同期に判断します。トラフィックが 5 分以内に倍増するようなケースでは、スケールアウトが追いつかず throttle が発生し得る点は 2-5 で述べた通りです。

タイムアウトの扱いにも大きな違いがあります。標準 Lambda は関数のタイムアウトが発生すると実行環境ごと処理を強制的に停止しますが、Managed Instances はタイムアウトしたリクエストをエラーとして呼び出し元に返した後も、コードの実行そのものは停止しません。他の同時実行中のリクエストの処理も継続されます。開発者は context オブジェクトで残り時間を確認し、タイムアウト前に自らの処理を中断するロジックを実装する必要があります。

両者の違いを整理すると、以下の通りです。

3-3. Provisioned Concurrencyとの違い

Provisioned Concurrency (PC) は、標準 Lambda の実行環境を事前に指定数だけウォームアップしておくことで cold start を回避する機能です。ただし、PC でウォームアップされる実行環境も基盤は標準 Lambda と同じ Firecracker MicroVM であり、1 実行環境が同時に処理できるリクエストは 1 つのままです。PC が変えるのは「cold start が起きるタイミング」だけであり、実行環境あたりの並行処理能力や課金モデルは標準 Lambda と同じ (duration 課金 + PC 維持課金) です。

Managed Instances は、この「事前ウォームで cold start を回避する」というアプローチ自体を採用していません。そもそも実行環境が継続稼働しているため cold start が発生せず、事前ウォームという概念が不要になります。その代わりに、1 実行環境あたりの処理能力を Runtime Worker 数 (最大同時実行数) で引き上げる、あるいは実行環境・インスタンス数そのものをスケールするという、PC とは異なるアプローチで容量を確保します。

3-4. AWS管理範囲とユーザー責任範囲

Managed Instances は「サーバーレスの運用簡素性を維持したまま EC2 を使う」モデルであるため、AWS が管理する範囲とユーザーが設定・責任を持つ範囲の境界線を正しく理解しておく必要があります。

3-5. セキュリティ境界の違い — Firecracker MicroVM から Capacity Provider へ

標準 Lambda は、Firecracker MicroVM によって関数ごとの強い分離が既定で確保されています。異なる関数、あるいは異なるテナントのワークロードが同じ物理ホスト上で動作していても、MicroVM 単位の分離により相互に影響しません。

Managed Instances では、この分離の前提が変わります。実行環境は EC2 インスタンス上のコンテナとして動作しますが、コンテナはセキュリティ境界として設計されていません。Capacity Provider が Managed Instances における新しいセキュリティ境界となり、信頼レベルが異なるワークロードは必ず別々の Capacity Provider に分離する必要があります。同一 Capacity Provider 配下の複数関数は、同じ Managed Instance 上でコンテナとして同居し得るため、相互に信頼できないワークロードを同居させてはいけません。

ここまで整理した実行モデル・スケーリング・セキュリティ境界の違いを踏まえ、次の §4 では実際に Capacity Provider を Terraform で構築し、Lambda 関数を紐付ける手順を解説します。

4. Capacity Provider の作成と Lambda 紐付け

本章では、§2-1 で整理した前提環境と IAM アクション、§2-4 の用語整理を踏まえ、実際に Terraform で Capacity Provider を構築し、Lambda 関数を紐付けるところまでをハンズオン形式で解説します。§2-6 の preflight チェックリストが完了している状態を開始条件とします。

4-1. Terraform 構成の全体像

本章で作成する Terraform リソースの全体像を整理すると、以下の通りです。

Terraform の AWS provider バージョンについては、§2-6 で暫定的に ~> 5.0 以降と記載しましたが、aws_lambda_capacity_provider リソース自体は AWS provider 6 系で追加されています。特に capacity_provider_scaling_config 内の scaling_policies (ターゲット追跡スケーリング) を使う場合は、執筆時点 (2026-07-15) で確認できた実装例をもとにすると ~> 6.31 以降を目安に、Terraform Registry の aws_lambda_capacity_provider ページで最新のバージョン要件を確認してから required_providers を固定してください (§2-6 の記載は本章の内容で読み替えます)。

terraform {
  required_providers {
 aws = {
source  = "hashicorp/aws"
version = "~> 6.31"
 }
  }
}

4-2. オペレーターロールと IAM 権限の準備

Capacity Provider が EC2 インスタンスをアカウント内に起動・終了するためには、CapacityProviderOperatorRoleArn として渡すオペレーターロールが必要です。§2-1 の IAM アクション表に対応する形で、Terraform で定義します。

data "aws_iam_policy_document" "capacity_provider_operator_trust" {
  statement {
 actions = ["sts:AssumeRole"]
 principals {
type  = "Service"
identifiers = ["lambda.amazonaws.com"]
 }
  }
}

resource "aws_iam_role" "capacity_provider_operator" {
  name= "lmi-capacity-provider-operator"
  assume_role_policy = data.aws_iam_policy_document.capacity_provider_operator_trust.json
}

data "aws_iam_policy_document" "capacity_provider_operator_permissions" {
  statement {
 sid = "ManagedInstancesEc2Lifecycle"
 actions = [
"ec2:RunInstances",
"ec2:TerminateInstances",
"ec2:DescribeInstances",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
 ]
 resources = ["*"]
  }
}

resource "aws_iam_role_policy" "capacity_provider_operator" {
  name= "lmi-capacity-provider-operator-policy"
  role= aws_iam_role.capacity_provider_operator.id
  policy = data.aws_iam_policy_document.capacity_provider_operator_permissions.json
}

Capacity Provider を作成する側 (CI/CD 実行ロールや Terraform 実行ロール) には、上記オペレーターロールを引き受けさせるための iam:PassRole を別途付与する必要があります。§2-1 で触れた通り、この 2 つのロール (作成者側とオペレーター側) を混同すると、Capacity Provider 自体は作成できてもインスタンス起動時に権限エラーが発生するため、Terraform のロール定義でも明確に分離しておきます。

data "aws_iam_policy_document" "capacity_provider_creator_permissions" {
  statement {
 sid = "CapacityProviderManagement"
 actions = [
"lambda:CreateCapacityProvider",
"lambda:GetCapacityProvider",
"lambda:UpdateCapacityProvider",
"lambda:PutFunctionScalingConfig",
 ]
 resources = ["*"]
  }

  statement {
 sid = "PassOperatorRole"
 actions= ["iam:PassRole"]
 resources = [aws_iam_role.capacity_provider_operator.arn]
  }
}

4-3. Capacity Provider の定義

VPC・セキュリティグループ・インスタンス要件・スケーリング設定を束ねた Capacity Provider 本体を定義します。§2-1 で前提とした複数 AZ のサブネットと、既存のセキュリティグループをそのまま参照します。

resource "aws_lambda_capacity_provider" "main" {
  name = "lmi-production"

  vpc_config {
 subnet_ids= var.private_subnet_ids # 複数AZのサブネットを指定 (最大16個)
 security_group_ids = [aws_security_group.lmi.id]
  }

  permissions_config {
 capacity_provider_operator_role_arn = aws_iam_role.capacity_provider_operator.arn
  }

  instance_requirements {
 architectures = ["arm64"] # Graviton4 等の専用ハードウェアを利用する場合はarm64を明示
 # AllowedInstanceTypes / ExcludedInstanceTypesはどちらか一方のみ指定可(併用不可)
 # 未指定の場合はLambdaが最適なインスタンスタイプを自動選択(可用性の観点から推奨)
  }

  capacity_provider_scaling_config {
 scaling_mode= "Auto" # Auto(既定) または Manual
 max_vcpu_count = 400 # Capacity Provider単位の上限。デフォルト400
  }

  tags = {
 Environment = "production"
 ManagedBy= "terraform"
  }
}

instance_requirements を省略、または AllowedInstanceTypes/ExcludedInstanceTypes を指定しない場合は、AWS 公式推奨の通り Lambda が最適なインスタンスタイプを自動選択します。特定のハードウェア要件 (高ネットワーク帯域を要する n 系インスタンス等) がある場合のみ、allowed_instance_types で絞り込んでください。

§2-2 で触れたコスト配分タグの伝播 (PropagateTags) は、CloudFormation の AWS::Lambda::CapacityProvider リソースでは PropagateTags プロパティとして提供が確認できていますが、対応する Terraform 側の属性名は執筆時点で一次情報での確証が取れていません。タグ伝播を有効化する場合は、Terraform Registry の最新スキーマを確認するか、aws lambda update-capacity-provider を Terraform 外の運用スクリプトから補完的に実行することを検討してください。

4-4. Lambda 関数と Capacity Provider の紐付け

Lambda 関数側は capacity_provider_config ブロックで Capacity Provider の ARN を指定します。§2-2 で述べた通り、関数のメモリは 2GB 以上、publish = true (バージョン発行) が必須です。Managed Instances は $LATEST ではなく発行済みバージョンに対してのみ有効になります。

resource "aws_lambda_function" "api_handler" {
  function_name = "lmi-api-handler"
  role = aws_iam_role.lambda_execution.arn
  handler = "index.handler"
  runtime = "python3.13"
  architectures = ["arm64"]

  filename= data.archive_file.lambda.output_path
  source_code_hash = data.archive_file.lambda.output_base64sha256

  memory_size = 2048 # Managed Instances下限。2GB/1vCPU未満は設定不可
  timeout  = 30
  publish  = true # 必須: Managed Instancesは発行済みバージョンにのみ適用される

  capacity_provider_config {
 lambda_managed_instances_capacity_provider_config {
capacity_provider_arn = aws_lambda_capacity_provider.main.arn
 }
  }

  vpc_config {
 subnet_ids= var.private_subnet_ids
 security_group_ids = [aws_security_group.lmi.id]
  }

  tags = {
 Environment = "production"
  }
}

capacity_provider_arn が capacity_provider_config.lambda_managed_instances_capacity_provider_config ブロック内にネストしている点に注意してください。関数の実行アーキテクチャ (architectures) は Capacity Provider の instance_requirements.architectures と一致させる必要があります (今回はどちらも arm64 で揃えています)。

4-5. 実行環境数の下限 / 上限の設定

MinExecutionEnvironments / MaxExecutionEnvironments は、執筆時点で Terraform リソースとしては提供が確認できておらず、AWS CLI (または AWS SDK / EventBridge Scheduler) の PutFunctionScalingConfig API を介して設定します。§2-5 で述べた通り、デフォルトの下限は AZ 冗長性のため 3 です。

aws lambda put-function-scaling-config \
  --function-name lmi-api-handler \
  --qualifier '$LATEST.PUBLISHED' \
  --function-scaling-config MinExecutionEnvironments=5,MaxExecutionEnvironments=50 \
  --region ap-northeast-1

$LATEST.PUBLISHED を指定すると、以降新しく発行されるバージョンにも設定が引き継がれます。特定バージョンを対象に設定した場合、次回発行する新バージョンではデフォルト値 (下限 3・上限無制限) へ戻るため注意してください。Min/Max は必ずペアで指定し、両方を 0 にすると関数を削除せずに無効化できます (§6 でこの挙動を活用したコスト最適化パターンを扱います)。

このコマンドを Terraform 管理下に置きたい場合は、null_resource + local-exec プロビジョナーで CI/CD パイプラインに組み込むか、Terraform の外側 (deploy スクリプト) で terraform apply 後に実行する運用が現実的です。予測可能なピークに合わせて定期的に値を変更したい場合は、§2-5 で触れた Amazon EventBridge Scheduler から PutFunctionScalingConfig を直接呼び出すスケジュール設定が有効です (詳細は §6 で扱います)。

4-6. 動作確認

Terraform apply 後、§2-6 の preflight チェックと同様の手順で構成を確認します。

# Capacity Providerが ACTIVE 状態になっているか確認
aws lambda get-capacity-provider \
  --capacity-provider-name lmi-production \
  --region ap-northeast-1 \
  --query 'State'

# 関数バージョンにCapacity Providerが紐付いているか確認
aws lambda get-function-configuration \
  --function-name lmi-api-handler \
  --qualifier 1 \
  --query 'CapacityProviderConfig'

# 実行環境数の下限/上限が反映されているか確認
aws lambda get-function-scaling-config \
  --function-name lmi-api-handler \
  --qualifier '$LATEST.PUBLISHED'

State が Active になっていること、CapacityProviderConfig に §4-3 で作成した ARN が反映されていることを確認できれば、Capacity Provider と Lambda 関数の紐付けは完了です。ここまでで、§1 の到達点として掲げた「Capacity Provider の設定から Lambda 関数の ARN 紐付けまでを一通り実装できる状態」に達しています。次の §5 では、この構成を前提にコスト試算と使い分けを判断します。

5. コスト最適化と使い分け判断 — 標準Lambda / Provisioned Concurrency / Managed Instances

§2-2 では、課金 3 要素 (リクエスト課金 + EC2 インスタンス料金 + 管理手数料) をもとにした概算 (約 $168.10/月) を扱いました。本章では、この概算を AWS Pricing Calculator で厳密化する手順と、EC2 コミット割引の活用方法、そして本記事の差別化の核である 3 モデルの使い分け判断基準を扱います。

5-1. AWS Pricing Calculator を用いた厳密な試算

§2-2 の簡易試算はインスタンスタイプ・稼働台数を単純化したイメージであり、実際のコストは Capacity Provider が自動選択するインスタンスタイプ、AZ 冗長性のための最小実行環境数 (デフォルト 3)、リージョンによって変動します。本番導入前には、必ず AWS Pricing Calculator で以下の手順に沿って試算してください。

AZ 冗長性のため、トラフィックがゼロでもデフォルトで 3 つの実行環境 (= 3 台の Managed Instance) が起動し続ける点は、②の見積もりで見落としやすいポイントです。§2-2 で述べた「コストフロア」を Pricing Calculator の試算にも必ず反映してください。

5-2. EC2 コミット割引の活用

Managed Instances が起動する EC2 インスタンスには、通常の EC2 と同様に Compute Savings Plans (Compute SP) または Reserved Instances (RI) によるコミット割引がそのまま適用できます。

Capacity Provider の既定動作 (未指定時にインスタンスタイプを自動選択) を活かす場合は、特定インスタンスファミリーへのコミットが前提となる RI よりも、Compute Savings Plans の方が割引を取りこぼしにくい構成になります。一方で、allowed_instance_types により特定ファミリーへ固定している場合は、RI のコミットとの整合が取りやすくなります。

コミット期間 (1 年 / 3 年) と支払いオプション (All Upfront / Partial Upfront / No Upfront) の選定は、既存の EC2/Graviton 運用で得られた知見をそのまま流用できます。Compute Savings Plans の購入戦略そのもの (最適なコミット額の算出方法等) は本記事の範囲外とし、既存の Cost 最適化シリーズに委譲します。

§2-2 の簡易試算例 (概算 $168.10/月) に Compute Savings Plans (最大 72% 割引) を EC2 インスタンス料金部分に適用すると、以下のように変化します。

管理手数料 (③) は EC2 オンデマンド価格の 15% を基準に計算されるため、コミット割引適用後も②に連動して圧縮されます。ただし実際の割引率はコミット額・期間によって変動するため、必ず Pricing Calculator または実際の請求データで確認してください。

5-3. 標準Lambda / Provisioned Concurrency / Managed Instances 三者比較

§1-1 の概観表を、コスト構造・実行環境の性質という観点でさらに掘り下げます。

5-4. 使い分け判断基準

3 モデルの選択基準を、トラフィックパターン・専用ハードウェア要件・運用許容度という 3 軸で整理します。

判断に迷う場合の簡易フローは以下の通りです。

Q1. リクエストは低頻度・バースト性中心か?
 → Yes: 標準Lambdaで十分 (Managed Instancesはオーバースペック、§1-2参照)
 → No: Q2へ

Q2. cold startが問題で、かつ高トラフィック・定常ではないか?
 → Yes: Provisioned Concurrencyを検討
 → No: Q3へ

Q3. 高トラフィック・定常稼働 かつ (専用HW要件 or 実行時間課金の総額がEC2ベースを上回る) か?
 → Yes: Managed Instancesを検討 (§4のCapacity Provider構築へ)
 → No: 標準Lambdaのまま運用を継続し、トラフィックの推移を監視

いずれのモデルも移行は関数バージョン単位で行えるため、まず一部の関数・トラフィックで Managed Instances を試験導入し、§5-1 の Pricing Calculator 試算と実際の請求額を突き合わせてから本格移行するアプローチを推奨します。次の §6 では、この判断を誤った場合や設定を誤った場合に発生する詰まりポイントを扱います。

6. 詰まりポイント / アンチパターン

本章では、Managed Instances を本番導入する際に見落としやすい詰まりポイントとアンチパターンを、実際に発生し得る症状とあわせて整理します。

6-1. 低頻度ワークロードへの誤適用によるコスト悪化

§2-2 で述べた「コストフロア」— トラフィックがゼロでも AZ 冗長性のためデフォルト 3 つの実行環境分の EC2 インスタンス料金・管理手数料が発生し続ける挙動 — を見落とし、低頻度・バースト性の高いワークロードに Managed Instances を適用すると、標準 Lambda のときより月額コストは増加するケースがあります。

対策として、以下を確認してください。

• §5-1 の Pricing Calculator 試算で、ピーク時だけでなく平常時・閑散時のコストフロアを必ず含める
• どうしても Managed Instances を使いたいが低頻度時間帯がある場合は、§4-5 で扱った MinExecutionEnvironments / MaxExecutionEnvironments を EventBridge Scheduler で時間帯別に調整する (6-3 で詳述)
• 業務時間外など完全にトラフィックの発生しない時間帯がある場合は、Min/Max を両方 0 に設定して関数を一時的に無効化する (§2-5 / §4-5 で触れた「デアクティベート」機能)

6-2. auto-scaling 上限設計ミス

Capacity Provider の MaxVCpuCount (デフォルト 400) や、関数の MaxExecutionEnvironments の上限設計を誤ると、想定外のトラフィック急増時にスケールアウトが頭打ちになり、throttle (ConcurrencyThrottles / CPUThrottles / MemoryThrottles / DiskThrottles) が発生します。

6-3. 予測可能なピークへの事前対応 — EventBridge Scheduler 活用

6-1・6-2 で触れた通り、Managed Instances は invocation 発生時にスケールする標準 Lambda と異なり、CPU 使用率・concurrency 飽和という非同期シグナルに基づいてスケールするため、5 分以内のトラフィック倍増には追従が遅れる場合もあります。セール開始時刻や月次バッチのように、ピークの発生タイミングを事前に把握できている場合は、Amazon EventBridge Scheduler から PutFunctionScalingConfig を直接呼び出すスケジュール設定が有効です。

# ピーク開始30分前にMin/Maxを引き上げるスケジュールを作成する例
aws scheduler create-schedule \
  --name "lmi-scale-up-before-peak" \
  --schedule-expression "cron(30 8 * * ? *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
 "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
 "RoleArn": "arn:aws:iam::<account-id>:role/eventbridge-scheduler-role",
 "Input": "{\"FunctionName\": \"lmi-api-handler\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 30, \"MaxExecutionEnvironments\": 200}}"
  }'

このスケジューリングは実行環境数の「床」と「天井」を事前に引き上げるだけで、実際のスケール自体は引き続き CPU 使用率・concurrency 飽和シグナルに基づいて行われる点に注意してください。ピーク後は 6-1 で触れた低頻度時間帯向けの縮小スケジュールとあわせて運用することで、コストフロアと throttle リスクの両方を抑制できます。

6-4. 専用ハードウェア前提の可搬性低下

instance_requirements.architectures を arm64 に固定し、Graviton4 等の専用ハードウェアを前提にコードを最適化すると、標準 Lambda (共有ハードウェア) への切り戻しや、他リージョンへの展開時にアーキテクチャ差異の検証が必要になります。特に以下の点に注意してください。

• ネイティブ依存ライブラリ (C 拡張を含む Python パッケージ等) を利用している場合、x86_64 / arm64 双方でビルド・検証が必要
• allowed_instance_types でインスタンスタイプを固定運用している場合、対象インスタンスファミリーの提供終了・在庫枯渇時に可用性の低下するリスクがある (§2-1 で述べた通り、Lambda にインスタンスタイプ選択を委ねる運用を可用性の観点で推奨します)
• Managed Instances 前提でチューニングしたメモリ/vCPU 比率 (§2-2) は、標準 Lambda に戻したとき、そのまま使えるとは限らない

移行の可逆性を確保したい場合は、Capacity Provider の instance_requirements を極力デフォルト (Lambda による自動選択) へ近づけて設定し、専用ハードウェア要件が明確な場合のみ限定的に固定する方針を推奨します。

6-5. その他の見落としやすいポイント

§3-5 の ep-box で触れた 2 点 (セキュリティ境界・タイムアウト後の継続実行) に加え、実装段階で見落としやすいポイントを整理します。

ここまでの詰まりポイントを踏まえたうえで、次の §7 では本記事全体のまとめと、関連記事へのクロスリンクを整理します。

7. まとめ + クロスリンク

7-1. 本記事の到達点

本記事では、2025 年 11 月に GA した AWS Lambda Managed Instances を、標準 Lambda・Provisioned Concurrency に続く「第三の実行モデル」として本番運用の視点から解説しました。要点を整理すると、以下の通りです。

§1-1 で掲げた「Capacity Provider の設定から Lambda 関数の ARN 紐付けまでを一通り実装できる状態」「課金モデルを理解し、3 モデルから自身のワークロードに適した選択を、コスト試算に基づいて判断できる状態」というゴールは、§4 の Terraform 実装と §5 のコスト試算・判断基準によって到達できる構成になっています。

7-2. 関連記事

本記事は「実行基盤 (compute substrate) と課金モデル」というインフラ層に焦点を当てており、以下の記事とあわせて読むことで、Lambda の本番運用に必要な周辺知識を補完できます。実際のクロスリンク結線は Phase5 (series-crosslink-automation) で行うため、リンク先 URL は本記事執筆時点ではプレースホルダです。

AWS Cost Optimization本番運用 Vol1 を読む

これらの記事は、いずれも本記事の前提知識または委譲先として位置づけています。特に EC2/Graviton の基礎知識に不安があるときは、§4 のハンズオンに進む前段階として、Compute 本番運用シリーズへ目を通しておくと理解がスムーズです。