Lambda MicroVMs についての調査
AWS Lambda の MicroVMs が、これまでの Lambda・コンテナ・仮想マシンと何が違うのかを整理する。
- 公開日
- 更新日
はじめに
AWS Lambda に 2026-06-22、新しく MicroVMs という実行単位が加わりました（出典: AWS What’s New、2026-08-24 確認）。 名前に Lambda が付いていますが、これまでの Lambda と何が異なるのかを調査します。
この記事では、MicroVMs がこれまでの Lambda やコンテナ、仮想マシンと何が違うのかを整理します。
Lambdaを支える技術について
Lambdaに求められた機能
Lambda は、他人同士のコードを1台の物理サーバーに大量に相乗りさせて動かすサービスです。関数は数百ミリ秒で終わることも多いため、実行環境の起動に数秒もかけられませんし、同じサーバーに多数の他の利用者と同居しているため互いに隔離されている必要もあります。
（出典: NSDI ’20 論文、2026-08-24 確認）
MicroVMについて
この要求を満たすには、必要最低限の機能だけを備えた小さな仮想マシン（MicroVM）が要ります。
仮想マシンを作るには、Linux カーネルに標準搭載されている仮想化機能（ハイパーバイザー）の KVM（Kernel-based Virtual Machine）と、KVM を操作して仮想マシンを組み立てる仮想マシンモニタ（VMM）の2つが必要です。当時、VMM の定番は QEMU でした。
ただし QEMU は、本物の PC を丸ごと再現した仮想マシンを作る VMM だったため、求めている小さな仮想マシンは作れませんでした。そのため AWS は Google の OSS「crosvm」をベースに、小さな仮想マシンだけを作る VMM である Firecracker を OSS として自社開発しました。Firecracker が作る仮想マシンを MicroVM と呼びます。Lambda は、この Firecracker が作る MicroVM の中で利用者のコードを動かしています。
（出典: NSDI ’20 論文、2026-08-24 確認）
QEMU と Firecracker の比較
1台に詰められる数・起動時間・利用できる機能の3点で QEMU と比べると、次のようになります。
詰められる数
仮想マシンにおける境界について
実行環境を隔離する方法には、仮想マシンのほかにコンテナもあります。コンテナは軽くて速い代わりに、同じサーバーにいる全員がホストのカーネルを1つ共有します。そのため、カーネルに脆弱性が1つあると、同居する他の利用者に影響を及ぼす可能性があります。
一方、仮想マシンは1台ずつ自分のゲストカーネルを持ちます。MicroVM も仮想マシンなので同じです。カーネルの脆弱性があっても、同居する他のテナントとの境界を越えることはありません。
ここで 仮想マシン・コンテナ・MicroVM で、それぞれがどういった境界になっているかを比較してみました。
（出典: Firecracker 公式サイト および NSDI ’20 論文、2026-08-24 確認）
Lambda 関数 と MicroVMs の違い
それぞれの比較
ここまで記載したように、Firecracker は以前から Lambda を支える技術の一つであり、従来のコードに関しても実行環境ごとに MicroVM が利用されています。
どういった違いがあるのか、Lambda 関数と Lambda MicroVMs の2つを比較してみました。
Lambda関数 と Lambda MicroVMsの比較表
| 観点 | Lambda 関数 | Lambda MicroVMs |
|---|---|---|
| 実行モデル | イベント駆動でハンドラを呼ぶ | 専用 HTTPS エンドポイントで常駐アプリに接続 |
| 状態 | 原則ステートレス | メモリ・ディスク・プロセスをセッション中保持 |
| ライフサイクル | Lambda が管理 | 開発者が run / suspend / resume / terminate |
| 最大実行時間 | 15分 | 8時間（合計） |
| 課金単位 | GB 秒 + リクエスト数、ミリ秒課金 | vCPU 秒 + GB 秒の秒課金 + スナップショット + データ転送 |
| OS 権限 | 制限的（疑似端末 pty なし） | フル OS 機能 |
（出典: Lambda MicroVMs デベロッパーガイド、2026-08-24 確認、2026-06-22 一般提供時点の仕様）
開発者が管理できる範囲の違い
併せて、開発者がどの層まで触れるか（どこから先が AWS の管理か）を、オンプレミス・EC2・これまでの Lambda 関数・MicroVMs の4つで比べた図を掲載します。
（出典: 同上）
4つの操作について
MicroVMs では、Firecracker が作る仮想マシンである MicroVM に対して、run / suspend / resume / terminate の4つの操作を利用者が直接実行できます。
run と terminate を呼ぶのは、MicroVMs を組み込む開発者のアプリ（バックエンド）です。suspend と resume は、run のときにアイドルポリシー（無通信が何秒続いたら止める、通信が来たら再開する）を渡しておけば Lambda が自動で行います。API で明示的に呼ぶこともできます（出典: Running and using MicroVMs「Idle policy configuration」、2026-09-05 確認）。
MicroVM の状態遷移図
4つの操作で MicroVM の状態がどう移るかを図にしました。
状態: PENDING（準備中）
コンピュート課金: なし
準備中（スナップショット読み込み）
稼働中（エンドポイントで通信を受付）
一時停止（メモリとディスクの状態を保持。コンピュート課金なし）
終了（最終状態。再開不可）
4つのAPIについて
それぞれの操作は次のとおりです。
| 操作（CLI 名） | 概要 |
|---|---|
run（run-microvm） |
イメージのスナップショットから MicroVM を起動し、一意の ID と専用の HTTPS エンドポイントを割り当てる |
suspend（suspend-microvm） |
メモリとディスクの状態を保持したまま一時停止する。停止中はコンピュート課金が発生しない。アイドル時間の超過で自動でも起きる |
resume（resume-microvm） |
一時停止した MicroVM を状態そのままに再開する。トラフィック到着時の自動再開も設定できる |
terminate（terminate-microvm） |
MicroVM を終了して全リソースを解放する。終了後は再開できない。最大実行時間の超過で自動でも起きる |
（出典: Running and using MicroVMs、2026-09-03 確認）
4つの操作を支える仕掛け: スナップショット
この4つの操作が成り立つ土台は、MicroVM の中身（メモリとディスク）を丸ごと保存して戻せる仕組みです。イメージを作る時点で、アプリを起動した直後の状態を Firecracker のスナップショットとして保存しておくので、run はそれを復元するだけで済み、依存関係の読み込みをやり直しません。suspend はその時点のメモリとディスクを保存して止め、resume はそこから戻します。
保持できる範囲には上限があります。1台の MicroVM が RUNNING と SUSPENDED でいられるのは合計で最長8時間、メモリは基準 0.5〜8 GB（ピーク時はその4倍、最大 32 GB / 16 vCPU）、ディスクは最大 32 GB です（出典: コアコンセプト、MicroVM images「MicroVM sizing」、Running and using MicroVMs「Key parameters」、2026-09-04 確認）。
フックについて
4つの操作に加えて、フックも用意されています。
フックは利用者が呼ぶものではなく、起動・一時停止・再開・終了の各タイミングと、ビルド時の ready / validate のタイミングで、Lambda が利用者のアプリを HTTP で呼び出すことが可能となる仕組みです。アプリ側で設定をしておくと、そのタイミングに独自の処理を差し込むことが可能となります。
| フック | いつ呼ばれるか | 用途 |
|---|---|---|
/ready（ビルド時） |
アプリ起動後 | 初期化完了を知らせ、スナップショットを撮らせる |
/validate（ビルド時） |
ビルド完了後の検証起動時 | 再開後に正しく動くか検証する |
/run |
起動直後 | テナントごとの初期化、一意な値の生成 |
/suspend |
一時停止の直前 | 書き込みの flush、接続のクローズ |
/resume |
再開の直前 | 接続の張り直し、認証情報の更新 |
/terminate |
終了の直前 | データの flush、後片付け |
（出典: Running and using MicroVMs および MicroVM images、2026-09-03 確認）
具体的な使いどころ
具体的な使いどころとしては、ブラウザ IDE やノートブックなどの開発プラットフォーム、データ分析基盤、AI コーディングエージェント、セキュリティスキャナ、CI/CD などが挙げられています（出典: AWS Compute Blog、2026-09-05 確認）。
ここでは AI コーディングエージェントの例を取り上げ、利用者が依頼から片付けるまでの一連の流れを追っていきます。
AI コーディングエージェントでのフローについて
MicroVM: なし
コンピュート課金: なし
結果を LLM に返し、正常に動くまで 3 と 4 を繰り返す
- 裏で動いたこと
- 利用者がフロント画面で「テストを書いて実行して」と依頼する。バックエンド（あなたのアプリ）が依頼を受け取る。MicroVM はまだ無い。
- 利用者にはこう見える
- 送信ボタンを押して、返事を待っている。
他のサービスとの違い
利用者ごとに専用の実行環境を配ることは、勿論これまでも EC2・コンテナ・Lambda 関数では可能でした。ただし、それぞれが得意としている範囲があり、要求に対してどれを利用するかといった判断が必要となります。
ここでは各方式ごとに、どういった要求を満たせるのか図を用意しました。方式を切り替えることで、それぞれの強みや弱みを見ることができます。
従来の Lambda: 隔離は強いが、15分・ステートレスで状態を持てず、縛りも多い
改めて、上記の観点を記載すると以下のようになります。
| 選択肢 | 隔離 | 起動 | 状態の保持 | 制約の少なさ |
|---|---|---|---|---|
| EC2 などの仮想マシン | 強い（ハードウェア仮想化） | 数分（AMI ブートと初期化） | 保持できる | 高い（時間・スペック・OS を選べる） |
| コンテナ | ホストカーネルを共有 | 数秒 | 保持できる | 高い |
| Lambda 関数 | Firecracker（ただし隠蔽） | コールドスタートあり | 15分・ステートレス | 低い（15分・イベント駆動） |
| MicroVMs | 強い（Firecracker を開放） | スナップショットから復元 | 8時間まで保持 | 低い（8時間・ARM64・メモリ上限） |
（出典: AWS News Blog、Lambda MicroVMs デベロッパーガイド、2026-09-05 確認）
まとめ
今回は、AWS Lambda に新しく加わった MicroVMs について、これまでの Lambda と何が異なるのかを調査しました。
リリースのきっかけとしては、AIの普及があるかと思います。 MicroVM を利用して、AI エージェントが作成するコードの実行環境を構築します。その際、実行者ごとに隔離された環境、会話をしながら合間は停止できる、実行を依頼したら実行前の状態は残しつつ続きを始めるといった使い方の理想は MicroVMs といった選択肢として一番のような気がします。
Firecracker が作る MicroVM は、以前から Lambda を支えてきた技術ですが、個人的に一番大きいと思ったのは、これまで AWS が責任範囲としていた Lambda の実行環境そのものを、開発者が run と terminate などで自分の手で扱えるようにしたところだと思っています。
AWS Lambda に新しく加わった MicroVMs についてですが、機能の追加というより AWS と開発者の責任範囲を新たに引き直したものだと感じました。