Amazon Web Services ブログ

完全なライフサイクル制御による分離されたサンドボックスの実行: AWS Lambda が MicroVM を導入

本記事は、2026 年 6 月 22 日に公開された Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs を翻訳したものです。翻訳は Solutions Architect の齋藤 拓巳が担当しました。

Voiced by Polly

本日、AWS Lambda MicroVMs を発表します。これは AWS Lambda 内の新しいサーバーレスコンピューティングプリミティブで、ユーザーや AI が生成したコードを分離されたステートフルな実行環境で実行できます。
仮想マシンレベルの分離、ほぼ瞬時の起動と再開、環境のライフサイクルと状態の直接制御が可能で、インフラストラクチャの管理や複雑な仮想化技術の専門知識は不要です。
Lambda MicroVMs は Firecracker を基盤としています。これは、月間 15 兆回を超える Lambda 関数の呼び出しを支えてきた軽量仮想化技術と同じものです。

この機能が求められる背景

ここ数年、新しい種類のマルチテナントアプリケーションが登場しています。これらのアプリケーションはすべて、エンドユーザーごとに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する必要があるという共通点を持っています。AI コーディングアシスタント、インタラクティブなコード環境、データ分析プラットフォーム、脆弱性スキャナー、ユーザー提供のスクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在この機能を構築するには、難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動しますが、カーネル共有アーキテクチャのため、信頼できないコードを安全に封じ込めるには大規模なカスタムのセキュリティ強化が必要です。Functions as a Service はイベント駆動型のリクエスト・レスポンスワークロードに最適化されていますが、ユーザーとのインタラクション間で環境の状態を保持する必要がある長時間実行のインタラクティブセッション向けには設計されていません。その結果、開発者はパフォーマンスと分離のトレードオフを受け入れるか、エンドユーザーに低レイテンシーの体験を提供しながら分離された実行を実現するために、カスタム仮想化インフラストラクチャの構築と運用に多大なエンジニアリングリソースを投資するかの選択を迫られます。これは深い専門知識を必要とし、本来構築しようとしているプロダクトからエンジニアリング時間を奪う取り組みです。

Lambda MicroVMs は、まさにこのギャップを埋めるために専用設計されています。
各 MicroVM は、単一のエンドユーザーまたはセッションに対して独自の分離された環境を提供し、高速に起動し、セッションの間メモリとディスクの状態を保持し、ユーザーが離席した際には低コストのアイドル状態に一時停止します。
同じ Firecracker テクノロジーが既に AWS Lambda Functions の基盤となっているため、このスタックを大規模に運用してきたサービスの運用成熟度をそのまま活用できます。

試してみましょう

まず、AWS Lambda コンソールに移動すると、左側のナビゲーションメニューに Lambda MicroVMs が表示されるようになっています。最初に MicroVM イメージを作成する必要があります。

Flask ウェブアプリとその Dockerfile を zip ファイルにパッケージ化し、Amazon Simple Storage Service (Amazon S3) バケットにアップロードしました。

Flask API – app.py

import logging 

 from flask import Flask, jsonify 

 app = Flask(__name__)
 logging.basicConfig(level=logging.INFO)


@app.route("/")
 def hello():
    app.logger.info("Received request to hello world endpoint")
    return jsonify(message="Hello, World!")


 if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Dockerfile


 FROM public.ecr.aws/lambda/microvms:al2023-minimal 
 RUN dnf install -y python3 python3-pip && dnf clean all 

 WORKDIR /app 

 COPY requirements.txt .
 RUN pip install --no-cache-dir -r requirements.txt 

 COPY app.py .

 EXPOSE 5000 

 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

以下のコマンドを使用して MicroVM イメージを作成しました。

aws lambda-microvms create-microvm-image \ 
--code-artifact uri= --name  \ 
--base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ 
--build-role-arn

上の画像のように、AWS コンソールで MicroVM Image を作成することもできます。
コマンドを実行すると、Lambda が zip を取得し、Dockerfile を実行し、アプリケーションを初期化して、実行中のディスクとメモリの状態の Firecracker スナップショットを取得しました。
ビルドログは /aws/lambda/microvms/ 配下の Amazon CloudWatch にリアルタイムでストリーミングされ、イメージの準備が完了すると、Amazon Resource Name (ARN) とバージョン番号とともにコンソールに表示されました。

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

起動は AWS コンソールまたは CLI からも行えます。
ここでは、イメージ ARN と、15 分間操作がないと自動的にサスペンドし、次のリクエストを受信すると自動的にレジュームするよう設定したアイドルポリシーを渡しました。
ネットワークの設定は不要です。
Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、新しい MicroVM を起動します。この MicroVM はスナップショットからレジュームされるため、Flask アプリはすでに実行された状態になっています。
実際、起動が完了した瞬間には Flask アプリはすでに動作していました。
たった 1 回の API 呼び出しで、完全に初期化されブートストラップされたコンピューティング環境が手に入ります。

トラフィックを送信するために、CLI で短期間有効な認証トークンを生成し、X-aws-proxy-auth ヘッダーを使用して通常の HTTPS リクエストに添付しました。
リクエストはすぐに Flask アプリに到達しました。
その後、MicroVM をサスペンドのしきい値を超えてアイドル状態にしたところ、MicroVM はサスペンドされ、メモリとディスクの状態がスナップショットとして保存されました。
次に別のリクエストを送信すると、アプリケーションの状態が完全に保持されたまま再開されました。
クライアント側からは、一時停止が発生したことはまったくわかりませんでした。

仕組み

内部的には、Lambda MicroVMs は、これまで単一の AWS コンピューティングサービスでは同時に提供されていなかった 3 つの機能を実現しています。
1 つ目は、Firecracker による仮想マシンレベルの分離です。
各セッションは専用の MicroVM で実行され、ユーザー間でカーネルやリソースが共有されることはありません。
そのため、あるユーザーが提供した信頼されていないコードはそのユーザーの実行環境内に封じ込められ、他の環境や基盤システムへのアクセスはできません。
2 つ目は、高速な起動と再開です。
このモデルは「イメージを作成してから起動する」方式です。Dockerfile と Amazon S3 に zip アーティファクトとしてパッケージ化されたコードを提供して MicroVM Image を作成すると、Lambda が Dockerfile を実行し、アプリケーションを初期化し、実行中の環境のメモリとディスクの状態の Firecracker スナップショットを取得します。
そのイメージから起動される後続のすべての MicroVM は、コールドブートではなく事前に初期化されたスナップショットから再開されるため、起動とアイドル状態からの再開の両方でほぼ瞬時の起動レイテンシーを実現します。
数ギガバイト規模のインタラクティブセッションでも、エンドユーザーが快適に操作できるほど素早くオンラインに復帰します。
3 つ目は、ステートフルな実行です。
実行中の MicroVM は、ユーザーのセッション全体を通じてメモリ、ディスク、実行中のプロセスを保持します。
アイドル期間中、MicroVM はメモリとディスクの状態をそのまま維持したままサスペンドでき、トラフィックが到着すると再開されます。
インストール済みのパッケージ、ロード済みのモデル、作業中のファイルセットは、ユーザーがセッションを再開した際にすぐに利用可能です。
MicroVM は最大 8 時間の合計実行時間をサポートし、設定可能なアイドル時間の後に自動的にサスペンドできるため、数分で完了するソフトウェア脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間のアイドル期間を伴うインタラクティブなコーディングセッションなど、多様なプロダクトを簡単に構築できます。
Lambda MicroVMs は事前に初期化されたスナップショットから起動されるため、初期化時に一意のコンテンツを生成したり、ネットワーク接続を確立したり、一時的なデータをロードしたりするアプリケーションでは、互換性のためにサービスが提供するフックとの統合が必要になる場合があります。

Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、独自の API を備えています。
Lambda Functions は引き続きイベント駆動型のリクエスト・レスポンスワークロードに最適な選択肢であり、Lambda MicroVMs はマルチテナントアプリケーション向けに特化して構築されています。具体的には、各エンドユーザーやセッションに対して、ユーザーまたは AI が生成したコードを実行するための独立した分離環境を提供する必要があるアプリケーションに適しています。
この 2 つは互いを補完する関係にあります。
イベント駆動型のバックボーンに Lambda Functions を使用しているアプリケーションは、信頼できないコードを分離して実行する必要があるステップで Lambda MicroVMs を呼び出すことができます。
お客様がアプリケーションを持ち込み、サービスが実行環境を提供します。

提供開始

AWS Lambda MicroVMs は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) の各リージョンで本日より利用可能です。ARM64 アーキテクチャ上で、MicroVM あたり最大 16 vCPU、32 GB のメモリ、32 GB のディスクを提供します。
アイドル状態の MicroVM は、API 呼び出しによる明示的なサスペンド、またはライフサイクルポリシーによる自動サスペンドが可能で、完全な状態を保持したまま高速に再開できるため、実行コストを削減できます。
料金の詳細は AWS Lambda の料金ページをご覧ください。

開始するには、AWS Lambda コンソールにアクセスするか、Lambda MicroVMs 製品ページで詳細をご確認ください。
ドキュメントについては、Lambda MicroVMs デベロッパーガイドを参照してください。

著者について

Micah Walter

Micah Walter

Micah Walter は、ニューヨーク市地域およびその他の地域のエンタープライズのお客様を支援するシニアソリューションアーキテクトです。クラウドへの移行のあらゆる段階で、エグゼクティブ、エンジニア、アーキテクトに対してアドバイスを行っており、サステナビリティと実践的な設計に深く注力しています。余暇には、アウトドアや写真撮影、家中を走り回る子どもたちを追いかけて楽しんでいます。

翻訳者について

齋藤 拓巳

ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。