Lambda microVMs，從零講起——Firecracker snapshot 怎麼讓「VM 級隔離」也能秒啟又保狀態

讀完這篇之後，你會知道一件事：AWS 在 6 月 22 日上線的 Lambda microVMs，並不是「Lambda function 變大隻」，而是把 Firecracker 的 snapshot 與 suspend/resume 兩個底層能力，包成了兩個可以直接呼叫的 API。文章會先把你手上那個沙箱需求攤開，再講為什麼 VM 與 container 都各差一截，然後逐層拆 snapshot、suspend/resume、stateful execution 三個機制——你會看到「VM 級隔離又能秒啟又保狀態」這組看似互斥的條件，是怎麼靠一份預先初始化的記憶體快照同時成立的。

那段你不敢直接 exec 的程式碼——沙箱的三個不可能三角

先把場景講具體。你在做一個會幫使用者跑程式碼的服務：可能是 AI coding assistant，使用者要它「寫個爬蟲然後跑跑看」；可能是線上的互動式程式碼環境，使用者在瀏覽器裡敲 Python 按執行；可能是資料分析平台，讓人上傳 notebook 自己跑。AWS 自己列的場景就是這幾類——原文寫的是「AI coding assistants, interactive code environments, data analytics platforms, vulnerability scanners, and game servers that run user-supplied scripts」。漏洞掃描器與跑使用者腳本的遊戲伺服器也在同一張清單上。

這些工作有一個共同的形狀：你要執行的程式碼，不是你寫的。它可能是使用者貼的，可能是 LLM 生出來的。你不能假設它善良。它可能想讀別的租戶的資料、想打你的內網、想把整台機器的 CPU 吃乾。所以第一個要求是隔離——而且是強到敢拿來裝不可信程式碼的隔離。

第二個要求是快。這是互動式工作：使用者按下執行，等三分鐘才看到環境起來，這個產品就死了。啟動延遲必須低到使用者感覺不到。

第三個要求最容易被忽略，但最關鍵：保狀態。使用者跟 AI 來回對話，第一輪裝了 numpy，第二輪要它畫圖。如果每一輪都是全新環境，前一輪 pip install 的東西全沒了，每次都要重裝。一個互動 session 裡，環境必須記得上一步——記憶體裡的變數、磁碟上裝好的套件、還在跑的 process，都要在。

強隔離、低延遲、保狀態。麻煩在於，市面上現成的兩個工具，各自只給你其中兩個。

VM 給你隔離但慢，container 給你快但要自己 hardening

傳統虛擬機是隔離的標準答案。每個 VM 有自己的 guest kernel，靠硬體虛擬化把租戶之間隔開——這道邊界夠硬，硬到雲廠商敢拿來做 multi-tenant。問題出在啟動。AWS 在公告裡的講法很直白：「Virtual machines deliver strong isolation but take minutes to start.」隔離強，但啟動以分鐘計。對一個使用者按下執行就要看到結果的互動產品來說，分鐘級的冷啟動是不能接受的。

那 container 呢？container 的賣點正好是 VM 的痛點：秒級啟動。同一份公告接著說「Containers launch in seconds, yet their shared-kernel architecture requires significant custom hardening to safely contain untrusted code.」秒啟沒問題，但 container 共用主機的 kernel——所有 container 跟宿主機跑的是同一個 Linux kernel，隔離靠的是 namespace 與 cgroup 這類 kernel 功能，而不是一道硬體邊界。要拿這種東西去裝不可信程式碼，你得自己堆上大量的自訂 hardening：seccomp profile、user namespace 重映射、gVisor 之類的 syscall 攔截層。這些都做得到，但都是你自己的責任，做錯一個地方就是一個逃逸。

把這兩端放進一張圖會更清楚。一個軸是隔離強度，一個軸是啟動延遲。VM 落在「隔離強、啟動慢」那一角；container 落在「啟動快、隔離靠自己補」那一角；傳統的 Lambda function 啟動極快，但它的模型是短命、無狀態、一次呼叫做完就回收，不是給你開一個能保狀態的長 session。三個既有選項，沒有一個剛好落在你要的位置。

新原語：把 Firecracker 包成兩個 API

AWS 給這個缺口的答案，自己定義得很精準：「AWS Lambda MicroVMs, a new serverless compute primitive within AWS Lambda that lets you run code generated by users or AI in isolated, stateful execution environments.」一個新的 serverless compute primitive，專門拿來跑使用者或 AI 生成的程式碼，環境同時是 isolated 與 stateful。注意這兩個形容詞——隔離與保狀態——正是上面那張圖左上角缺的那一塊。

底層是什麼？公告寫得直接：「Lambda MicroVMs are powered by Firecracker, the same lightweight virtualization technology that has powered over 15 trillions of monthly Lambda function invocations.」Firecracker 不是新東西，它就是撐起 Lambda 每月逾 15 兆次呼叫的那套輕量虛擬化（原文寫 15 trillions，照引）。要理解 microVM 為什麼能同時做到隔離與快，得先看一眼 Firecracker 本身。

Firecracker 對自己的定位是「an open source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services」。它跑出來的東西叫 microVM——「lightweight virtual machines, called microVMs, which provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers」。這句話就是整個「兼得」的根：比傳統 VM 更強的安全與隔離，同時有 container 的速度與資源效率。

它怎麼做到的？兩個關鍵。一是隔離邊界用的是真的虛擬化——Firecracker 用 Linux 的 KVM 來建立與管理 microVM，每個 microVM 是一個有自己 guest kernel 的虛擬機，這道邊界跟傳統 VM 同級，不是 container 那種 shared-kernel。二是它把開機慢的原因砍掉了——Firecracker 配的是「a minimal device model that excludes all non-essential functionality」，一個最小化的裝置模型，只留 virtio-net、virtio-block、virtio-vsock、serial console 與 keyboard controller 五個模擬裝置，其餘非必要功能全砍。沒有那一堆要初始化的虛擬硬體，開機自然快。具體有多快？Firecracker 的數字是「initiates user space or application code in as little as 125 ms and supports microVM creation rates of up to 150 microVMs per second per host」——最快 125 ms 起 user space，每台 host 每秒最多建 150 個 microVM。每個 microVM 的記憶體 overhead「less than 5 MiB」，所以單機可以塞得很密。

但 125 ms 是 Firecracker「冷啟動一個全新 microVM」的數字。Lambda microVMs 真正的招數，不是冷啟動更快，而是根本不冷啟動。下面這張圖把兩個新 API 的流向攤開——你會看到 snapshot 是在哪一步產生的。

不冷啟動：snapshot 怎麼把開機這件事提前做完

把上面那條流程的兩半分開看，整個機制就清楚了。傳統做法裡，「啟動一個環境」是這樣的：開機 kernel、起 init、跑你的 entrypoint、import 一堆套件、把應用初始化到可以接請求的狀態。這一連串步驟，每次啟動都得重來一遍——這就是 cold boot，慢的就是這一段。

Lambda microVMs 的做法是：把這一整段「開機到初始化完成」只做一次，做在建構期。create-microvm-image 跑你的 Dockerfile、把應用實際初始化起來，然後對這個「已經跑起來、隨時可以接請求」的環境取一份 Firecracker snapshot——把當下的 memory 與 disk 狀態整個凍存下來。之後 run-microvm 要起一個新 microVM，它不從開機開始，而是直接把這份 snapshot 載回 memory，從凍存的那一刻繼續跑。原文的句子值得再看一次：「resumes from the pre-initialized snapshot rather than booting cold」。從預先初始化的快照 resume，而不是冷開機。

這就是為什麼公告敢說 launch 與 idle resume 都是 near-instant startup latency。要注意的是，原文用的是「near-instant」這個詞，沒給確切毫秒數——Firecracker 文件裡那個 125 ms 是它冷啟一個全新 microVM 的數字，不能直接當成 Lambda microVMs 從 snapshot resume 的延遲。合理的推測是，從 snapshot resume 比冷啟還要快，因為連那 125 ms 的開機都省了——但這是推斷，公告沒給數字。

值得停下來想一下，為什麼「VM 級隔離、又能秒啟」這組合過去很難同時成立。VM 慢，慢在它每次都得從一張空白的虛擬硬體開始：BIOS、bootloader、guest kernel、device probe、init 系統，這一整套是為了「從零點亮一台機器」設計的，而你的應用要等這套全跑完才輪得到。container 之所以快，正是因為它跳過了這一整段——它共用宿主機已經開好的 kernel，省下的就是開機。snapshot 的巧妙在於，它讓你保留 VM 的硬體邊界（隔離），卻又不必每次付那段開機代價（速度）：把「開機到應用就緒」的結果凍成一份 memory image，啟動時不是重做這段，而是把結果直接貼回去。換句話說，它不是讓開機變快，是讓開機只發生一次、發生在沒有使用者在等的建構期。隔離與速度之所以以前像是二選一，是因為大家都把「啟動」當成一件每次都得重來的事；snapshot 把它變成可以預先算好、重複套用的東西。

下面這張圖把 cold boot 與 snapshot resume 兩條啟動路徑並排，你可以拖中間那條分隔線比對：左邊是每次都要走完的那串開機步驟，右邊是直接把凍存狀態載回來。

保狀態與 suspend：同一個 session 裡記得上一步，閒置時不白燒

snapshot 解決了「啟動慢」。但前面講的三個要求還有第三個：保狀態。這一塊是 microVM 跟傳統 Lambda function 模型分家的地方。

傳統 function 是無狀態的：一次呼叫進來、跑完、回收，下一次呼叫可能落在完全不同的執行環境，前一次留下的任何東西都不保證在。microVM 反過來。公告講得很清楚：「Each MicroVM gives a single end user or session its own isolated environment that launches rapidly, retains memory and disk state for the length of the session.」一個 microVM 綁一個 end user 或 session，在整個 session 期間保留 memory 與 disk 狀態。再具體一點：「A running MicroVM retains memory, disk, and running processes across the user's session.」連 running processes 都保留——你 session 裡背景跑的那個 process，下一個請求進來時它還在跑。

這直接對上了 coding assistant 的需求。使用者第一輪叫它 pip install，套件裝進磁碟；第二輪叫它 import 來用，磁碟還在、import 得到。中間那個 Python interpreter 的 process 也還活著，記憶體裡的變數都在。對使用者來說，這就是一個連續的 session，而不是每輪都重來的孤立呼叫。

要看出這跟傳統 function 模型差多遠，把同一個情境放回 function 上想一遍：第二輪請求很可能落在另一個全新的執行環境，上一輪裝的套件、開的檔案、跑到一半的 process 全部不在，你只能靠外部儲存（S3、EFS、資料庫）把狀態存出去再讀回來——也就是把「保狀態」這件事自己用一層持久化邏輯補出來。microVM 把這層手工補出來的持久化收進了平台本身：狀態就活在這個 microVM 的 memory 與 disk 裡，不必序列化出去、不必每輪重建，因為它根本沒換環境。隔離單位從「一次呼叫」上移到了「一個 session」，這是模型層面的轉變，不只是規格放大。

但保狀態有代價：一個 microVM 綁定一個 session，session 沒結束，這個 microVM 就一直佔著。使用者去開會了，環境空轉半小時，你卻還在為它付錢——這正是 container 長 session 方案的老問題。microVM 的解法是 suspend。公告寫：「During idle periods, a MicroVM can be suspended – with memory and disk state intact – and resumed when traffic arrives.」閒置期間，microVM 可以被 suspend，而且 memory 與 disk 狀態原封不動地保留；有流量再 resume。配合前面講的 snapshot resume 機制，這個 resume 也是 near-instant 的——使用者開完會回來敲下一行，環境瞬間回來，狀態都還在，他不會察覺中間被 suspend 過。公告對閒置狀態的成本描述是「pauses to a low idle cost when the user steps away」，用的是 low idle cost，沒給具體價格。

什麼時候 suspend、suspend 多久、要不要自動 resume，由一個 idle policy 控制。公告給的範例長這樣：

--idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

三個欄位：maxIdleDurationSeconds（閒置多久後動作，範例 900 秒）、suspendedDurationSeconds（suspend 狀態維持多久，範例 300 秒）、autoResumeEnabled（要不要在流量來時自動 resume，範例 true）。這是 run-microvm 的參數，等於讓你自己定義「活躍 → 閒置 → suspend → resume」這個 session 生命週期的節奏。

這幾個旋鈕背後是一個你得自己拿捏的取捨。idle 門檻設得短，閒置一下就 suspend，省成本，但代價是使用者稍微停頓、回來時就得吃一次 resume；設得長，使用者體感更順，但閒置期間你付的就不是 low idle cost 而是接近活躍的成本。suspendedDurationSeconds 則決定狀態能凍存多久——超過這個窗口，這個 session 大概就被當成結束、資源釋放。autoResumeEnabled 決定喚醒是平台幫你做、還是要靠你的應用層自己觸發。換句話說，idle policy 不是一個開關，而是讓你在「成本」與「使用者體感的連續性」之間畫一條線，按你的工作負載特性去調。

下面這個模擬把一段 session 跑給你看：play 之後 play head 沿時間軸前進，使用者活躍、閒置、被 suspend、再被喚醒，下方那條成本帶會在 suspend 時掉下去，而那一格代表「memory 狀態保留」的指示燈全程亮著——這就是 stateful execution 與 suspend/resume 合在一起的樣子。

邊界在哪：ARM64、16 vCPU、8 小時，與四個區域

機制講完，落到工程決策前你得先看清楚硬邊界——一個 microVM 不是無限大的機器，它有很明確的上限。公告把規格列得很清楚，逐項照引：架構是 ARM64；最高 up to 16 vCPUs；32 GB of memory；每個 microVM 32 GB of disk；單次最長 MicroVMs support up to 8 hours of total runtime。下面這幾張卡把這些上限攤開。

這幾個數字框出了它的甜蜜區。ARM64 唯一架構，意味著你的 image 與相依套件得在 ARM64 上跑得起來——x86-only 的二進位檔要先解決。16 vCPU / 32 GB 記憶體 / 32 GB 磁碟，對一個互動式 coding 或資料分析 session 綽綽有餘，但不是給你跑大型訓練或巨量資料批次的規格。單次最長 8 小時，這條最值得留意：它擺明了 microVM 是給「有人在用的 session」，不是給你當常駐服務跑——一個 session 撐到 8 小時就到頂，這跟「per end user / per session」的定位是一致的。

區域目前只有四個：US East（N. Virginia、Ohio）、US West（Oregon）、Europe（Ireland）、Asia Pacific（Tokyo）。台灣團隊離得最近的是 Tokyo，延遲上可以接受；但如果你的使用者在歐洲與美東以外、又對延遲敏感，現階段就得自己權衡。發布狀態是 2026 年 6 月 22 日的「Now available」，不是 preview——可以直接拿來上。價格公告沒列在文內，只說在 Lambda pricing page 上。

那什麼工作真正適合搬上來？回到 AWS 自己列的那張場景清單，把它們的共同點抽出來就清楚了：AI coding assistant、互動式程式碼環境、資料分析平台、漏洞掃描器、跑使用者腳本的遊戲伺服器——這幾類全都同時要求「per-session 的強隔離」「保得住 session 內狀態」「啟動與喚醒要快」這三件事。過去你得在 container 上自己堆 hardening 才能勉強湊齊，現在這三件由一個原語一次給。反過來說，如果你的工作不需要隔離不可信程式碼、或根本不需要保狀態、或不在乎冷啟動延遲，那 microVM 對你就是殺雞用牛刀，傳統 function 或 container 仍然更省。它補的是一個很具體的縫，不是要取代誰。

The model：microVM 不是更大的 function，而是一份「預先開機到一半、隨時可以喚醒」的 Firecracker 快照——隔離來自 VM 的硬體邊界，速度來自不冷啟動，保狀態來自整個 session 綁同一個 microVM，省錢來自閒置時 suspend 而狀態不丟。