AWS Lambda MicroVMsとは何か
AWSは2026年6月、AWS Lambdaの新しいサーバレスコンピュートプリミティブとして「AWS Lambda MicroVMs」を発表しました。これは、ユーザーやAIが生成したコードを、隔離されたステートフルな実行環境で安全に動かすための仕組みです。サーバの管理やキャパシティのプロビジョニングといった運用負担を負わずに、独立した仮想マシンを必要なときだけ立ち上げて使える点が大きな特徴になります。
従来のサーバレスは、短時間で終わるステートレスな処理を前提に設計されてきました。一方で、生成AIが書いたコードをその場で実行したり、ユーザーごとに独立した作業環境を長時間維持したりといった用途では、強い隔離と状態の保持が同時に求められます。Lambda MicroVMsは、サーバレスの手軽さを保ちつつ、この「隔離」と「ステートフル」という二つの要件を両立させることを狙ったサービスです。
本記事では、Lambda MicroVMsの基盤技術であるFirecrackerによる分離の仕組みから、スナップショットを使った高速起動、イメージの作成と接続の流れ、従来のLambda関数との使い分けまでを順番に解説します。
Firecrackerによる隔離とステートフルな実行環境
Lambda MicroVMsの土台になっているのは、軽量仮想化技術のFirecrackerです。Firecrackerは、これまでにLambda関数の月間15兆回を超える呼び出しを支えてきた実績のある技術であり、その同じ基盤の上にMicroVMsが構築されています。各MicroVMはそれぞれ独立したカーネルを持ち、ユーザー間でカーネルやリソースを共有しません。これにより、あるユーザーが持ち込んだ信頼できないコードは自分の実行環境の中だけに閉じ込められ、ほかの環境や基盤システムへはアクセスできない構造になっています。
もう一つの柱がステートフルであることです。稼働中のMicroVMは、メモリ、ディスク、実行中のプロセスをユーザーのセッションを通じて保持します。最大で8時間にわたって実行を継続でき、これはLambda関数の実行時間が最大15分であることと比べると大きな違いです。長時間の対話的な処理や、状態を積み上げていくワークフローを、サーバレスのまま扱えるようになります。
スナップショットによる高速起動とsuspend・resume
強い隔離とステートフルを両立させると、起動の遅さが気になるところです。Lambda MicroVMsはこれをスナップショットで解決しています。イメージを作成する際にDockerfileを実行してアプリケーションを初期化し、その稼働状態のメモリとディスクをFirecrackerのスナップショットとして保存します。以降そのイメージから起動するMicroVMは、毎回コールドブートするのではなく、初期化済みのスナップショットから再開します。そのため起動はほぼ即時で、重いランタイムやモデルの読み込みを毎回やり直す必要がありません。
アイドル時の扱いも特徴的です。トラフィックが来ない間は、メモリとディスクの状態を保持したままMicroVMをsuspend（一時停止）でき、再びリクエストが届いたタイミングでresume（再開）します。利用者から見ると中断は意識されず、インストール済みのパッケージやロード済みのモデル、作業中のファイルがそのまま使える状態で戻ってきます。一時停止中は実行のコストを抑えられるため、状態を捨てずにコスト効率を高められる点が現実的なメリットになります。
MicroVM Imageの作成からHTTP接続までの流れ
利用の起点はMicroVM Imageの作成です。アプリケーションのコードとDockerfileをzipにまとめてAmazon S3に置き、CLIからイメージ作成を指示します。するとLambda側がコードを取得し、Dockerfileの実行とアプリケーションの初期化、そしてスナップショットの作成までを自動で進めます。ビルドの進行状況はAmazon CloudWatch Logsへストリーム出力されるため、初期化の様子を追いながら確認できます。
aws lambda-microvms run-microvm \
--image-identifier <MicroVMイメージのARN> \
--execution-role-arn <実行用IAMロールのARN> \
--idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'イメージができたら、上のように起動を指示します。起動するとMicroVMの識別子と専用のエンドポイントURLが返り、面倒なネットワーク設定は不要です。アプリケーションへはHTTPで接続します。CLIで短命の認証トークンを生成し、それを X-aws-proxy-auth ヘッダに付けてHTTPSリクエストを送ることで、対象のMicroVMに直接アクセスできます。あわせて、起動時に指定するidle-policyで、自動一時停止までのアイドル時間や一時停止の継続時間、自動再開の有無といったライフサイクルを制御できます。
従来のLambda関数との違いと使い分け
Lambda MicroVMsは、既存のLambda関数を置き換えるものではなく、補完する位置づけです。Lambda関数は、イベント駆動でリクエストに短時間で応答するワークロードに最適化されています。これに対してMicroVMsは、エンドユーザーやセッションごとに独立した環境を割り当て、長時間にわたって状態を保ちながら実行するマルチテナント型の用途に向いています。信頼できないコードを動かす隔離の強さも、MicroVMsならではの強みです。
両者は組み合わせて使えます。たとえば、イベント駆動のバックボーンをLambda関数で構築しつつ、その中から隔離が必要な処理だけをMicroVMの実行環境へ振り分けるといった設計が考えられます。短く終わる定型処理はLambda関数で、状態を抱えた長時間の対話的処理はMicroVMsでと役割を分けることで、サーバレスの利点を保ったまま扱える範囲を広げられます。どちらを使うべきかは、実行時間の長さ、状態保持の必要性、そして隔離の強度という観点で見極めるとよいでしょう。
ユースケースと対応リージョン、導入時の考慮点
想定される代表的な用途は、AIコーディングアシスタントやインタラクティブなコード実行環境、データ分析プラットフォーム、脆弱性スキャナ、ユーザーが持ち込んだスクリプトを動かすゲームサーバーなどです。いずれも、外部から渡されるコードを安全に隔離しつつ、セッションの状態を保ちたいという共通点があります。生成AIが書いたコードをその場で試す場面が増えるなかで、こうしたセキュアなサンドボックスの需要は今後さらに高まると考えられます。
対応リージョンは、米国東部（バージニアとオハイオ）、米国西部（オレゴン）、ヨーロッパ（アイルランド）、アジア太平洋（東京）です。日本国内のリージョンで利用できるため、国内向けのサービスでも検討しやすい状況になっています。アーキテクチャはARM64で、1つのMicroVMあたり最大16 vCPU、32GBメモリ、32GBディスクまで利用できます。
導入にあたっては、まず隔離とステートフルが本当に必要なワークロードかを見極めることが出発点になります。短時間で完結する処理であれば従来のLambda関数で十分なことも多く、MicroVMsの真価は長時間かつ状態を抱える用途で発揮されます。料金については、本記事の執筆時点で公式に具体的な単価が示されていないため、最新の情報はAWS Lambdaの料金ページで確認してください。アイドル時にsuspendを活用してコストを抑える運用設計も、あわせて検討するとよいでしょう。
