EC2 ではなく AWS Lambda MicroVMs 上の code-server で Strands Decider ハンズオンを完走した話

やったことと結論

Amazon EC2（t4g.xlarge）向けに公開された「Strands Decider ハンズオン」を、AWS Lambda MicroVMs 上の自作 code-server 環境へ移植し、一連の演習ステップを完走しました。

検証を通じて確認できた主な結果は次の 3 点です。

• 最大 16 vCPU のバースト性能により、判定処理のレイテンシが EC2（4 vCPU）の約 3000〜5400 ms から 783〜1328 ms（約 1 秒）へ短縮されたこと
• 約 8.4 GB のメモリを確保した推論サーバーを落とさず、suspend から resume することで、数秒でモデル再ロードなしに推論を再開できたこと
• 通常利用（1.5 時間）では EC2（約 39 円）が MicroVM（約 114 円）より安価なものの、MicroVM には 8 時間の自動終了機能があるため、24 時間放置の消し忘れ時でも費用上限（約 606 円）が抑えられること

数 GB のモデルを扱う一時的な検証環境として、数秒で起動し、状態を保持したまま停止できる Lambda MicroVMs は実用的な選択肢になります。

検証の動機と題材

今回の検証を試みた動機は 2 点あります。

1 点目は、直近で参加した Kiro University Challenge で制作した code-server on Lambda MicroVMs を、モデルをロードする本格的なハンズオンで実戦投入したかったためです。

もう 1 点は、1〜2 時間程度の検証のために EC2 をプロビジョニングしたくないという実感です。EC2 は環境構築や CloudFormation デプロイに数分待たされる上、検証終了後にリソースを削除し忘れると課金が継続します。必要なときだけ数秒で立ち上がり、作業中断時にはメモリごと一時停止できる環境で動かしたいと考えました。

題材としたのは、ふくちさん（@har1101）が公開されたハンズオン記事です。

本ハンズオンは、JAWS-UG 東京支部が開催したイベント「JAWS-UG東京 Strands Deciderハンズオン」の題材でもあります。

丁寧なハンズオンを公開してくださった @har1101 に感謝です！

題材と基盤の前提知識

本検証で組み合わせた 2 つの技術について、概要を整理します。

Strands Decider とは

AWS が 2026年10月1日に発表した決定・判定専用の 2B 軽量言語モデルです。

一般的な大規模言語モデル（LLM）のような自由文のテキスト生成は行いません。あらかじめ定義された選択肢の選定（choice）、Yes / No の二値判定（noul）、採点（score）など、意思決定やルーティングの判定に特化しています。

イベントのキャッチコピーでも

AWS製のJevみたいなやつ

と紹介されていた通り、判定特化型モデルとして知られる TypeSafe Jev に近い技術です。文章をトークン単位で生成しないためパース崩れが起きず、確信度（confidence）付きで高速に判定を返します。

クラウドのマネージド API として提供されるサービスとは異なり、Strands Decider はモデル重み（ベースモデル Qwen3.5-2B + LoRA アダプター）が公開されています。自前の環境内で完結して動かせるため、社外へデータを送信できない要件でも扱いやすい利点があります。

AWS Lambda MicroVMs とは

AWS Lambda の仮想化基盤である「Firecracker」を軽量な仮想マシンとしてオンデマンドで起動できるものです。通常のLambda関数と違って「最大8時間」動かすことが可能です。

AMI から起動する EC2 とは異なり、メモリと vCPU のスナップショットから数秒でインスタンスが復帰します。仮想マシンが RUNNING 状態の秒数のみ課金される秒単位の従量課金や、実行中プロセスをメモリごと退避して復帰できる suspend / resume 機能を備えています。また、ベースライン指定のリソース（メモリ・vCPU）に対し、負荷に応じて最大 4 倍まで自動でバーストします。

MicroVM への移植と環境構成

元記事で指定されている EC2 t4g.xlarge と、今回仕立てた Lambda MicroVMs 環境の対比は次の通りです。

項目	元記事の環境 (EC2 t4g.xlarge)	今回の環境 (Lambda MicroVMs sdh-code-server)
vCPU	4	baseline 4 / peak 16
メモリ	16 GB	baseline 8 GiB / burst 32 GB（VM 内実測 31 GB）
ディスク	EBS（数十 GB）	32 GB（baseline メモリ 8 GiB 連動）
起動時間	数分（AMI からのブート、CFN 構築は約 7 分超）	数秒（Firecracker snapshot resume）
途中停止	stop / start（EBS のみ維持、プロセス消失）	suspend / resume（メモリ状態ごと維持）
時間単価	$0.1728 / h（東京リージョン実測値）	baseline 約 $0.504 / h + burst 分の秒課金
認証情報	インスタンスプロファイル（IMDSv2）	executionRoleArn（IMDSv2 経由で取得）

検証日は 2026年10月8日、リージョンは東京（ap-northeast-1）です。

▲ AWS Lambda コンソールの「MicroVM Images」画面。作成した sdh-code-server イメージ（8 GB memory / 4 vCPU）と Running 状態の MicroVM インスタンス

▲ ブラウザで開いた code-server。ワークスペース内にハンズオン資産が配置されている

移植における設計ポイント

EC2 環境から MicroVM 環境へ移植するにあたり、以下の 3 点を意識してコンテナイメージと設定を構成しました。

1 点目は、32 GB ディスクの確保です。Lambda MicroVMs のディスク容量はベースラインメモリに連動します（2 GiB で 8 GB、8 GiB で 32 GB）。PyTorch や仮想環境、約 4.4 GB のモデル重みを収容するため、minimumMemoryInMiB を 8192 に設定しました。

2 点目は、CPU 向け PyTorch ホイールの選定です。Graviton 環境における行列演算のハングを回避するため、公式の CPU 向けホイール（download.pytorch.org/whl/cpu の 2.14.1+cpu）を採用しました。CUDA 同梱ホイールに含まれる NVPL BLAS 依存を排除しています。

3 点目は、認証と環境変数の設定です。MicroVM の実行ロールに Amazon Bedrock の権限を付与し、IMDSv2 経由でクレデンシャルを取得させました。また、Strands の既定リージョンが us-west-2 であるため、コンテナ環境変数で東京リージョン（AWS_DEFAULT_REGION=ap-northeast-1）を明示しています。

再現手順

移植コードは公開リポジトリにまとめました。外部ツールに依存しない自己完結型の構成です。

前提ツール（Node.js 22、pnpm、uv）が揃っていれば、以下のコマンドでインフラ構築からイメージ作成、VM 起動まで進められます。

ホストマシンでの再現手順

# 1. 依存関係のインストールとインフラデプロイ
pnpm install && pnpm -C infra install
pnpm -C infra exec cdk deploy --outputs-file cdk-outputs.json --require-approval never

# 2. MicroVM イメージのビルド（約 15 分）
node scripts/gen-config.mjs
node scripts/build-image.mjs

# 3. MicroVM の起動とブラウザ接続
node scripts/mvm.mjs launch --yes
node scripts/proxy.mjs

node scripts/proxy.mjs を実行すると発行されるワンタイム URL をブラウザで開くだけで、演習ファイル一式が配置された code-server に接続できます。詳細なコマンド体系や 6 項目の動作検証スクリプト（verify.mjs）については、リポジトリの README を参照してください。

実機検証の結果

code-server 内のターミナルからハンズオンの各ステップ（Step 1〜7）を実行し、判定結果、処理速度、メモリ保持、費用を測定しました。

判定結果の再現性と一貫性

元記事の EC2 環境における判定結果と、MicroVM 環境での実測値を比較した結果です。

Step	内容	MicroVM 実測値	元記事（EC2）の値	判定結果の整合
1	ask (choice)	請求 0.599 / 技術 0.265 / 営業 0.136、confidence 0.398	請求 0.599 / 技術 0.265 / 営業 0.136、confidence 0.398	完全一致
1	ask (noul)	0.789	0.789	完全一致
1	ask (score)	1.17 (0.139 / 0.552 / 0.310)、confidence 0.516	1.17 (0.139 / 0.552 / 0.310)、confidence 0.516	完全一致
2	serve + curl	{"緊急か":{"noul":0.7894}}、レイテンシ 783 ms	値一致、レイテンシ 約 3000 ms	値一致（速度は MicroVM が優位）
3	tool call intervention	args_grounded 0.16 / premature 0.65 → Guide	args_grounded 0.16 / premature 0.65 → Guide	完全一致
4	escalation gate	p_human: 0.523 / 0.862 / 0.764 / 0.853	5 件とも同じ振り分け	完全一致
5	model router	軽量 0.976 / 0.958、高性能 0.966 / 0.944	4 件とも正しい側へルーティング	一致（※高性能モデルを Haiku に置換）
6	graph routing	請求 0.93 / 技術 0.993 / 営業 0.938	請求 0.671 / 技術 0.993 / 営業 0.938	選択結果一致（請求の確信度のみ差異）
7	tool approval	list 0.06 / read 0.07 / send 0.76 / delete 0.78	list 0.06 / read 0.07 / send 0.74 / delete 0.78	ほぼ一致

Step 5 では、アカウント側で Anthropic Sonnet 4.6 の Marketplace subscription 申請が未完了だったため、呼び出し先を申請済みの Haiku 4.5 に変更して検証しました。Decider によるルーティング判定自体は正しく行われています。

複数回実行してもスコアがぶれにくく、元記事の各クラス確率や緊急度判定の値がそのまま手元で再現されました。出力フォーマットの崩れもなく、エージェントの分岐判定として高い決定性を確認できました。

16 vCPU バーストによる推論の高速化

顕著な差が現れたのは判定の処理速度です。

元記事の EC2 t4g.xlarge（固定 4 vCPU）では、Decider の各判定に約 4300〜5400 ms、HTTP サーバー経由の推論（Step 2）に約 3000 ms を要していました。これに対し、Lambda MicroVMs 上では Step 2 の推論が 783 ms、各ステップの判定も 783〜1328 ms の範囲に収まりました。

Lambda MicroVMs は 8 GiB baseline の設定で最大 16 vCPU までバーストします。テキスト生成を行わない CPU 判定モデルに対して、バーストした CPU リソースが直接寄与し、EC2 の約 3〜4 倍の速度で応答が返る結果となりました。

suspend / resume によるモデル常駐復帰

Lambda MicroVMs の特徴である、メモリ状態をスナップショットへ退避して一時停止する suspend と、そこからの復帰（resume）を検証しました。

ポート 8099 で strands-decider serve を立ち上げ、モデル重みを保持した状態（RSS 約 8.4 GB、プロセス ID 988）で一時停止と再開を行いました。

ホストマシンでの suspend / resume

# ターミナルから一時停止
node scripts/mvm.mjs suspend

# 再開
node scripts/mvm.mjs resume

仮想マシンを再開したところ、strands-decider serve は停止前と同一のプロセス ID（988）で生存していました。サーバーの再起動や重みの再読み込みは一切発生していません。

再開直後の 1 件目の推論リクエストは、メモリのページインを伴うため 7300 ms を要したものの、2 件目以降は通常の約 1000 ms へ復帰しました。

EC2 インスタンスの停止と起動では OS 再ブートに伴いメモリ上のプロセスが消失します。Lambda MicroVMs では、数 GB の重みを常駐させたプロセスごと待機させ、必要なときに数秒で推論可能状態へ戻せる実用性を確認できました。

費用対効果の比較

ハンズオンを想定所要時間の 1.5 時間実施した場合と、終了後に消し忘れた場合の費用比較です（1 ドル = 150 円換算）。

比較項目	EC2 (t4g.xlarge)	Lambda MicroVMs (4vCPU/8GiB)
時間単価	$0.1728（約26円）	$0.5048（約76円）
通常利用（1.5h）	$0.26（約39円）	$0.76（約114円）
消し忘れ（24h後）	$4.15（約622円）	$4.04（約606円）
自動終了	なし	8時間後

時間あたりの単価を比べると、Lambda MicroVMs は EC2 の約 3 倍の費用がかかります。通常利用（1.5 時間）の範囲であれば、EC2 が約 39 円、MicroVM が約 114 円と、どちらも数十円から百円強の範囲に収まります。

注目すべきは「消し忘れ」のシナリオです。EC2 は自動終了の仕組みを持たないため、停止や削除を忘れて放置すると 24 時間で約 622 円（＄4.15）まで課金が膨らみます。これに対し、Lambda MicroVMs には最大実行時間（8 時間後）により自動終了します。そのため、仮に丸一日放置してしまっても 8 時間時点で自動停止し、最大でも約 606 円（＄4.04）にとどまります！

また、作業の合間に suspend を挟む細切れ利用であれば、コンピュート課金（秒課金）を完全に止められます。SUSPENDED 状態の維持費用はスナップショット保管料（$0.08 / GB・月）のみとなるため、実稼働時間が短い検証ほどコスト効率が向上します。

検証完了後は VM を即座に terminate してコンピュート課金を停止しました。残るイメージバージョンや CDK スタックも、追加検証が不要になり次第削除する運用としています。

実践で見えたメリットと制約

EC2 向けのハンズオンを自作の Lambda MicroVMs 環境へ移植したことで、得られた手応えと運用の注意点の双方が見えてきました。

メリットの 1 つ目は、数 GB クラスのモデル常駐環境をオンデマンドで扱える点です。約 8.4 GB のメモリを確保したプロセスを数秒で起動・中断・再開できるため、常時起動のコストを払わずにモデルを待機させられます。

2 つ目は、CPU 判定モデルとの相性の良さです。最大 16 vCPU のバーストにより、軽量判定モデルが 1 秒前後で軽快に動作しました。

3 つ目は、使い捨て環境としての扱いやすさです。EC2 のようなリソース消し忘れによる長期課金リスクを抑えやすく、不要になった時点でクリーンアップが容易でした。

運用の注意点と前提条件

• 初期アカウントのメモリクォータ: 開設直後の AWS アカウントではベースラインメモリ枠が 8 GB に制限されているため、8 GiB baseline の VM は同時 1 台までしか起動できません（2 台目は ServiceQuotaExceededException）。複数台を動かすには事前のクォータ引き上げ申請が必要です。
• 連続稼働コストの高さ: 長時間連続して起動し続ける用途では EC2 のほうが明確に安価です。MicroVM の強みを活かすには、作業の合間に suspend を挟む運用設計が欠かせません。
• Bedrock の Marketplace 申請: Step 5 で扱う Claude Sonnet などのモデル呼び出しには、IAM 権限とは別にアカウント側で AWS Marketplace のサブスクリプション申請が必要です（未申請時は AccessDeniedException）。

Strands Decider のような数 GB クラスのモデルを動かすハンズオンや検証において、Lambda MicroVMs は「高速な起動と推論」「状態保持による中断」「安全なコスト管理」を両立できる実用的な基盤でした。

今回の環境を手元で試したい方は、公開リポジトリの手順に沿って動かしてみてください。