Lambda MicroVMsは常駐サーバーの代わりに なるか？ Kiro Crew を動かして検証してみた / Kiro Crew on Lambda MicroVMs

Lambda MicroVMs 上で Kiro Crew を動かし、「必要なときだけ起動する常駐サーバー代替」になり得るかを検証しました。動作確認や Suspend/Resume、状態復元まで試し、実用化に向けた課題と限界を整理します。

登壇資料：
2026/09/26 JAWS-UG 栃木 オフライン # 10 -秋の登壇祭り-
https://jawsug-tochigi.connpass.com/event/406770/

Transcript

1. JAWS-UG 栃木 #10 · 2026.09.26 Lambda MicroVMs は 常駐サーバーの代わりに なるか？ Kiro Crew を動かして検証してみた JAWS-UG 栃木 #10 -秋の登壇祭り- 2026.09.26 足立 和生 / アジアクエスト株式会社
2. 自己紹介 アジアクエスト株式会社 AWS Community Builder（Dev Tools） （2025 Japan AWS Jr. Champions） 2026 Japan All AWS Certifications Engineer JAWS-UG 配信部 / JAWS SONIC 2026 スタッフ 足立 和生 好きなAWSサービス Kiro 2
3. TODAY Lambda MicroVMs を使い、 Kiro Crew を必要なときだけ動かしたい
4. なぜこの検証を始めたか 使わない時間の費用を減らし、新しい実行基盤の用途を探したい EC2 の常駐費用 Kiro Crew が働いていない時間もインスタンスは動き続ける 必要なときだけ動かしたい 利用中だけ計算資源へ課金する構成を試したい ServerlessDays Tokyo 2026 がきっかけ ハンズオン後、隔離環境以外のユースケースを探していた 4
5. Lambda MicroVMs の発表 2026年6月22日、AWS が東京リージョンを含む5リージョンで提供開始 Run isolated sandboxes with full lifecycle control AWS Lambda introduces MicroVMs aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/ 5
6. Lambda MicroVMs とは イメージから起動し、稼働・休止・再開・終了する Linux VM ① 起動 イメージから生成 → ② 稼働 RUNNING 稼働 ⇄ 休止 は同じ VM で繰り返せる ⇄ ③ 休止 SUSPENDED → ④ 終了 破棄 終了すると VM 固有の状態は失われる 各 Lambda MicroVM は 独立した実行環境 6
7. Lambda Functions との違い Kiro Crew の複数プロセスを VM 単位で動かせる Lambda Functions Lambda MicroVMs 関数の呼び出し 関数ランタイム 最大15分 独立した Linux VM 複数プロセス 最大8時間 VS 7
8. Kiro Crew とは Kiro CLI をチームとして動かし、会話や作業を次のセッションへつなぐ 1 依頼する 2 Kiro Crew が作業 3 次のセッションへ 人が仕事を渡す Kiro CLI を実行する 会話や作業を引き継ぐ github.com/kirodotdev/KiroCrew 8
9. 使わない時間も EC2 は動く 必要なときだけ起動する方式を試したい EC2 を常駐させる場合 Lambda MicroVMs 24時間稼働 0時 24時 利用 休止 0時 利用 休止 24時 同じ24時間でも、稼働している時間が違う 9
10. Kiro Crew を必要なときだけ動かせるか 起動できることと、作業を続けられることを実機で確かめる Q1 Q2 MicroVM で起動できるか Gateway を起動し、Kiro CLI から応答を受け取れるか 停止後も仕事を続けられるか Suspend 後の再開と、8時間後の別 MicroVM への復元を 確認する 起動確認だけでは、常駐先として使えるとは言えない 10
11. 「動く」と「続く」は別の成功条件 状態の復元までは確認済み。Kiro Crew が仕事を続けられるかが残る Kiro Crew が応答 01 認証・Kiro Crew Gateway・チャット 同じ Lambda MicroVM で再開 02 ディスク上の Kiro Crew データを保持 03 別 Lambda MicroVM に引き継ぐ S3復元・パス移行・会話閲覧は確認済み。Memory検索・Task再開は未検証 確認済み 確認済み 復元済み 継続未検証 11
12. Kiro Crew Gateway と Kiro CLI Kiro Crew Gateway が入口となり、CLI のセッションへ仕事を渡す Kiro Crew Gateway 利用者 入口・セッション管理 依頼・結果確認 保持したい状態 Kiro CLI Session Memory エージェントの作業 Task Workspace 12
13. Kiro Crew Gateway が止まると 同じ入口で新しい依頼を受け続けることはできない 利用者 新しい依頼 Kiro Crew Gateway 停止中 × CLI 実行先 停止中の依頼を受ける仕組みは、別途設計が必要 13
14. 何を引き継ぎたいのか 「続きから」の意味は、状態の種類ごとに違う Session Memory Task Workspace 会話と文脈を参照する 次の工程へ進む 前に覚えた情報を使う 作業ファイルを保つ 14
15. Kiro Crew 全体を1台の Lambda MicroVM へ Kiro Crew Gateway と Kiro CLI を同じ実行環境に置く 1台の Lambda MicroVM Kiro Crew Gateway 依頼の入口 → Kiro CLI 作業の実行 Kiro Crew を丸ごと同居させる 実装の詳しい経路は、後半で扱う 15
16. イメージは起動時の土台 Crew 本体は入っても、前の VM の仕事は入らない Container image から作る MicroVM Image Kiro CLI ↙ Kiro Crew 初期設定 ↘ Lambda MicroVM A 利用済み Lambda MicroVM B 新規起動 CLI + Crew CLI + Crew イメージ由来 /root/.kiro/crew 実行時に生成 （空） イメージ由来 VM A の状態なし 16
17. 同じ Lambda MicroVM の Suspend/Resume Suspend はメモリとディスクを保つ Lambda MicroVM A Suspend 前 RUNNING メモリ・ディスクあり 3つとも同じ MicroVM Suspend 中 SUSPENDED メモリ・ディスクを保持 Resume 後 RUNNING 保持した状態で再開 MicroVM ID は変わらない 17
18. 8時間の境界 同じ Lambda MicroVM を永遠には使い続けられない VM A VM B 0h 稼働 休止 再開・稼働 — 8h 上限 新規起動（世代交代） 上限の目安：最大 28,800 秒（8時間）※算入範囲は仕様確認 世代交代には 状態の外部保存と復元 が要る 18
19. 料金モデル（コンピュート） ベースラインは継続課金、バーストは消費した秒だけ課金される 通常稼働 ） ベースライン （2GB / 1vCPU・デフォルト） バースト（最大 4x） バースト超過分 （最大 4x まで） アイドル（サスペン ド） 再開（resume） UPCv / BG リ モ メ （ ス ー ソ リ $0 時間 → アイドル中は最大 8 時間サスペンド可能。計算課金はゼロ、状態は保持され即時再開できる 19
20. 料金は稼働時間で逆転する 同じ 1 vCPU / 2 GiB なら、月約210時間が損益分岐点になる Lambda MicroVMs ） DS （U 額月 EC2 c7g.medium：約 $26.50 / 月 約210時間 / 月 約7時間 / 日 0 210 400 730時間 前提：バージニア北部、EC2 c7g.medium On-Demand $0.0363/時、MicroVM 既定 baseline 約 $0.1261/時。Snapshot・EBS・転送・Burst は除外 20
21. 今回の実装構成 Mac の検証スクリプトから、認証付き WebSocket で MicroVM 内のコマンドを実行する AWS Lambda MicroVM >_ シェル接続口 ローカル環境 8022 /shell JWE 認証付き WebSocket Mac connect.sh / shell.py VM 内で実行 CLI 入出力 Kiro Crew Gateway → ↔ loopback 127.0.0.1:5476 ↔ Kiro CLI 2.24.0 Kiro Crew 0.7.1 が管理 起動時に シークレット取得 ↓ ↑ Kiro API Key を返却 Secrets Manager 21
22. Kiro Crew と Kiro CLI をイメージへ 左が構築要素、右が Dockerfile の依存パッケージ部分 1 Container image 2 依存パッケージ 3 Amazon Linux 2023 minimal tar・gzip・unzip・git・python3.12・openssl Kiro CLI / Kiro Crew CLI 2.24.0・Crew 0.7.1 # 依存パッケージ部分 FROM public.ecr.aws/lambda/ microvms:al2023-minimal RUN dnf install -y tar gzip unzip git python3.12 openssl 22
23. Kiro の認証情報は起動時に取得する Kiro API キーをイメージに含めない AWS Secrets Manager Kiro API キー → Lambda MicroVM run / resume hook Secret を取得 → CLI wrapper 実行時にキーを渡す イメージにキーを含めない ビルド時：キーを含めない 起動・再開時：Secrets Manager から取得 実行時：CLI wrapper へ渡す 23
24. Lambda MicroVM で Kiro Crew が動作した 認証、Kiro Crew Gateway、チャット応答まで実測した Kiro 認証 確認済み whoami exit 0 Kiro Crew Gateway 確認済み 127.0.0.1:5476 で HTTP 200 Kiro Crew チャット 確認済み ready / exit 0 外部公開 Dashboard 未確認 確認範囲は Lambda MicroVM 内 Kiro Crew の基本経路は Lambda MicroVM 内で動いた 24
25. 同じ Lambda MicroVM で Crew データを保持した Suspend/Resume 後も /root/.kiro/crew を保持した Suspend 前 同じ Lambda MicroVM A /root/.kiro/crew 存在 → 確認済み：同一 Lambda MicroVM の Kiro Crew データ保持 Resume 後 同じ Lambda MicroVM A /root/.kiro/crew 存在 未検証：Memory 検索 / Task 再開 25
26. Suspend/Resume の所要時間 明示 API での状態遷移は約 1〜1.3 秒。休止からの復帰は近瞬時だった Suspend → SUSPENDED 約 1.2〜1.4 秒 5 サイクルで安定 Resume → RUNNING 約 1.2〜1.3 秒 1 回のみ 3.2 秒 トラフィック起因の Auto-resume 近瞬時 固有コストは接続 OH に埋もれる 前提：バージニア北部、none モードの使い捨て MicroVM 1 台、suspend-microvm / resume-microvm を明示呼び出し、状態を 0.5 秒間隔でポーリング（実遷移はこれより速 い可能性） アイドル時に休止し、必要なときに近瞬時で復帰できる 26
27. 世代交代の壁 新しい Lambda MicroVM に 仕事は自動で移らない 同じ Lambda MicroVM のデータ保持と、別 Lambda MicroVM への状態継承は別問題
28. 状態の復元後に仕事を続けられるか ファイル復元と会話閲覧は通った。残るのは Kiro Crew の利用可否 復元・パス移行 S3 往復と会話閲覧を実機確認 Memory 検索 Kiro Crew API 経由は未検証 Task 再開 二重実行防止を含め未検証 復元はできた。業務の継続はまだ 28
29. 世代交代の全体構成 状態保存と切替制御を分け、Kiro Crew の実行環境を入れ替える 1 Mac 2 →起動 Durable Functions 3 →実行 MicroVM Kiro Crew →保存 Kiro CLI 4 S3 5 →復元 次世代 MicroVM 復元して再開 ↑ secret 注入 Secrets Manager 29
30. 今後の外部保存手段の候補 状態の外部保存・復元をどこに置くか、これから比較検証する S3 Object 検証済み 世代ごとに tar/manifest を保存。往復は実機確認 済み DynamoDB S3 Files ファイルとしてマウント。SQLite の整合性を要検 証 候補 世代・lease・fencing token など制御メタデータ 向き 候補 候補 外部サービス TiDB など。マネージド DB を状態ストアに使う案 保存先ごとに 整合性・費用・復元性 を比較する 30
31. 別 Lambda MicroVM で継続を判定する 保存できたことだけでは「仕事を続けた」と言えない 状態 VM A で用意する VM B で確認する 現時点 Session 会話履歴を残す 履歴を参照できる 会話閲覧済み Memory 記憶を保存 記憶を利用できる 未検証 Task 途中の作業を残す 重複なく継続 未検証 Workspace ファイルを編集 変更を保持 復元済み 残る合格条件は Memory 検索と Task 再開 31
32. 現時点の答え 冒頭の3段階に答え合わせをする Kiro Crew が応答 01 認証、Kiro Crew Gateway、チャット 同じ Lambda MicroVM で再開 02 ディスク上の Kiro Crew データ保持 03 別 Lambda MicroVM へ復元 復元・会話閲覧は確認済み。Memory 検索・Task 再開は未検証 確認済み 確認済み 復元済み 継続未検証 技術的には近づいたが、常駐サーバー用途には複雑すぎる 32
33. まとめ Lambda MicroVMs を Kiro Crew の常駐サーバーとして使うのはお勧めしない 常駐先には EC2、自宅サーバー、VPS の方が楽 8時間ごとの世代交代と状態照合を運用へ持ち込む必要がない 検証で分かったこと Lambda MicroVMs と Kiro Crew の状態管理を深く理解できた 実装は公開予定 ブログと GitHub で、もの好きな人向けに共有する 33
34. Memory と Task の保存先調査 APPENDIX 01 どこに、いつ書かれ、どう復元確認するかを整理する 調査項目 Memory Task 保存対象 覚えた情報 Snapshot Global / Member Memory、Knowledge、 Task DB は対象外 Markdown 補助アーカイブ session_map.json / workspace_dir Transcript、Task DB、CLI Session、外部 Workspace 制約 SQLite WAL のためネットワーク FS 不可 書込中コピーと二重実行を回避 残る確認 Crew API から検索できるか 重複なく再開できるか 途中の作業状態 34
35. 今後答えたい疑問 APPENDIX 02 この検証固有で、実装・実機検証が要る残りの問い 休止中の起動トリガー 停止中の VM をどう起こし、依頼をどうキューイングするか 外部公開・認証エンドポイント loopback までしか未確認。JWE 付き HTTPS に Gateway を載せる設計 live resume 同一 CLI Session の実再開。readiness までで実再開は未検証 Task 再開と二重実行防止 lease / fencing token・外部副作用照合は設計のみ 35