こんにちは小山です。
本当はre:Invent中に出すはずだったブログですが日本で仕上げました。
人生ってそんなもんですよね。
さて、AWS Lambda Managed Instances を一言でいうなら
Lambda の手軽さ × EC2 の柔軟さを両取りする新機能 です。
では詳しく内容に触れていきましょう。
AWS Lambda Managed Instances(以下、Lambda Managed Instances)は、
AWS Lambda の使いやすさ(サーバーレス運用)と、Amazon EC2 の柔軟性/性能を融合する新機能として、2025年11月30日に発表されました。
サポートしているリージョンは
米国東部(バージニア北部)、米国東部(オハイオ)、米国西部(オレゴン)
アジアパシフィック(東京)、欧州(アイルランド)です。
東京で使えるのはありがたいですね。
日本でAWSの活用が進んでいることがうかがえます。
Lambda Managed Instances とは?
改めてですが、今回発表されたLambda Managed Instancesは
既存サービスであるLambdaのメリットそのままに課題を解決したものです。
従来、Lambda はインフラ管理不要なサーバーレス環境として広く活用されているサービスです。
イベント駆動やオンデマンドでコードを実行でき、スケーリングや課金も使った分だけ、という手軽さが魅力です。
しかし
「特定の CPU アーキテクチャを使ってLambdaを使いたい」
「LambdaでEC2 のリザーブド/Savings Plans を活かしたい」
「Lambdaを持続的・安定的なワークロードでコスト最適化したい」
といったニーズでは、これまで Lambda だけでは限界があり、
インフラ管理を伴う EC2 の利用が必要になるケースがありました。
Lambda Managed Instances はこのギャップを埋めるために設計されており、
以下のような特徴を持ちます。
EC2 インスタンスタイプを選択可能
EC2のSavings Plans / RI が使える
常時ウォームでコールドスタートがほぼ解消
マルチコンカレンシー対応
EC2管理はAWSが担当
では上記特徴を詳しく解説します。
EC2 インスタンスタイプを選択可能
特定のインスタンスタイプを選択することができます。
逆に、実行環境にすべてのインスタンスを含めることや特定のインスタンスタイプを除外することもできます。
さらに、最大vCPU数や、自動スケーリングを使用するかCPUポリシーを使用するかなど、
自動スケーリングに関するいくつかのコントロールを指定することもできます。
MLや特殊なバッチ実行をする場合にはインスタンスタイプを指定しての実行ができるのでとても良いですね。
EC2 のSaving Plans やReserved Instances料金の適用ができる
Lambda Managed Instances では、通常のオンデマンド料金だけでなく、
Compute Savings Plans や Reserved Instances といった、
EC2の割引適用可能な料金モデルを利用できます。
EC2のメリットである安定したワークロードとコスト削減の効果を受けることができます。
従来のLambda のように「実行時間あたりで課金」されるのではなく、以下の三要素で料金が決定します。
料金体系が従来のLambdaと変わってしまうので試算の仕方は注意が必要ですね。
100 万回の呼び出しごとに 0.20 USD の標準 Lambda リクエスト料金
EC2 のインスタンス料金
EC2 オンデマンドインスタンス料金に基づいて計算される 15% のコンピューティング管理料金
コールドスタートがほぼ解消
既存のLambdaでは、コールドスタート回避にはProvisioned Concurrencyの使用が必要でした。
これには追加の料金や設定が必要です。
対してLambda Managed Instancesでは、
インスタンス上で事前にプロビジョニングされた実行環境にリクエストを自動的にルーティングするため、コールドスタートを排除できます。
マルチコンカレンシー対応
1つの環境で同時に複数リクエスト処理します。
従来の Lambda では「1リクエスト=1実行環境」でしたが。
Lambda Managed Instancesでは同一環境(EC2インスタンス)を共有します。
同一環境の共有はコンピュート資源を効率よく活用できます。
EC2の運用はAWSが担当
インスタンスのプロビジョニング、OS パッチ適用、セキュリティアップデート、インスタンス間の負荷分散、
そして需要に基づいた自動スケーリングは AWS が処理します。
このあたりは従来のLambdaの良さをそのまま引き継いでくれている感じがしますね。
サービス比較
| 特徴 | Lambda | Lambda Managed Instances | EC2 |
|---|---|---|---|
| インフラ管理 | 不要 | 不要 | 必要 |
| インスタンスタイプ | 選択不可 | 選択可能 | 選択可能 |
| コールドスタート | あり | ほぼなし | なし |
| 割引適用 | なし | あり | あり |
| コンカレンシー | 単一 | 複数 | 複数 |
ユースケース
- 高負荷 API
- 特定の CPU アーキテクチャ、GPU など特殊ハードウェアが必要なバッチ処理
- コスト最適化と運用負荷の両立を目指すサービス運用
注意点
サービスの移行に伴って基本的に関数コードは変更不要ですが、マルチコンカレンシー環境での並列実行に対応しているか(スレッドセーフか、共有リソースの扱い、グローバル関数)を確認する必要があります。
たとえばグローバル変数などは、実行環境が使い回されると、前回の実行で代入された値が、次回の実行時にもそのまま残ってしまいます。
そのため既存のLambdaで問題なく動いているサービスであっても、そのまま移行すると意図せぬ挙動となることがあるためコードの見直しを事前に実施することを推奨します。
また、インスタンスの有効期間が「最大で14日」と、従来と料金モデルが異なるため、請求額が変わることがあります。
まとめ
Lambda の手軽さと EC2 の柔軟性を融合したとても良いサービスだと思います。
他方で既存のLambdaも、低頻度で実行される軽量のジョブや専有環境での実行が必要な場合はまだまだ活躍の場面がありそうです。