AWS Lambda MicroVMs: serverless にステートフルで隔離されたサンドボックスが加わる

AWS Lambda MicroVMs は、仮想マシンレベルの隔離、snapshot からのほぼ即時の起動、そして中断と再開が可能なステートフル実行をもたらす、新しい serverless コンピュートプリミティブです。これは Firecracker 上で動作します。Firecracker は、すでに月間 15 兆回を超える Lambda 呼び出しを支えている軽量仮想化技術です。要約すると、Lambda は各セッションに専用で隔離された長寿命のサンドボックスを割り当てる能力を獲得し、しかもそれを自分で仮想化を管理することなく実現します。

自分のアプリケーションが書いていないコードを安全に実行しようとしたことがあるなら、つまりマルチテナントのコード実行、インタラクティブなノートブック、脆弱性スキャナーなどを扱ったことがあるなら、これがなぜ重要なのかすでにわかっているはずです。これまでの正直な答えは「コンテナや VM を立ち上げ、オーケストレーション、隔離、ライフサイクルの配管を自分で作り込む」というものでした。MicroVMs はそれを 1 回の API 呼び出しに集約します。

実際に何が新しいのか

通常の Lambda 関数はステートレスで短命、イベント駆動です。その用途では卓越しています。一方で、数分から数時間にわたって生き続け、メモリ内に状態を保持し、信頼できないコードをカーネルレベルで隔離する必要があるセッションには、間違ったツールです。MicroVMs は同じサービス内にある別のプリミティブで、まさにそのギャップを狙ったものです。AWS は、これを今日まで単一の AWS コンピュートサービスでは同時に提供されていなかった 3 つの機能として位置づけています。

1. VM レベルの隔離

各セッションは専用の MicroVM 内で動作し、ユーザー間でカーネルもリソースも共有しません。それが Firecracker の保証です。あるテナントの信頼できないコードはそのテナント自身の環境に封じ込められ、他の環境やホストへの経路はありません。コンテナはカーネルを共有しますが、MicroVM は共有しません。自分が書いていないコードを実行する場合、その境界こそがすべての要点です。

2. snapshot による高速起動と再開

モデルはイメージを作ってから起動する方式です。Dockerfile と Amazon S3 上のコードアーティファクトから MicroVM Image をビルドします。Lambda は Dockerfile を実行し、アプリケーションを初期化し、実行中のメモリとディスクの状態の Firecracker snapshot を取得します。そのイメージから起動されるすべての MicroVM は、コールドブートする代わりに事前初期化された snapshot から再開します。数ギガバイトに及ぶインタラクティブなセッションでも、ライブに感じられるほど高速に戻ってきます。これは SnapStart のアイデアを論理的な極限まで進めたものです。プロセスを起動しているのではなく、実行中のプロセスを復元しているのです。

3. ステートフルで中断可能な実行

実行中の MicroVM は、セッションをまたいでメモリ、ディスク、プロセスを保持します。アイドル状態になると状態を保ったまま中断でき、トラフィックが戻ると再開できます。インストール済みのパッケージ、ロード済みのデータ、作業中のファイルはすべてそのまま残ります。MicroVMs は合計で最大 8 時間のランタイムをサポートし、設定可能なアイドル時間の経過後に自動的に中断します。これが従来のステートレス serverless の前提を、良い意味で崩す部分です。

運用するとどう見えるか

ワークフローの大半は 2 つの CLI 呼び出しで完結します。まずイメージをビルドします。

aws lambda-microvms create-microvm-image \
  --code-artifact uri=<path/to/s3/artifact.zip> \
  --name my-sandbox \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn <build role ARN>

ビルドログは /aws/lambda/microvms/<image-name> 配下で CloudWatch にストリーミングされ、完成したイメージは固有の ARN とバージョンを持って現れます。次に、そこから MicroVM を起動します。

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-sandbox \
  --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \
  --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

Lambda は固有の MicroVM ID と専用のエンドポイント URL を返し、snapshot から再開しているためアプリケーションはすでに実行中です。ネットワークの設定は不要です。ライフサイクルの制御は idle-policy にあります。中断するまでどれだけアイドルでいるか、終了するまでどれだけ中断状態を保つか、そして次のリクエストで自動的に再開するかどうかを指定します。

どこに収まり、どこに収まらないか

MicroVMs を選ぶべきとき	通常の Lambda にとどまるべきとき
信頼できないコードやユーザー提供のコードを実行し、カーネルレベルの隔離が必要なとき	コードが信頼でき、作業が短くステートレスな変換であるとき
セッションが数分から数時間にわたってメモリ内に状態を保持する必要があるとき	各呼び出しが独立していて数秒で完了するとき
フリートを自分で運用せずにユーザーごとの専用環境がほしいとき	マネージドな実行環境を共有することで問題ないとき
アイドル期間が当たり前で、アイドルに課金し続ける代わりに中断と再開を使いたいとき	トラフィックが安定していて、リクエストとレスポンスがすべての形であるとき

MicroVMs は関数の代替ではありませんし、24 時間 365 日稼働するサーバーを安く動かす手段でもありません。8 時間という上限と中断・再開のモデルはセッションのために作られています。ユーザーが開いて放置するコーディングサンドボックス、10 分間動くスキャン、2 時間動いてから静かになる分析ジョブといったものです。ワークロードが常に忙しい長時間稼働のサービスなら、それはやはり ECS や EC2 の領域です。

知っておくべき snapshot の注意点

すべての MicroVM は事前初期化された snapshot から再開するため、アプリが初期化中に行うことで「毎回新しいこと」を前提にしている処理は、思わぬ結果を招くことがあります。起動時に生成された一意の ID、ブート時に開かれたネットワーク接続、ランダムシード、一度だけロードされた一時データなどは、すべて snapshot に凍結され、複数の起動をまたいで再利用される可能性があります。これは SnapStart のユーザーがすでに知っているのと同じ種類の落とし穴です。セッションごとに一意または新鮮である必要があるものは、初期化中ではなく再開後に生成してください。AWS はこのためのフックを公開しており、接続指向のものやセキュリティに関わるものには、それを使いたくなるはずです。

まとめ

Lambda MicroVMs は、serverless がステートレスで短命なだけの存在から脱却したことを示す、これまでで最も明確なシグナルです。今や、本物の隔離、snapshot 速度の起動、中断・再開可能な状態を備えたマネージド Firecracker サンドボックスが、2 つの API 呼び出しと 1 つの idle policy として手に入ります。マルチテナントのコード実行を構築する人にとって、これは最も難しく、最も差別化につながらない部分、つまり隔離とライフサイクルの配管を取り除きます。プロダクトを作り、MicroVM フリートの運用は Lambda に任せましょう。

次に読む

AWS Monthly (Nov '25): The Stateful Serverless Revolution、MicroVMs が乗っているトレンドラインについて。
Securing Docker Containers、共有カーネルがなぜ MicroVMs が取り除くために作られた境界なのかについて。

同じ発表を AI とエージェントの観点から、つまり MicroVMs がなぜ AI 生成コードの実行のために作られているのかについては、ercan.ai のフィールドノートを参照してください。AWS、serverless、プラットフォーム関連の相談、あるいはただ挨拶したいだけでも、ercanermis.com から始めてください。