新機能 AWS Lambda MicroVMsで、Flaskアプリを動かしてサスペンド・レジュームまで試してみた

AWS Lambdaの新機能 MicroVMsを東京リージョンで実際に動かしました。Dockerfileからイメージ作成、MicroVM起動、HTTPリクエスト、サスペンド・レジュームまで一連のライフサイクルをCLIで確認しています

suzuki.ryo
2026/06/23

はじめに

2026年6月22日、AWS Lambdaの新しいコンピューティングプリミティブとして Lambda MicroVMs が発表されました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/aws-lambda-microvms/https://aws.amazon.com/jp/about-aws/whats-new/2026/06/aws-lambda-microvms/

Lambda MicroVMsは、ユーザーやAIが生成したコードをVMレベルのアイソレーションで実行できるサーバーレス環境です。Firecracker仮想化技術をベースとしており、スナップショットからの高速起動とステートフルなサスペンド・レジュームを提供します。

従来のLambda関数との位置づけの違いを整理します。

観点 Lambda 関数 Lambda MicroVMs
設計思想 イベント駆動・ステートレス ステートフルな隔離サンドボックス
アイソレーション Firecracker MicroVM（再利用あり） Firecracker MicroVM（インスタンスごとに隔離）
状態保持 保証なし サスペンド中もメモリ・ディスク状態を保持
最大実行時間 15分 8時間
リソース上限 最大6 vCPU / 10 GBメモリ 最大16 vCPU / 32 GBメモリ / 32 GBディスク
ライフサイクル制御 AWS 管理 開発者が明示的に制御
接続方式 イベントソース / 関数 URL 専用 HTTPS エンドポイント

Lambda MicroVMsは既存のLambda関数の置き換えではなく、ユーザーごとに隔離された長時間のインタラクティブ環境が必要な場面に向いています。

本記事では、公式ブログのFlaskアプリサンプルをap-northeast-1（東京）で動かし、ライフサイクルを確認します。以下、S3バケット名は YOUR-BUCKET-NAME、アカウントIDは 123456789012 で表記します。

AWS CLIは2.35.10を使用しました（lambda-microvms サブコマンドに対応したバージョンが必要です）。

https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.htmlhttps://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html

検証内容

IAM ロール作成

Lambda MicroVMsのイメージビルド時に使用するIAMロールを作成します。Lambdaサービスがこのロールを引き受け、S3からコードを取得し、CloudWatch Logsにビルドログを出力します。

信頼ポリシー:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": ["sts:AssumeRole", "sts:TagSession"]
  }]
}

aws iam create-role \
  --role-name MicroVMBuildRole \
  --assume-role-policy-document file://trust-policy.json

権限ポリシー:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
    },
    {
      "Effect": "Allow",
      "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}

aws iam put-role-policy \
  --role-name MicroVMBuildRole \
  --policy-name MicroVMBuildPolicy \
  --policy-document file://build-policy.json

サンプルアプリ準備 & S3 アップロード

Flaskアプリ、Dockerfile、requirements.txtの3ファイルを用意します。

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=8080)

requirements.txt:

flask==3.1.1
gunicorn==23.0.0

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 8080

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

gunicornで 0.0.0.0:8080 を待ち受けています。認証トークンの allowed-ports とリクエスト時の X-aws-proxy-port で8080を指定するため、アプリ側の待ち受けポートも8080にしています。

S3バケットを作成し、zipにまとめてアップロードします。

aws s3 mb s3://YOUR-BUCKET-NAME --region ap-northeast-1

zip app.zip app.py requirements.txt Dockerfile
aws s3 cp app.zip s3://YOUR-BUCKET-NAME/app.zip

MicroVM イメージ作成

create-microvm-image でイメージを作成します。Dockerfileの実行後にアプリケーションを起動し、その状態のFirecrackerスナップショットを取得する流れです。

--base-image-arn はLambda MicroVMsが提供するVM基盤を指定するもので、Dockerfileの FROM が指定するOS／アプリ環境とは役割が異なります。

aws lambda-microvms create-microvm-image \
  --name flask-microvm-demo \
  --code-artifact uri=s3://YOUR-BUCKET-NAME/app.zip \
  --base-image-arn arn:aws:lambda:ap-northeast-1:aws:microvm-image:al2023-1 \
  --build-role-arn arn:aws:iam::123456789012:role/MicroVMBuildRole \
  --region ap-northeast-1

{
    "imageArn": "arn:aws:lambda:ap-northeast-1:123456789012:microvm-image:flask-microvm-demo",
    "name": "flask-microvm-demo",
    "state": "CREATING",
    "baseImageArn": "arn:aws:lambda:ap-northeast-1:aws:microvm-image:al2023-1",
    "codeArtifact": {
        "uri": "s3://YOUR-BUCKET-NAME/app.zip"
    },
    "imageVersion": "1.0"
}

ビルド完了をポーリングで待ちます。

while true; do
  STATE=$(aws lambda-microvms get-microvm-image \
    --image-identifier arn:aws:lambda:ap-northeast-1:123456789012:microvm-image:flask-microvm-demo \
    --region ap-northeast-1 --query 'state' --output text)
  echo "$(date +%H:%M:%S) $STATE"
  [ "$STATE" = "CREATED" ] && break
  sleep 10
done

ビルドは約3分で CREATED に遷移しました。

{
    "imageArn": "arn:aws:lambda:ap-northeast-1:123456789012:microvm-image:flask-microvm-demo",
    "name": "flask-microvm-demo",
    "state": "CREATED",
    "latestActiveImageVersion": "1.0",
    "createdAt": "2026-06-23T10:11:30.953000+09:00",
    "updatedAt": "2026-06-23T10:14:31.702000+09:00"
}

MicroVM 起動

run-microvm でMicroVMを起動します。ingress/egressのnetwork connectorとidle-policyを指定します。

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:ap-northeast-1:123456789012:microvm-image:flask-microvm-demo \
  --ingress-network-connectors "arn:aws:lambda:ap-northeast-1:aws:network-connector:aws-network-connector:ALL_INGRESS" \
  --egress-network-connectors "arn:aws:lambda:ap-northeast-1:aws:network-connector:aws-network-connector:INTERNET_EGRESS" \
  --idle-policy '{"autoResumeEnabled":true,"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300}' \
  --region ap-northeast-1

{
    "microvmId": "microvm-01234567-abcd-ef01-2345-6789abcdef01",
    "state": "PENDING",
    "endpoint": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.lambda-microvm.ap-northeast-1.on.aws",
    "idlePolicy": {
        "maxIdleDurationSeconds": 900,
        "suspendedDurationSeconds": 300,
        "autoResumeEnabled": true
    },
    "maximumDurationInSeconds": 28800
}

idle-policyの各パラメータの意味は以下の通りです。

パラメータ 今回の設定値 意味
maxIdleDurationSeconds 900 アイドル継続でサスペンドするまでの秒数
suspendedDurationSeconds 300 サスペンド状態を維持する最大秒数
autoResumeEnabled true リクエスト受信で自動レジュームするか

起動は約10秒で RUNNING に遷移しました。スナップショットからの復元方式のため、毎回アプリケーションの初期化処理を実行する従来方式と比べ、起動後すぐ利用できると考えられます。

aws lambda-microvms get-microvm \
  --microvm-identifier microvm-01234567-abcd-ef01-2345-6789abcdef01 \
  --region ap-northeast-1 --query 'state' --output text

RUNNING

HTTP リクエスト送信

MicroVMへのリクエストには認証トークンが必要です。create-microvm-auth-token で取得します。

TOKEN=$(aws lambda-microvms create-microvm-auth-token \
  --microvm-identifier microvm-01234567-abcd-ef01-2345-6789abcdef01 \
  --expiration-in-minutes 30 \
  --allowed-ports '[{"port":8080}]' \
  --region ap-northeast-1 \
  --query 'authToken."X-aws-proxy-auth"' --output text)

X-aws-proxy-auth ヘッダーにトークンを付与してリクエストします。

curl "https://xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.lambda-microvm.ap-northeast-1.on.aws/" \
  -H "X-aws-proxy-auth: $TOKEN" \
  -H "X-aws-proxy-port: 8080"

{"message":"Hello, World!"}

サスペンド & レジューム

suspend-microvm でMicroVMを手動サスペンドします。

aws lambda-microvms suspend-microvm \
  --microvm-identifier microvm-01234567-abcd-ef01-2345-6789abcdef01 \
  --region ap-northeast-1

aws lambda-microvms get-microvm \
  --microvm-identifier microvm-01234567-abcd-ef01-2345-6789abcdef01 \
  --region ap-northeast-1 --query 'state' --output text

SUSPENDED

サスペンド状態で再度リクエストを送信します。idle-policyで autoResumeEnabled: true を設定しているため、リクエストを受けると自動レジュームされます。

time curl "https://xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.lambda-microvm.ap-northeast-1.on.aws/" \
  -H "X-aws-proxy-auth: $TOKEN" \
  -H "X-aws-proxy-port: 8080"

{"message":"Hello, World!"}

real    0m2.636s

サスペンド状態へのリクエスト送信からレスポンス受信までが約2.6秒でした（curlのreal時間ベース。ネットワーク往復やTLS確立を含む）。レジューム処理単体の時間ではない点に注意してください。認証トークンの有効期限（30分）内であり、サスペンド・レジュームをまたいでも同じトークンでリクエストが通りました。

状態がRUNNINGに戻ったことを確認します。

aws lambda-microvms get-microvm \
  --microvm-identifier microvm-01234567-abcd-ef01-2345-6789abcdef01 \
  --region ap-northeast-1 --query 'state' --output text

RUNNING

クリーンアップ

検証完了後、作成したリソースを削除します。

# MicroVM 終了
aws lambda-microvms terminate-microvm \
  --microvm-identifier microvm-01234567-abcd-ef01-2345-6789abcdef01 \
  --region ap-northeast-1

# MicroVM イメージ削除
aws lambda-microvms delete-microvm-image \
  --image-identifier arn:aws:lambda:ap-northeast-1:123456789012:microvm-image:flask-microvm-demo \
  --region ap-northeast-1

# S3 オブジェクト・バケット削除
aws s3 rm s3://YOUR-BUCKET-NAME --recursive
aws s3 rb s3://YOUR-BUCKET-NAME

# IAM ロール削除（インラインポリシー削除後にロール削除）
aws iam delete-role-policy --role-name MicroVMBuildRole --policy-name MicroVMBuildPolicy
aws iam delete-role --role-name MicroVMBuildRole

まとめ

ステップ 所要時間
イメージビルド 約3分
MicroVM起動（PENDING → RUNNING） 約10秒
サスペンドからのレジューム + レスポンス 約2.6秒

従来のLambda関数デプロイとは異なり、Dockerfileでアプリ環境を定義してスナップショットを取得するフローでしたが、手順はシンプルで迷う箇所はありませんでした。スナップショット復元による起動のため初回起動処理のやり直しがなく、サスペンド・レジュームで再デプロイなしに実行環境を再開できました。

公式ブログではAIコーディングアシスタントのサンドボックスやマルチテナントのコード実行環境が想定用途として挙げられています。メモリ・ディスク状態がサスペンドをまたいで保持される特性を考えると、ユーザーセッションごとに隔離環境を立てて中断・再開するようなワークロードとの相性が良さそうです。