Lambda MicroVMs は関数の長時間版ではない — 8時間・状態保持・VM 分離の新しい実行単位
AWS Lambda の MicroVMs が従来の関数と何が違うのかを整理し、コールドスタートとセキュリティ境界、そして課金の面から採否を判断する材料をまとめます。
- 公開日
AWS Lambda に MicroVMs という実行単位が加わりました。名前に Lambda が付いていますが、従来の関数とは API 名前空間が違い、課金体系も別です。実質的には別サービスです。
この記事では、Lambda を日常的に使っている個人開発者が「自分のワークロードで使うべきか」を判断できるよう、3点に絞って整理します。従来の関数と何が違うのか、どういう条件で優位になるのか、いくらかかるのか。読み終えると、手元の処理を MicroVMs・従来の Lambda 関数・Amazon EC2 のどこに置くかを、根拠つきで切り分けられます。
数値の出典は各所に添えますが、確認日はいずれも 2026-08-24 です。一般提供の開始が 2026-06-22 と新しく、仕様・上限・料金が動きうる領域なので、実装前に一次ソースを引き直してください。
新しいのは技術ではなく、実行環境を操作できるようになったこと
MicroVM は、ハードウェア仮想化で隔離された最小構成の仮想マシンです。Lambda MicroVMs はこれを Firecracker という仮想マシンモニタで起動します。Firecracker は AWS が開発してオープンソース化したもので、Linux の KVM を使って軽量な仮想マシンを立ち上げます。各仮想マシンが自分のゲストカーネルを持つため、カーネルの脆弱性がテナントの境界を越えません（出典: Firecracker 公式サイト および NSDI ’20 論文、2026-08-24 確認、リージョンは該当なし）。
ここで意外なのは、従来の Lambda 関数も1呼び出しごとに Firecracker の上で動いてきた点です。AWS は月間15兆回を超える Lambda リクエストを同じ基盤で支えてきたと説明しています（出典: AWS Compute Blog、2026-08-24 確認、リージョンは該当なし）。つまり隔離技術そのものは新しくありません。
新しいのは抽象化の層です。従来の関数では Firecracker が開発者から見えず、ライフサイクルを制御できませんでした。状態も持てず、フル OS 機能も使えません。MicroVMs では run / suspend / resume / terminate を開発者が直接叩けます。パッケージの導入、ファイルシステムのマウント、シェルや pty も使えます。
従来の関数との違い
| 観点 | 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 一般提供時点の仕様）
つまり、既存の関数を長時間版に置き換える機能ではありません。 想定されているのは、アプリ開発者が書いていないコードを走らせる用途です。利用者や LLM が生成したコードを、セッション単位で隔離して実行します。イベント駆動の処理は従来の関数に残し、信頼できないコードを実行する工程だけを MicroVMs に切り出す構成が公式の推奨です。
強い隔離・速い起動・状態の保持を1つで満たす
これまで、利用者ごとに専用の実行環境を配ろうとすると、3つの要求のどれかを諦める必要がありました。
| 選択肢 | 隔離 | 起動 | 状態の保持 |
|---|---|---|---|
| EC2 などの仮想マシン | 強い（ハードウェア仮想化） | 数分（AMI ブートと初期化） | 保持できる |
| コンテナ | ホストカーネルを共有 | 数秒 | 保持できる |
| Lambda 関数 | Firecracker（ただし隠蔽） | コールドスタートあり | 15分・ステートレス |
| MicroVMs | 強い（Firecracker を開放） | スナップショットから復元 | 8時間まで保持 |
（出典: AWS News Blog、2026-08-24 確認、リージョンは該当なし）
ブラウザ上の開発環境、AI コーディングアシスタントのサンドボックス、脆弱性スキャナがこの隙間に落ちていました。いずれも利用者が席を外す時間が長く、戻ってきたら続きから再開したい処理です。MicroVMs はここを埋める設計です。
起動が速いのは、初期化済みの状態を丸ごと保存しているから
MicroVMs は、イメージを作ってから起動する二段構えです。Dockerfile とコードを Amazon S3 に置いて create-microvm-image を呼びます。すると Lambda 側が Dockerfile をビルドし、アプリを起動します。その初期化済みのメモリとディスクが、Firecracker のスナップショットとして保存されます。以降そのイメージから起動する仮想マシンは毎回このスナップショットから復元されるので、依存関係の読み込みやモデルのロードをやり直しません（出典: コアコンセプト、2026-08-24 確認、リージョンは該当なし）。
無操作が続くと、設定したアイドルポリシーに従って自動でサスペンドされます。サスペンド中は状態を保ったままコンピュートの課金が止まり、次のリクエストで自動的にレジュームします。
状態を保存する副作用として、一意の値をイメージに焼き込めない
スナップショットから復元する方式には、設計上の制約が伴います。ユニーク ID・シークレット・乱数シードは、仮想マシンごとに異なるべき値です。これらをイメージに含めると、同じイメージから起動した全ての仮想マシンで値が共有されます。こうした値は起動後の /run フックで生成します。ビルド時やサスペンド前に確立した認証情報・ネットワーク接続も、レジューム時には期限切れや切断になりうるため、起動時に取り直す前提で組みます。
もう1点、/run フックが失敗するかタイムアウトすると、仮想マシンは RUNNING に到達せず終了処理へ落ちます。フックのタイムアウトとエラー処理は最初から実装しておく必要があります。
課金は秒単位で、常時動かすなら EC2 のほうが安い
課金はコンピュート・スナップショット・データ転送の3要素です。ミリ秒ではなく秒単位で、ベースラインのコンピュートを常時課金し、ピーク時の超過分を従量で足します。サスペンド中はコンピュートの課金が止まり、ストレージだけが残ります。動作環境は ARM64（Graviton）のみです。既定のベースラインは 2GB メモリ / 1 vCPU で、ピーク時は4倍まで垂直にスケールします。上限は1台あたり 16 vCPU / 32GB メモリ / 32GB ディスクです（出典: AWS Compute Blog、2026-08-24 確認、リージョンは該当なし）。
ローンチ時の提供リージョンは5つでした。米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（アイルランド）、アジアパシフィック（東京）です。2026-08-19 に5リージョンが追加され、計10になりました（出典: 追加リージョンの告知、2026-08-24 確認）。東京が最初から入っているので、国内向けの個人開発でも試せます。
コスト感の目安を1つ挙げます（この段落の数値は第三者の試算で、元記事の URL は未確認です。判断に使う前に料金ページで再計算してください）。InfoQ が引用する試算では、1 vCPU + 2GB の最小構成を常時稼働させると1日あたり 3.03 ドルです。Fargate のスポットの9倍を超えます。有利になるのはアイドル時間が長いセッション型の処理です。 平均 CPU 使用率が高く常時稼働に近い処理なら、EC2 や Fargate のほうが安くなります。 判断は自分のワークロードのアイドル比率で行ってください。
数分ごとのサスペンドとレジュームを繰り返す設計では、スナップショットの読み書き課金が積み上がります。アイドルのタイムアウトは秒ではなく分の単位で設定するのが無難です。
公式には確認できていない数値
判断材料として重要なのに、一次ソースで確定できなかった項目があります。ここは推測で埋めずに、確認できていないと書きます。
具体的な単価は料金ページ側にあります。 AWS の公式ブログとドキュメントは課金の構造を明記していますが、本文にドル単価を載せていません。第三者の検証（Northflank）は、US East の ARM について次の単価を挙げています。ただし別の試算（murraycole.com）とは食い違いがあり、いずれも元記事の URL は未確認です。
| 項目 | 単価（第三者による値） |
|---|---|
| コンピュート（vCPU） | 1 vCPU 秒あたり 0.0000276944 ドル |
| コンピュート（メモリ） | 1 GB 秒あたり 0.0000036667 ドル |
| スナップショットストレージ | 1 GB 月あたり 0.08 ドル |
見積もりに使うなら Lambda の料金ページで直接確認してください。
起動とレジュームの実時間も公式には出ていません。 開発者ガイドは「復元する状態のサイズと /resume フックの時間に依存する」と述べるだけです。AWS の公式表現も「ほぼ瞬時」に留まります。第三者の観測（Aidan Steele）では、起動要求から RUNNING まで約2秒という報告があります。なお Firecracker 公式仕様の「API 呼び出しからゲストの init 開始まで 125 ミリ秒以下」は Firecracker 単体の値です。スナップショット復元を含む Lambda MicroVMs の起動時間とは別物なので、混ぜて見積もらないでください。
送信ネットワークの既定挙動にも報告があります。 同じ第三者の記事では、外向きの UDP が既定でブロックされ、DNS が壊れるという挙動が報告されています。ローンチ告知には書かれていない内容です。egress の設計は実測して確かめる前提で見積もってください。
採用する条件と、見送る条件
採用を検討する価値があるのは、次のいずれかに当てはまる場合です。利用者や LLM が生成した任意のコードを実行する。セッションごとに強い隔離が要る。メモリやディスクの状態を数分から8時間の範囲で保持したい。対話的で、復帰のレイテンシが体感に直結する。アイドルが長く、その分のコストを落としたい。
逆に見送るべき条件もはっきりしています。短時間・ステートレス・イベント駆動なら従来の Lambda 関数のままが安く、単純です。CPU を長時間フルに回し続けるなら EC2 のほうがコストで勝ちます。エージェントのホスティングがマネージドで欲しいだけなら Bedrock AgentCore Runtime が該当します。
見落とされやすいのは、オーケストレーションが利用者の実装責任である点です。MicroVMs が提供するのは仮想マシン単体で、どの利用者にどの仮想マシンを割り当てるか、ルーティング、後片付け、監視は自分で書きます。PoC は動いても本番で破綻する箇所がここなので、工数の見積もりに最初から入れてください。
試すなら、まず public.ecr.aws/lambda/microvms:al2023-minimal を基点にしたアプリを東京リージョンで1つ作ります。ポート 8080 で待ち受けるだけの中身で足ります。イメージ作成から起動、認証トークンの生成、curl での疎通までを一気に通すのが最短です。そのうえでサスペンドとレジュームの実測を取り、アイドル比率でコストを試算すれば、採否が数値で決まります。