摘要： AWS 於 2026 年 6 月 22 日推出 Lambda MicroVMs，讓每個使用者或任務取得專屬沙箱，用來隔離執行不受信任程式碼。文章說明 Firecracker 快照支援近乎即時啟動與狀態回復，目前單機最長 8 小時，上限為 16 vCPU、32 GB 記憶體與磁碟，且只支援 ARM64。
2026 年 6 月 22 日，AWS 透過官方部落格替 Lambda 產品線添了一名新成員：Lambda MicroVMs。它的定位是專門用來隔離執行不受信任程式碼的無伺服器運算單元，公告裡也直接點出四種鎖定場景——AI 編碼助理、互動式程式設計環境、資料分析平台，以及漏洞掃描服務。這四者有個共同的麻煩：都得替每一位使用者、每一項任務準備專屬沙箱，而這件事放到傳統架構裡從來沒有順手過。
AWS 把過往的情況說成一道被迫的選擇題：只能在「隔離、速度、狀態保留」之間擇一兼顧。MicroVMs 的目標，就是讓這道選擇題直接消失。
隔離、速度、狀態，三者難以兼得
三種既有做法各有一處短板。虛擬機器把隔離做到最好，代價是開機時間動不動就以分鐘計；容器雖然啟動俐落，共享核心的設計卻逼你在跑不信任程式碼之前先完成大量加固；FaaS 天生適合請求回應型工作負載，碰到要保住狀態的長時間互動工作階段就撐不住。一款要讓使用者一邊寫、一邊執行程式碼的產品，在這三個選項裡怎麼挑都只能妥協。
MicroVMs 的解法是讓每位使用者或每項任務各擁有一台專屬 MicroVM：核心不共享、資源不共享，一旦出事，波及範圍就被封死在單一實例裡。AI 編碼助理要的正是這種保證——模型寫出的程式碼可能有錯，甚至帶有惡意，但無論如何不能傷到同一時間並行運作的其他使用者。
秒級啟動的關鍵：Firecracker 快照
技術底層是 Firecracker，也就是同樣在背後支撐 Lambda Functions 的輕量級虛擬化技術，AWS 稱它每月要處理超過 15 兆次函式呼叫。使用模型是「先建映像、再啟動」：開發者備妥 Dockerfile，並將程式碼以壓縮檔形式放上 S3；服務接著建置映像、完成應用初始化，然後對記憶體與磁碟狀態擷取一份 Firecracker 快照。此後每一台 MicroVM 都從快照回復，不必冷開機——就算工作階段高達數 GB，也能近乎即時啟動。
規格數字如下：一台 MicroVM 最長執行 8 小時，配備上限 16 vCPU、32 GB 記憶體與 32 GB 磁碟，架構目前僅支援 ARM64。
暫停、回復與專屬端點
狀態保留是另一個主打功能。執行中的 MicroVM 會連同記憶體、磁碟與行程一併留下——裝過的套件、載入的模型、手邊正在處理的檔案，歷經暫停與回復後原封不動。暫停可以透過 API 手動觸發，也可以交給閒置政策自動處理；官方示範將閒置門檻設在 900 秒並啟用自動回復，客戶端幾乎感覺不到過程發生。
連上沙箱不需要任何網路設定：MicroVM 啟動後即取得專屬 HTTPS 端點，流量以 X-aws-proxy-auth 標頭中的短效權杖完成驗證。公告頁面還提到端點支援 HTTP/2、gRPC 與 WebSockets，並可從主控台、CloudFormation、CDK 或 Agent Toolkit 加以管理。計費結構是執行期間收基礎運算費用，活躍時段超出基準的部分才另外計費；把閒置中的 MicroVM 暫停，既壓低成本又不損失狀態。
一點提醒：實例是從預先初始化過的快照回復而來，若應用會在初始化階段產生唯一性內容或建立網路連線，就要搭配服務提供的掛鉤來處理。首波共五個區域開放：美東（北維吉尼亞、俄亥俄）、美西（奧勒岡）、歐洲（愛爾蘭）與亞太（東京）。
這對 Agent 開發者代表什麼
在 AWS 的規劃裡，MicroVMs 與既有服務是互補而非取代：Lambda Functions 繼續擔任事件驅動的骨幹，流程中需要隔離執行不信任程式碼的步驟則轉交 MicroVMs，兩者還能互相呼叫。對正在組裝 agent 工具鏈的團隊來說，「程式碼執行」這一環多了全代管選項，不必再親自維護 Firecracker 叢集，也不用費工加固容器環境。
兩條界線要先想清楚：僅支援 ARM64，代表相依 x86 套件的應用得先完成移植；8 小時上限，也讓它接不住生命週期更長的常駐服務。但對「每次任務一個乾淨沙箱」的 agent 執行模式而言，這兩項限制幾乎不構成阻礙——真正值得注意的是暫停回復與專屬端點：過去得自行打造的一整段基礎設施，如今收斂成一次 API 呼叫。