AWS Lambda に、ユーザーが書いたコードや AI が生成したコードを安全に実行するための新しいプリミティブ「MicroVMs」が追加されました。仮想マシンレベルの分離と、ほぼ瞬時の起動や再開を両立し、環境の起動から終了までを開発者自身が制御できる点が特徴です。本記事では、サーバーレスを活用する日本のエンジニア向けに、Lambda MicroVMs の位置づけと仕組み、想定ユースケース、そして移行や運用で押さえておきたい観点を整理します。
Lambda MicroVMs とは何か
Lambda MicroVMs は、分離されたステートフルな実行環境を提供する新しいサーバーレスコンピューティングのプリミティブです。従来の仮想マシンが持つ強い分離特性と、サーバーレスならではの俊敏さやインフラ管理不要という利点を、ひとつの仕組みに統合しています。信頼できないコードを扱うアプリケーションや、セッションの状態を保持したまま長時間動かしたいワークロードが主な対象です。
ここで重要なのは、既存のコンテナや従来型 VM、そして通常の Lambda 関数との住み分けです。それぞれの特性を整理すると次の表のようになります。
実行形態 | 分離の強さ | 起動の速さ | 主な向き先 |
|---|---|---|---|
従来型の仮想マシン | カーネル非共有で強い | 起動に分単位を要することが多い | 長時間稼働の汎用ワークロード |
コンテナ | カーネル共有のため追加のハードニングが必要 | 速い | 信頼できるコードの高密度実行 |
Lambda 関数 | 実行単位で分離 | 速い | イベント駆動のリクエスト応答 |
Lambda MicroVMs | カーネル非共有の VM レベル分離 | ほぼ瞬時に起動と再開 | 長時間で対話的なステートフル処理 |
コンテナはカーネルを共有するため、信頼できないコードを安全に走らせるには大きなセキュリティ対策が求められます。一方 MicroVMs はセッションの間でカーネルやリソースを共有しないため、標準で VM レベルの分離を得られます。Lambda 関数がイベント駆動のワークロードに向くのに対し、MicroVMs は環境の状態を保持しながら長く動かす用途に向いています。

Firecracker が支える仕組みとほぼ瞬時の起動
Lambda MicroVMs は Firecracker という軽量仮想化技術で駆動されます。Firecracker は月間 15 兆回を超える Lambda 関数の呼び出しを支えてきた実績のある基盤であり、強い分離と軽量さを両立している点が MicroVMs にそのまま生きています。
起動の流れはスナップショットを軸に設計されています。開発者は Dockerfile と、Amazon S3 に置いた zip 形式のコードアーティファクトを指定して MicroVM のイメージを作成します。Lambda が Dockerfile を実行してアプリケーションを初期化し、その状態を Firecracker のスナップショットとして取得します。以降にそのイメージから起動する環境は、コールドブートを繰り返すのではなく、初期化済みのスナップショットから再開するため、ほぼ瞬時に立ち上がります。
提供されるスペックの上限も把握しておきたいところです。主な値を表にまとめます。
項目 | 上限や前提 |
|---|---|
vCPU | 最大 16 |
メモリ | 最大 32 GB |
ディスク | 最大 32 GB |
実行と状態保持の時間 | 最大 8 時間 |
アーキテクチャ | ARM64 |
提供区分は一般提供であり、2026 年 6 月 22 日の AWS 公式ブログで発表されました。利用できるリージョンは、米国と欧州、そしてアジアパシフィックの東京を含む複数リージョンで開始しています。対象リージョンは今後拡大していく可能性があるため、実際の利用時は最新の公式情報で確認することをおすすめします。
完全なライフサイクル制御という考え方
MicroVMs の大きな特徴は、環境のライフサイクルを開発者が明示的に制御できる点にあります。起動を意味する launch、一時停止の suspend、再開の resume、終了の terminate という 4 つの操作を、自分のアプリケーションの都合に合わせて呼び出せます。
各操作の役割を整理すると次のようになります。
操作 | 役割 |
|---|---|
launch | 初期化済みスナップショットから環境を起動する |
suspend | メモリとディスクの状態を保持したまま一時停止し、アイドル時のコストを抑える |
resume | 保持した状態からリクエスト到来時などに再開する |
terminate | 不要になったセッションを終了する |
アイドル時には自動でサスペンドさせることもでき、そのしきい値は設定可能です。状態を捨てずに一時停止できるため、長時間のセッションを維持しつつも、使っていない時間帯のコストを下げやすい設計になっています。イメージ作成には create-microvm-image、環境の起動には run-microvm といったコマンドが用意されており、作成から起動、停止、終了までを一貫して扱えます。なお、コマンドの完全な構文や細かなオプションは開発者ガイドで確認しておくと安心です。

想定ユースケースとマルチテナントでの分離
MicroVMs が特に効果を発揮するのは、ユーザーごとに分離した環境で信頼できないコードを実行する必要があるアプリケーションです。AWS は代表的なユースケースをいくつか挙げています。主なものを整理します。
ユースケース | MicroVMs が活きる理由 |
|---|---|
AI コーディングアシスタント | AI が生成したコードを分離環境で安全に実行し結果を返せる |
対話型のコード実行環境 | セッション状態を保ちながら長時間の対話を継続できる |
データ分析プラットフォーム | 利用者ごとに独立した計算環境を素早く用意できる |
脆弱性スキャナ | 危険性のある処理を強い分離のもとで走らせられる |
ユーザースクリプトを動かすゲームサーバー | 投入されたコードをテナント単位で隔離できる |
これらはいずれも、マルチテナントの SaaS で複数の利用者のコードを同じ基盤の上で走らせる状況に通じます。カーネルを共有しない分離があることで、あるテナントの処理が別のテナントに影響を及ぼすリスクを抑えられます。テナントごとのアクセス制御については、専用のエンドポイントや認証の仕組みと組み合わせる設計が想定されます。詳細は公式ドキュメントで確認してください。
開発者が押さえる移行と運用の考慮点
強力な仕組みである一方で、導入や移行の際に意識しておきたい点もあります。実際に検討を始める前に確認しておきたい観点を整理します。
観点 | 考慮すべき内容 |
|---|---|
アーキテクチャ | ARM64 が前提のため、既存の x86 向けバイナリや依存関係は移行時に見直す |
スナップショット由来の一意性 | 初期化時に一意な値の生成や接続確立、一時データの読み込みを行う場合は AWS が提供するフックと統合し整合性を保つ |
コスト設計 | 課金はコンピュート、スナップショットの操作とストレージ、データ転送という複数の軸で構成される。アイドル時のサスペンドを前提に設計する |
Lambda 関数との使い分け | 短いイベント駆動の処理は Lambda 関数、長時間で状態を持つ対話型処理は MicroVMs と役割を分ける |
料金の具体的な単価は公式の料金ページで確認する必要があります。本記事では課金の軸のみを示し、金額は断定しません。スナップショットから同じ状態で複数の環境が立ち上がる特性は便利である反面、乱数のシードやネットワーク接続など、環境ごとに一意であるべき要素の扱いには注意が必要です。こうした点は AWS が提供する統合ポイントを活用することで整合性を確保できます。
Lambda MicroVMs は、サーバーレスの手軽さを保ちながら、これまで自前のインフラ管理が避けられなかった分離実行の領域を大きく前進させる仕組みです。AI 生成コードの実行基盤やマルチテナントのサンドボックスを検討しているエンジニアにとって、有力な選択肢になりそうです。まずは対応リージョンと料金体系を公式情報で確認し、小さなワークロードから試してみると理解が深まります。

















