AWS Lambda MicroVMs — サーバレス×ステートフル×VM隔離が実用に足るかを作る側から見る
AWSが「AWS Lambda MicroVMs」を発表した。サーバレスの管理不要な手軽さを保ちつつ、最大8時間のステートフルな実行環境をカーネルレベルで分離されたMicroVMとして提供するサービスだ。
出典: AWS Lambda MicroVMs登場。サーバレスの手軽さでステートフルかつ隔離された実行環境を提供
要点 (事実のみ)
- AWSがサーバレス基盤上でステートフルかつ隔離された実行環境を提供する新サービス「AWS Lambda MicroVMs」を発表
- 仮想マシンにFirecrackerを採用し、カーネルレベルの分離を実現。最大8時間ステートを維持できる
- アイドル状態でもメモリとディスクの内容が保持され、トラフィック到着時に瞬時にセッションを再開可能
- 1つあたり最大16 vCPU・32 GBメモリ・32 GBディスク（ARM64アーキテクチャ）
- 東京リージョンを含む複数リージョンで利用可能。DockerfileとAmazon S3でMicroVMイメージを管理
徐 聖博の見解
率直に言って、このサービスが刺さる用途はかなり具体的だと感じた。「AIが生成したコードの安全な隔離実行」という公式ユースケースは、私たちがいまPoC・初期顧客と進めているAIエージェント基盤で真っ先に突き当たる課題そのものだ。
エージェントがコードを生成・実行するループを回す場合、従来の選択肢は大きく二つだった。①コンテナをプロビジョニングして管理する（運用負荷が高い）、②既存のLambdaで関数を切り出す（ステートレスなので会話文脈やファイルが消える）。Lambda MicroVMsはこの両者の嫌なところを消す設計になっている。Firecrackerは元々AWS FargateやLambdaの内部基盤として実績があるため、「新しい実験的技術」ではなく枯れたコンポーネントの公開APIという理解が正確だ。その点で、研究者時代から「再現条件と実績」を重視してきた私としては、技術的な信頼性への懸念は低い。
ただし、作る側として冷静に見ると注意点もある。最大8時間という上限は「一時的・短時間ワークロード向け」と公式が明言しており、永続セッションを前提にした設計にはそのまま使えない。また、ARM64限定・リージョン制限あり・アイドル時のコスト設計は実際に触ってみないとわからない部分が残る。中小〜中堅企業向けに受託開発や自社エージェントSaaSを提供する立場では、「デモで動く」と「本番ワークロードのコスト・監視体制が成立する」の間に常に大きな距離がある。GA前に実運用コストとコールドスタート挙動のベンチマークを取ることが先決だ。
マルチテナントSaaSへの応用という点でも可能性はある。テナントごとに独立したMicroVMを瞬時に用意できるなら、共有コンテナで悩んでいたリソース分離とセキュリティ境界の問題を低コストで解決できる。ただしこれも、テナント数が増えたときの並列起動レイテンシとコストの実測値が判断の前提になる。
(編集レンズ: 実装・運用視点 / AIを「作る側」の目線)
