「サーバレスで安く軽く作るつもりで始めたのに、途中で状態を持つ処理が出てきて詰まりました。結局そこだけコンテナに逃がして、運用が二系統に分かれてしまったんです」——システム開発の相談を受けると、こういう打ち明け話が驚くほどよく出てきます。最初の設計は正しかった。Lambda で組めば、サーバを持たず、使った分だけ払い、急なアクセスにも勝手に伸びる。ところが作り込むうちに、ユーザーのセッションをまたいで状態を覚えておきたい処理や、十数分では終わらない重い処理が現れる。Lambda の前提から外れた瞬間、設計は静かに崩れ始めます。
そこで多くの現場が取る回避策は決まっています。一つの処理を無理やり細切れのステップに割って状態を外部 DB に退避する。あるいは、その部分だけ ECS や Fargate のコンテナに切り出す。どちらも動きはします。ただ、前者はロジックが分割の都合でねじれて読めなくなり、後者はサーバレスとコンテナの運用が二重になって、監視も権限もデプロイも二系統を抱えることになる。「安く作る」はずが、いつのまにか一番の負債を背負っている。2026 年 6 月 22 日に AWS が発表した Lambda MicroVMs は、この板挟みにちょうど効く新しい選択肢です。ただし万能薬ではありません。本記事では、何を解いて何を解かないのかを冷静に切り分けます。
なぜ従来の Lambda では「状態」と「長時間」で詰まるのか
まず、Lambda がなぜこの二点で壁に当たるのかを押さえておきます。これは欠陥ではなく、設計思想そのものです。
Lambda は一回の呼び出しを使い捨てる前提で作られています。関数が起動し、処理して、終わったら環境ごと破棄される。だから速く、安く、勝手にスケールする。その代わり、呼び出しをまたいで状態を覚えておくことは原則できません。ユーザーが操作を続ける対話型のセッションや、計算の途中経過を抱え込むような処理とは、根本的に相性が悪い。さらに実行時間にも上限があり、長く回り続ける処理はそのままでは収まりません。隔離の粒度も、同じ実行環境が使い回される前提のため、「他人が書いたコードを安全に走らせたい」といった用途には粒度が粗すぎる場面があります。
この性質を回避しようと、状態を DynamoDB や Aurora に逃がし、処理を Step Functions で細かく繋ぎ直す。設計としては定石ですが、本来一続きだったロジックが外部ストアと状態遷移図に散らばり、追いかけるのが一気に難しくなる。DB 側の近代化で逃がし先を整える発想は Aurora Serverless v4 でのDB近代化 でも触れていますが、それでも「状態を外に出す」こと自体のコストは消えません。Lambda MicroVMs は、ここを別の角度から崩します。
Lambda MicroVMs が変えるのは「実行環境を持ち続けられる」こと
Lambda MicroVMs は、ひとことで言えば「サーバレスの手軽さのまま、状態を保持できて、強く隔離された実行環境」を提供する仕組みです。AWS は、これを Lambda 関数を支えてきたのと同じ軽量仮想化技術 Firecracker の上に構築しています。
肝は三つです。一つ目は状態の保持。起動した MicroVM はメモリ・ディスク・実行中のプロセスをセッションをまたいで保持し、アイドル時には状態を保ったまま中断（サスペンド）でき、アクセスが来たら再開する。AWS の発表では、状態は最長 8 時間保持できるとされています。二つ目は隔離。セッションごとにカーネルもリソースも共有しない VM レベルの隔離されたサンドボックスを与えられるため、利用者や AI が書いたコードを安全に走らせたい用途に向きます。三つ目は起動の速さ。Dockerfile とコードから MicroVM イメージを作る際に、初期化済みの状態を Firecracker のスナップショットとして取っておき、以降はそこから再開するため、コールドブートを避けてほぼ瞬時に立ち上がります。
作り方の流れもイメージしておくと判断しやすくなります。
1. Dockerfile + コード（S3上のzip）を用意する
2. Lambda が Dockerfile を実行し、アプリを初期化
3. 初期化済みの状態を Firecracker スナップショットとして保存
4. 以降の起動・再開はスナップショットから復元（≒コールドブート回避）提供は ARM64 アーキテクチャ上で、1 つの MicroVM あたり最大 16 vCPU・32 GB メモリ・32 GB ディスクまで。リージョンは米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、欧州（アイルランド）、そしてアジアパシフィック（東京）から始まっています。東京リージョンが初日から入っているのは、国内向けの受託で検討する側にとって素直に効きます。
「向く処理」と「向かない処理」を取り違えない
ここが本記事で一番伝えたいところです。Lambda MicroVMs は従来の Lambda の置き換えではありません。狙いどころがはっきり違います。
AWS が主用途として挙げているのは、利用者や AI が生成したコードを各ユーザー専用の環境で安全に走らせる類のアプリケーションです。具体的には、ブラウザ上の対話型コーディング環境、データ分析プラットフォーム、AI コーディングアシスタント、脆弱性スキャナ、利用者が書いたスクリプトを動かすゲームサーバ、といった「他人のコードを、隔離して、状態を持たせて、ある程度の時間走らせたい」処理です。AI エージェントに自由にコードを実行させるサンドボックスとしての相性も語られています。
逆に、従来の Lambda が得意としてきた領域——短く終わるイベント駆動の処理、API のバックエンド、ファイルアップロードをトリガにした変換、定期バッチのキック——は、これまで通り素の Lambda で組むのが正解です。ここに MicroVMs を持ち込むと、過剰な隔離と保持の仕組みを抱え込むだけで、コストも複雑さも増えます。判断の軸は単純で、「呼び出しごとに使い捨ててよい処理」か「セッションを持ち続けたい・他人のコードを隔離したい処理」か。前者は素の Lambda、後者が MicroVMs の領分です。HTTP アプリをサーバレスへ寄せる移行は Lambda Web Adapterでの移行 の方が筋がいい、というように、選択肢は処理の性質で割り振るものです。
コストの考え方が Lambda とは別物になる
発注を検討する側が見落としやすいのが、課金の考え方が従来の Lambda と変わる点です。ここを Lambda の感覚で見積もると、予算がずれます。
従来の Lambda はリクエスト単位・ミリ秒単位の従量課金で、「使った瞬間だけ払う」のが大きな魅力でした。Lambda MicroVMs はこれより、コンテナを常駐させる Fargate に近い考え方になります。秒単位で課金され、ベースとなる構成を決め、そこから上振れするバースト分と、一つの代表的なセッションを起動から中断・終了までモデル化して見積もる、という発想です。一方で、アイドル時にサスペンドした MicroVM は、スナップショットの保管料はかかるものの稼働中の計算課金は発生しないとされています。つまり「使い続けたいが、ずっと動かしているわけではない」対話型の用途では、常時起動のコンテナより無駄を抑えられる可能性がある。
| 観点 | 従来の Lambda 関数 | Lambda MicroVMs |
|---|---|---|
| 状態 | 原則ステートレス（使い捨て） | セッションをまたいで保持（最長8時間） |
| 課金の発想 | リクエスト・ミリ秒単位の従量 | 秒単位、Fargate 寄りの容量見積もり |
| 向く処理 | 短いイベント駆動・API バックエンド | 対話型セッション・他人のコードの隔離実行 |
このコスト構造を理解せずに「サーバレスだから安いはず」と進めると、想定より高くつく。逆に、向いた用途で常駐コンテナから移せば下がる余地もある。クラウドコストを処理の性質ごとに可視化して見極める姿勢は AWS FinOps Agentでコスト可視化 で扱った考え方とそのまま地続きです。
事例: コンテナに逃がした「分析サンドボックス」を一本化した
具体例を挙げます。社員規模 60 名ほどの SaaS を手がける事業者（社名は伏せます）から、「自社サービスの中で、ユーザーがアップロードしたデータに対して任意の分析スクリプトを走らせる機能があるのだが、運用が重くて困っている」という相談を受けました。元々はメインの API を Lambda で組んでいたものの、この分析機能だけは「ユーザーの書いたコードを安全に・長めに走らせる」必要があり、Lambda では収まらず ECS の常駐コンテナに切り出していたのです。
問題は二つありました。一つは、利用がない深夜帯もコンテナが立ちっぱなしで、計算リソースの料金が一日中かかり続けていたこと。もう一つは、メインがサーバレス、分析だけがコンテナという二系統構成のせいで、デプロイ手順も監視も IAM の権限設計も二重になり、担当者の頭の中が常に分かれていたことです。新機能を出すたびに、両方を意識する負担が地味に効いていました。
私たちはまず、この分析機能の使われ方のログを二週間分そろえてもらいました。すると、実際にスクリプトが走っているのは平日日中に偏り、夜間と休日はほぼ無稼働。一回の分析セッションも長くて十数分で、8 時間の保持上限には遠く及ばない。これは Lambda MicroVMs の「隔離された状態あり環境を、必要なときだけ立ち上げ、アイドル時はサスペンド」という形に素直にはまる、と判断しました。そこで、東京リージョンで分析サンドボックス部分を MicroVMs に載せ替え、メイン API は従来の Lambda のまま据え置き。結果として、夜間・休日の無稼働時間に計算料金が乗らなくなり、コンテナの常駐運用がなくなったぶん、デプロイと監視を Lambda 系に寄せて一本化できました。いちばん効いたのは、機能を丸ごと移さず、処理の性質ごとに「ここは素の Lambda、ここだけ MicroVMs」と線を引いたことです。流行りものに全部を寄せず、向いた一区画にだけ当てたから、運用がむしろ軽くなりました。
飛びつく前に、自社の処理を二つに仕分ける
Lambda MicroVMs は確かに新しい引き出しですが、検討の入口でやるべきは、新機能の調査ではありません。自社のどの処理がこれに向くのかを仕分けることです。
まず確かめたいのは、「状態を持ちたい・他人のコードを隔離したい」処理が実際に自社にあるか。対話型のセッション、ユーザーや AI が書いたコードの実行、長めに走る分析——こうした性質を持つ処理がなければ、そもそも MicroVMs の出番はなく、素の Lambda で組むのが正解です。次に、もしコンテナに逃がしている処理があるなら、それが常時稼働を必要としているのか、アイドル時間が多いのかを稼働ログで見ること。アイドルが多い対話型なら、サスペンドできる MicroVMs で無駄を削れる可能性が高い。逆に、常に高負荷で回り続ける処理は、無理に動かすより従来の構成のままが妥当な場合もあります。発表されたばかりの機能なので、本番採用の前には小さな一区画で挙動とコストを確かめる段取りも欠かせません。
サーバレスで作ったが状態を持つ処理で詰まってコンテナに逃がした、運用が二系統に分かれて重くなった、新しい Lambda MicroVMs が自社のどの処理に効くのか冷静に見極めたい——そうしたお悩みがあれば、グリームハブの開発・AI・自動化のご相談窓口からお問い合わせください。現在のアーキテクチャと処理ごとの稼働実態を拝見し、どこを素の Lambda のまま残し、どこを MicroVMs に寄せ、どこは従来の構成が妥当かを、コストの試算まで含めて率直にお見立てしたうえで、移行とその後の運用一本化までご一緒します。
Sources
- Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs － AWS News Blog
- AWS introduces Lambda MicroVMs for isolated execution of user and AI-generated code － AWS What’s New
- AWS Lambda MicroVMs － AWS
- AWS debuts Lambda MicroVMs with up to 8 hours runtime － The Register
- What you need to know about Lambda MicroVMs － theburningmonk.com
