Lambda MicroVMsが分からなすぎたので 1から使い所を考えてみた 2026/9/30 JAWS-UG 茨城⽀部 #17 秋の推しAWSサービスLTまつり！ 

⾃⼰紹介 職種歴： 1. インフラエンジニア：3年 2. クラウドエンジニア：3.5年 3. 開発エンジニア：2年 ● 部署 ○ ● ニックネーム ○ ● つくぼし 今まで推していたAWSサービス ○ ● クラウド事業本部 AWS App Runner SNS/ブログ ○ X(@tsukuboshi0755) ○ DevelopersIO(つくぼし) 2 

3 最近Lambda MicroVMsというサービスをよく⾒ますよね？ 皆さんはこのサービスがどういうものかご存知でしょうか？ 

4 ぶっちゃけ私はMicro VMの概念すら よく分かってなかったので今回調べました 

対象者 ● Lambdaといったら関数でしょ？と思っている⽅ ● Micro VMってそもそも何ですか？と疑問に思う⽅ ● Lambda MicroVMs は聞いた事あるけど使い所がわからない⽅ 5 

対象者 1. そもそもMicro VM is 何？ 2. Lambda MicroVMsとは 3. Lambda MicroVMsと他AWSサービスとの⽐較 4. Lambda MicroVMs のユースケースを考える 6 

そもそもMicro VM is 何？ 

8 Micro VMってなんだ？ VMやコンテナとは違うのか？ 

MicroVM が⽣まれた背景 ● VMはBIOS‧PCI 等の物理マシンに必要な設定を抱えるので、オーバー ヘッドが⼤きく起動に時間がかかる ● コンテナの登場で⾼速なコンピュータ環境の起動が可能になったが、ホ スト側のカーネルを他コンテナと共有するためセキュリティ観点での環 境分離が不⼗分という指摘が残っていた ● MicroVMでは、VMにおけるハイパーバイザやゲストカーネルの考えはそ のままに、オーバーヘッドの原因であるデバイスエミュレーションだけ を削ぎ落とす ○ VMとほぼ同等の分離単位を持ちつつ、コンテナ並の⾼速な起動時間 を実現する 9 

コンテナ仮想化とMicroVMは何が違うのか？ ● 両者とも⾼速に起動できるコンピューティング環境という特徴を持つ ● コンテナ ○ 各コンテナでカーネル⼀枚を共有する。 ○ namespace‧cgroup‧seccomp といったカーネル内の機能で仕切る が、分離単位はVMより浅くなる。 ● MicroVM ○ 各インスタンスで専⽤カーネルを独⽴して持つ。 ○ 分離単位は基本的にVMと同⼀であり、コンテナと併⽤も容易。 10 

Firecrackerとは ● Amazonが作成したKVMベースのVMM ● MicroVMを⾼速に起動可能な環境として作られた ● OSSとして公開されている ○ https://firecracker-microvm.github.io/ ● LambdaやFargate、AgentCore Runtimeの基盤として使われている ○ 実は利⽤者が意識しなくて良かっただけで、MicroVM⾃体は今まで もAWSの裏側で使われてきた 11 

MicroVMやFirecrackerの仕組みについてもっと知りたい⽅は https://dev.classmethod.jp/articles/devio2021-awslambda-under-the-food/ 12 

Lambda MicroVMsとは 

Lambda MicroVMs とは ● MicroVMを元にしたVM レベルの分離を持つコンピュート環境 ○ 「Lambda関数」とは別物 ● 起動⼿順は以下の通り ○ DockerfileとアプリコードからMicroVM イメージを作る ○ イメージから個々のインスタンスをMicroVMとして起動 ● イングレスネットワークで以下の通信を許可できる ○ HTTPを許可すると、専⽤URLエンドポイントからHTTPリクエスト 送信可能(デフォルト) ○ シェルを許可すると、WebSocketを通じてターミナルへのアクセス が可能(テスト環境のみ) 14 

Lambda MicroVMs のターミナルアクセス 15 

Lambda MicroVMs のターミナルアクセス 16 

Lambda Micro VMsの3⼤特徴 ● 分離レベル：VM級で払い出せる ○ 厳密にはMicroVM 1台 = 1ユーザー / 1セッション単位で払い出す ● 起動速度：数秒から数⼗秒 ○ 通常のVMサービス(EC2等)と⽐較するとめちゃくちゃ早い ● 状態保持：停⽌と再開が可能 ○ メモリとディスクの状態を保持したまま停⽌できる 17 

Lambda Micro VMsの便利な点 ● 最⼤実⾏時間：8時間 ○ ある程度⻑時間の処理であれば継続実⾏させる事が可能 ○ 8時間経過するとVMが⾃動破棄される ● NW設定：VPCなしのパブリックアクセス(デフォルト) ○ VPCを意識せず起動できるため運⽤負荷が少ない ○ VPC Egressコネクタを使えばVPC内のプライベートアクセスも可能 18 

Lambda Micro VMsで気をつけるべき制約 ● 最⼤メモリ32GB (ピーク時) / 16 vCPU (ピーク時) / 最⼤ディスク 32GB ● CPUはARM64(Graviton)のみ。x86は⾮対応。 ● HTTPリクエストには X-aws-proxy-auth の JWE トークンが必要で、 トークンの有効期限は最⼤60分。 ● イングレス通信で許可されるのは HTTP/1.1‧HTTP/2‧WebSocket‧gRPC‧SSE のみで、それ以外の任 意の TCP通信はそのままでは通らない。 19 

20 超絶ざっくりいうと、 「起動が早い‧寿命が8時間‧VPCレス」 という特徴を持つVM 

Lambda MicroVMsと他AWSサービスとの⽐較 

22 Lambda Micro VMsは 他のAWSサービスとどう違う？ 

Lambda Micro VMs vs Lambda 関数 ● ● 分離レベル ○ ほぼ互⾓。 ○ Lambda関数でもテナント分離モードを利⽤する事で、呼び出し毎に実⾏環境を分離可能。 ○ ただし通常モードだと呼び出し毎に実⾏環境は分離されないので注意。 起動速度 ○ Lambda関数が有利になりやすい。Lambda関数はウォームしていればミリ秒単位、コール ドスタートでも100ミリ秒〜数秒程度。 ● 状態保持 ○ Micro VMsが有利。Lambda関数はキャッシュがメモリやエフェメラルストレージに残る事 はあるが保証されず、保証するには原則外部サービスに切り出す必要がある。 ● 実⾏時間 ○ Micro VMsが有利。Lambda関数は15分(Managed Instancesだと90分)しか継続実⾏できな い。 ● NW運⽤負荷 ○ ほぼ互⾓。Lambda関数もパブリックアクセスかVPC内かを選べる。 23 

Lambda Micro VMs vs ECS Fargate ● ● 分離レベル ○ ほぼ互⾓。 ○ Fargateのタスクは VMレベルの分離境界を持ち、カーネルを他タスクと共有しない。 ○ ただしタスク内のサイドカーコンテナまでは分離されないので注意。 起動速度 ○ Micro VMsがやや有利。Fargate は軽くても数⼗秒はかかるため、ユーザーを待たせながら 起動する⽤途には少し重め。 ● 状態保持 ○ Micro VMsが有利。Fargateはキャッシュがタスク終了時に消えるため、別サービスに切り 出す必要が出てくる。 ● 実⾏時間 ○ ● Fargateが有利。Fargateは実⾏時間の上限が無い。 NW運⽤負荷 ○ Micro VMsが有利。FargateはVPCが必須のためNW設計の考慮が必要。 24 

Lambda Micro VMs vs EC2 ● ● 分離レベル ○ ほぼ互⾓。両者ともVMレベルでの分離。 ○ EC2はインスタンス単位でMicroVMsはセッション単位という違いはある。 起動速度 ○ ● MicroVMs が有利。EC2 は AMI から OS を丸ごとブートするので数⼗秒〜分はかかる。 状態保持 ○ ⼀⻑⼀短。EC2はデフォルトだと停⽌時にメモリを破棄する仕様だが、ストレージは無制限 にファイルを保持できる。 ● 実⾏時間 ○ ● EC2が有利。EC2は実⾏時間の上限が無い。 NW運⽤負荷 ○ Micro VMsが有利。EC2はVPCが必須のためネットワーク設計の考慮が必要。 25 

Lambda Micro VMs vs CodeBuild ● 分離レベル ○ ● ほぼ互⾓。CodeBuildはビルドごとに新しいVMを⽴て、終了時に破棄する。 起動速度 ○ Micro VMsがやや有利。CodeBuildはオンデマンドだとプロビジョニングが遅い。リザーブ ドキャパシティだとプロビジョニングは問題は解決するが、マシンが常時稼働するため料⾦ が⾼くなる。 ● 状態維持 ○ Micro VMsが有利。CodeBuildはオンデマンドだとキャッシュはビルドごと破棄なので外部 サービスに切り出すしかなく、リザーブドキャパシティだとキャッシュは残るものの次のビ ルドが同じインスタンスで使い回せる保証が無い。 ● 実⾏時間 ○ ● CodeBuild がやや有利。CodeBuildのタイムアウトは最⼤36時間まで伸ばせる。 NW運⽤負荷 ○ ほぼ互⾓。CodeBuildもパブリックアクセスかVPC内かを選べる。 26 

Lambda Micro VMs vs Bedrock AgentCore Runtime ● 分離レベル ○ ● 起動速度 ○ ● 完全に互⾓。VMレベルのみならずセッション単位の粒度まで⼀緒。 ほぼ互⾓。AgentCoreのV2 はスナップショットから起動。 状態維持 ○ ⼀⻑⼀短。AgentCoreはセッション終了時にMicro VMを破棄するためメモリを保てないが、 Managed Session Storageを利⽤すると14⽇までファイルを保持できる。 ● 実⾏時間 ○ ● AgentCoreがやや有利。デフォルトは8時間だがManaged Instancesであれば14⽇利⽤が可能。 NW運⽤負荷 ○ ほぼ互⾓。AgentCOreもパブリックアクセスかVPCモードかを選べる。 ※AgentCore はエージェント特化（MCP‧A2A、LangGraph/Strands/CrewAI前提、セッション管理⾃ 動）、Micro VMs はエージェント以外の任意ワークロード向けという違いがあるためここで使い分け 27 

28 汎⽤的なワークロードで 「状態を持てる」使い捨て環境が欲しい時に Lambda MicroVMsを使うと良さそう 

Lambda MicroVMs のユースケースを考える 

30 結局Lambda Micro VMsは どうやって使うのが正解なのか？ 

使い所① 未検証のコード‧パッケージ実⾏⽤サンドボックス環境 ● AWS公式が筆頭に上げる使い⽅ ● AI が⽣成した「何をするか分からないコード」をユー ザー/セッション単位で隔離実⾏する ● 応⽤として外部の不審なパッケージをテストしレポート を⽣成する⽤途でも使える 31 

サンドボックス環境の例 参考：https://github.com/aws-samples/sample-lambda-microvm-claude-managed-agents 32 

使い所② 常駐 Web アプリのホスティング検証 ● 従来のサーバレス（Lambda Web AdapterやApp Runner）では載らなかった WebSocket 必須のアプリが 載る ● Streamlit製のAIアプリをホスティング可能 ● Micro VM⾃体は8時間で⾃動破棄されるため、検証⽤途と しての利⽤がオススメ 33 

使い所③ 使い捨ての研修⽤ラボ環境 ● Code Server(https://github.com/coder/code-server) の デプロイ先として利⽤できる ● 従来のEC2より起動が早くVPC設定もいらないため、使い 捨ての研修⽤ラボとして使える ● 8時間以内に完了するワークショップであれば⾃動破棄さ れるため、リソース掃除もいらない 34 

使い所④ CIタスクランナー ● ECSをランナーとして使うとDocker in Dockerに必要な特 権モード制限やNW設計の課題があるが、MicroVMsなら コンテナもVPCも気にせず起動できる ● CodeBuildをランナーとして使うと設定が重い弱点があ るが、MicroVMsは起動が早くて軽いため使い捨てが簡単 ● GitHub Actionsと併⽤し、コンテナ稼働可能&HTTPアク セス可能な使い捨ての環境として使⽤するのがオススメ 35 

逆に使わない⽅が良い所 ● 普通の API バックエンド ○ ECSまたはLambda関数でOK ● 常時フル稼働の重いワークロード ○ ECSまたはEC2出ないと厳しい ● エージェント ○ AgentCore Runtime推奨 36 

37 使い所は選ぶが、ハマると強⼒なサービス 

まとめ 

結論 39 ● Lambda Micro VMsは、「起動が早い‧寿命が8時間 ‧VPCレス」の特徴を持つVMと考えると良さそう ● 汎⽤的なワークロードで、かつ「状態を持てる」使い捨 て環境が欲しい時にLambda MicroVMsを使うと良さげ ● 使い所は選ぶがハマると強⼒なサービスである 

40 Lambda MicroVMsは今までにないパターンのAWSサービスですが、 いかんせん絶妙に使い所を選びます。 個⼈的にAWSからの挑戦状だと勝⼿に思っているので、 もし⾯⽩い使い⽅があればぜひ⼀緒に掘りたいです。 

No content