Lambda MicroVMsが分からなすぎたので使い所を1から考えてみた

Transcript

1. Lambda MicroVMsが分からなすぎたので 1から使い所を考えてみた 2026/9/30 JAWS-UG 茨城⽀部 #17 秋の推しAWSサービスLTまつり！
2. ⾃⼰紹介 職種歴： 1. インフラエンジニア：3年 2. クラウドエンジニア：3.5年 3. 開発エンジニア：2年 • 部署 ◦ • ニックネーム ◦ • つくぼし 今まで推していたAWSサービス ◦ • クラウド事業本部 AWS App Runner SNS/ブログ ◦ X(@tsukuboshi0755) ◦ DevelopersIO(つくぼし) 2
3. 3 最近Lambda MicroVMsというサービスをよく⾒ますよね？ 皆さんはこのサービスがどういうものかご存知でしょうか？
4. 4 ぶっちゃけ私はMicro VMの概念すら よく分かってなかったので今回調べました
5. 対象者 • Lambdaといったら関数でしょ？と思っている⽅ • Micro VMってそもそも何ですか？と疑問に思う⽅ • Lambda MicroVMs は聞いた事あるけど使い所がわからない⽅ 5
6. 対象者 1. そもそもMicro VM is 何？ 2. Lambda MicroVMsとは 3. Lambda MicroVMsと他AWSサービスとの⽐較 4. Lambda MicroVMs のユースケースを考える 6
7. そもそもMicro VM is 何？
8. 8 Micro VMってなんだ？ VMやコンテナとは違うのか？
9. MicroVM が⽣まれた背景 • VMはBIOS‧PCI 等の物理マシンに必要な設定を抱えるので、オーバー ヘッドが⼤きく起動に時間がかかる • コンテナの登場で⾼速なコンピュータ環境の起動が可能になったが、ホ スト側のカーネルを他コンテナと共有するためセキュリティ観点での環 境分離が不⼗分という指摘が残っていた • MicroVMでは、VMにおけるハイパーバイザやゲストカーネルの考えはそ のままに、オーバーヘッドの原因であるデバイスエミュレーションだけ を削ぎ落とす ◦ VMとほぼ同等の分離単位を持ちつつ、コンテナ並の⾼速な起動時間 を実現する 9
10. コンテナ仮想化とMicroVMは何が違うのか？ • 両者とも⾼速に起動できるコンピューティング環境という特徴を持つ • コンテナ ◦ 各コンテナでカーネル⼀枚を共有する。 ◦ namespace‧cgroup‧seccomp といったカーネル内の機能で仕切る が、分離単位はVMより浅くなる。 • MicroVM ◦ 各インスタンスで専⽤カーネルを独⽴して持つ。 ◦ 分離単位は基本的にVMと同⼀であり、コンテナと併⽤も容易。 10
11. Firecrackerとは • Amazonが作成したKVMベースのVMM • MicroVMを⾼速に起動可能な環境として作られた • OSSとして公開されている ◦ https://firecracker-microvm.github.io/ • LambdaやFargate、AgentCore Runtimeの基盤として使われている ◦ 実は利⽤者が意識しなくて良かっただけで、MicroVM⾃体は今まで もAWSの裏側で使われてきた 11
12. MicroVMやFirecrackerの仕組みについてもっと知りたい⽅は https://dev.classmethod.jp/articles/devio2021-awslambda-under-the-food/ 12
13. Lambda MicroVMsとは
14. Lambda MicroVMs とは • MicroVMを元にしたVM レベルの分離を持つコンピュート環境 ◦ 「Lambda関数」とは別物 • 起動⼿順は以下の通り ◦ DockerfileとアプリコードからMicroVM イメージを作る ◦ イメージから個々のインスタンスをMicroVMとして起動 • イングレスネットワークで以下の通信を許可できる ◦ HTTPを許可すると、専⽤URLエンドポイントからHTTPリクエスト 送信可能(デフォルト) ◦ シェルを許可すると、WebSocketを通じてターミナルへのアクセス が可能(テスト環境のみ) 14
15. Lambda MicroVMs のターミナルアクセス 15
16. Lambda MicroVMs のターミナルアクセス 16
17. Lambda Micro VMsの3⼤特徴 • 分離レベル：VM級で払い出せる ◦ 厳密にはMicroVM 1台 = 1ユーザー / 1セッション単位で払い出す • 起動速度：数秒から数⼗秒 ◦ 通常のVMサービス(EC2等)と⽐較するとめちゃくちゃ早い • 状態保持：停⽌と再開が可能 ◦ メモリとディスクの状態を保持したまま停⽌できる 17
18. Lambda Micro VMsの便利な点 • 最⼤実⾏時間：8時間 ◦ ある程度⻑時間の処理であれば継続実⾏させる事が可能 ◦ 8時間経過するとVMが⾃動破棄される • NW設定：VPCなしのパブリックアクセス(デフォルト) ◦ VPCを意識せず起動できるため運⽤負荷が少ない ◦ VPC Egressコネクタを使えばVPC内のプライベートアクセスも可能 18
19. 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. 20 超絶ざっくりいうと、 「起動が早い‧寿命が8時間‧VPCレス」 という特徴を持つVM
21. Lambda MicroVMsと他AWSサービスとの⽐較
22. 22 Lambda Micro VMsは 他のAWSサービスとどう違う？
23. Lambda Micro VMs vs Lambda 関数 • • 分離レベル ◦ ほぼ互⾓。 ◦ Lambda関数でもテナント分離モードを利⽤する事で、呼び出し毎に実⾏環境を分離可能。 ◦ ただし通常モードだと呼び出し毎に実⾏環境は分離されないので注意。 起動速度 ◦ Lambda関数が有利になりやすい。Lambda関数はウォームしていればミリ秒単位、コール ドスタートでも100ミリ秒〜数秒程度。 • 状態保持 ◦ Micro VMsが有利。Lambda関数はキャッシュがメモリやエフェメラルストレージに残る事 はあるが保証されず、保証するには原則外部サービスに切り出す必要がある。 • 実⾏時間 ◦ Micro VMsが有利。Lambda関数は15分(Managed Instancesだと90分)しか継続実⾏できな い。 • NW運⽤負荷 ◦ ほぼ互⾓。Lambda関数もパブリックアクセスかVPC内かを選べる。 23
24. Lambda Micro VMs vs ECS Fargate • • 分離レベル ◦ ほぼ互⾓。 ◦ Fargateのタスクは VMレベルの分離境界を持ち、カーネルを他タスクと共有しない。 ◦ ただしタスク内のサイドカーコンテナまでは分離されないので注意。 起動速度 ◦ Micro VMsがやや有利。Fargate は軽くても数⼗秒はかかるため、ユーザーを待たせながら 起動する⽤途には少し重め。 • 状態保持 ◦ Micro VMsが有利。Fargateはキャッシュがタスク終了時に消えるため、別サービスに切り 出す必要が出てくる。 • 実⾏時間 ◦ • Fargateが有利。Fargateは実⾏時間の上限が無い。 NW運⽤負荷 ◦ Micro VMsが有利。FargateはVPCが必須のためNW設計の考慮が必要。 24
25. Lambda Micro VMs vs EC2 • • 分離レベル ◦ ほぼ互⾓。両者ともVMレベルでの分離。 ◦ EC2はインスタンス単位でMicroVMsはセッション単位という違いはある。 起動速度 ◦ • MicroVMs が有利。EC2 は AMI から OS を丸ごとブートするので数⼗秒〜分はかかる。 状態保持 ◦ ⼀⻑⼀短。EC2はデフォルトだと停⽌時にメモリを破棄する仕様だが、ストレージは無制限 にファイルを保持できる。 • 実⾏時間 ◦ • EC2が有利。EC2は実⾏時間の上限が無い。 NW運⽤負荷 ◦ Micro VMsが有利。EC2はVPCが必須のためネットワーク設計の考慮が必要。 25
26. Lambda Micro VMs vs CodeBuild • 分離レベル ◦ • ほぼ互⾓。CodeBuildはビルドごとに新しいVMを⽴て、終了時に破棄する。 起動速度 ◦ Micro VMsがやや有利。CodeBuildはオンデマンドだとプロビジョニングが遅い。リザーブ ドキャパシティだとプロビジョニングは問題は解決するが、マシンが常時稼働するため料⾦ が⾼くなる。 • 状態維持 ◦ Micro VMsが有利。CodeBuildはオンデマンドだとキャッシュはビルドごと破棄なので外部 サービスに切り出すしかなく、リザーブドキャパシティだとキャッシュは残るものの次のビ ルドが同じインスタンスで使い回せる保証が無い。 • 実⾏時間 ◦ • CodeBuild がやや有利。CodeBuildのタイムアウトは最⼤36時間まで伸ばせる。 NW運⽤負荷 ◦ ほぼ互⾓。CodeBuildもパブリックアクセスかVPC内かを選べる。 26
27. 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. 28 汎⽤的なワークロードで 「状態を持てる」使い捨て環境が欲しい時に Lambda MicroVMsを使うと良さそう
29. Lambda MicroVMs のユースケースを考える
30. 30 結局Lambda Micro VMsは どうやって使うのが正解なのか？
31. 使い所① 未検証のコード‧パッケージ実⾏⽤サンドボックス環境 • AWS公式が筆頭に上げる使い⽅ • AI が⽣成した「何をするか分からないコード」をユー ザー/セッション単位で隔離実⾏する • 応⽤として外部の不審なパッケージをテストしレポート を⽣成する⽤途でも使える 31
32. サンドボックス環境の例 参考：https://github.com/aws-samples/sample-lambda-microvm-claude-managed-agents 32
33. 使い所② 常駐 Web アプリのホスティング検証 • 従来のサーバレス（Lambda Web AdapterやApp Runner）では載らなかった WebSocket 必須のアプリが 載る • Streamlit製のAIアプリをホスティング可能 • Micro VM⾃体は8時間で⾃動破棄されるため、検証⽤途と しての利⽤がオススメ 33
34. 使い所③ 使い捨ての研修⽤ラボ環境 • Code Server(https://github.com/coder/code-server) の デプロイ先として利⽤できる • 従来のEC2より起動が早くVPC設定もいらないため、使い 捨ての研修⽤ラボとして使える • 8時間以内に完了するワークショップであれば⾃動破棄さ れるため、リソース掃除もいらない 34
35. 使い所④ CIタスクランナー • ECSをランナーとして使うとDocker in Dockerに必要な特 権モード制限やNW設計の課題があるが、MicroVMsなら コンテナもVPCも気にせず起動できる • CodeBuildをランナーとして使うと設定が重い弱点があ るが、MicroVMsは起動が早くて軽いため使い捨てが簡単 • GitHub Actionsと併⽤し、コンテナ稼働可能&HTTPアク セス可能な使い捨ての環境として使⽤するのがオススメ 35
36. 逆に使わない⽅が良い所 • 普通の API バックエンド ◦ ECSまたはLambda関数でOK • 常時フル稼働の重いワークロード ◦ ECSまたはEC2出ないと厳しい • エージェント ◦ AgentCore Runtime推奨 36
37. 37 使い所は選ぶが、ハマると強⼒なサービス
38. まとめ
39. 結論 39 • Lambda Micro VMsは、「起動が早い‧寿命が8時間 ‧VPCレス」の特徴を持つVMと考えると良さそう • 汎⽤的なワークロードで、かつ「状態を持てる」使い捨 て環境が欲しい時にLambda MicroVMsを使うと良さげ • 使い所は選ぶがハマると強⼒なサービスである
40. 40 Lambda MicroVMsは今までにないパターンのAWSサービスですが、 いかんせん絶妙に使い所を選びます。 個⼈的にAWSからの挑戦状だと勝⼿に思っているので、 もし⾯⽩い使い⽅があればぜひ⼀緒に掘りたいです。