AWS Firecracker 論文導讀：AWS 為什麼用 microVM 支撐 Serverless
Firecracker 是 AWS 開源的 Virtual Machine Monitor，用來執行輕量級的 microVM。它最常被提到的原因，是 AWS Lambda 底層使用了這套技術：AWS 需要快速啟動隔離的執行環境，在大型主機上承載大量租戶，同時保留使用者對虛擬機隔離邊界的安全期待。
AWS 在 2018 年 Firecracker 發表文章中，也曾描述 Fargate Tasks 會執行在 Firecracker microVMs 上。不過這句話需要平衡看待：Fargate 是託管的 container compute service，Firecracker 並不是 Fargate 對使用者暴露、可依賴的產品介面或契約。這篇文章提到 Fargate 時，會把它視為 AWS 官方曾公開說明 Firecracker 影響 serverless container runtime layer 的例子，而不是主張「每一種 Fargate 模式或平台細節都等同於每個 container 一個 Firecracker microVM」。
Firecracker 論文有意思的地方，不是單純說「container 很快」或「VM 比較安全」。它真正的設計取捨更務實：保留硬體虛擬化帶來的強隔離，拿掉通用 VMM 裡 serverless worker 不需要的裝置與平台複雜度，並在 Linux 已經有成熟機制的地方直接重用。
本篇為我對於 Firecracker 論文的理解。原始論文本身不難讀，但它牽涉到 hypervisor、KVM、Linux isolation primitives、Lambda worker 架構與效能取捨；如果只是照著論文順序看，很容易知道每個元件做什麼，卻不一定看出 AWS 為什麼要做這樣的工程選擇。
Firecracker 要解決什麼問題
Serverless 平台需要同時滿足幾個不容易一起做到的條件：
- 隔離性：不同客戶之間不能只靠薄弱的安全邊界。
- 高密度：單一 host 應該能跑上千個執行環境。
- 低額外成本：每個環境閒置時不應該吃掉太多 memory 或 CPU。
- 快速啟動：cold start 必須低到足以支援互動式 workload。
- 相容性：客戶應該能執行一般 Linux binary 與 library。
- 維運簡單：平台團隊要能用熟悉的 Linux 工具觀察、限制與管理資源。
Linux container 輕量、啟動快，但它共享 host kernel。傳統 VM 的隔離比較強，但像 QEMU 這類通用虛擬化 stack 會帶進大量裝置模型、更大的 emulation surface，以及 serverless worker 不一定需要的額外負擔。
Firecracker 走的是中間路線：每個 workload 跑在 KVM 支撐的 microVM 裡，而 VMM 只支援 serverless 與 container workload 真正需要的一小組裝置與操作。
我自己讀完後的理解是：Firecracker 並不是要證明 VM 或 container 哪一邊比較好，而是 AWS 在 serverless 這個使用情境裡「不想二選一」。它想要 container 接近的密度與啟動速度，也想要 VM 更清楚的安全邊界；Firecracker 的價值就在於把問題範圍縮到足夠小，讓這兩件事可以同時成立。
基本名詞
在看 Firecracker 前，先把幾個常被混在一起的名詞拆開。
Hypervisor
Hypervisor 提供虛擬化層，讓多個 guest operating systems 可以跑在同一台實體機器上。Type 1 hypervisor 直接跑在硬體上，或在非常接近硬體的 privileged 位置；Type 2 hypervisor 則跑在一般 host operating system 之上。
KVM 讓 Linux kernel 變成 hypervisor，並把硬體虛擬化能力暴露給 user-space VMM 使用。
VMM
Virtual Machine Monitor 負責建立與管理 VM。它會設定 vCPU、guest memory、虛擬裝置、block device、networking 與生命週期。在 Firecracker 架構中，KVM 提供硬體虛擬化能力，而 Firecracker 是控制 microVM 的 VMM。
QEMU
QEMU 是功能很完整的通用 emulator 與 VMM。它的優勢是相容性很廣：支援多種架構、多種裝置與多種使用情境。但這樣的彈性也代表更大的 codebase 與攻擊面，對範圍明確的 serverless worker 來說不一定划算。
crosvm
Firecracker 最早是從 Google 的 crosvm 衍生而來。crosvm 和 Firecracker 類似，重點放在 KVM 與 paravirtualized devices，而不是模擬大量實體硬體。
cgroups 與 seccomp
Firecracker 也依賴 Linux 本身的隔離機制：
- cgroups：限制與統計 CPU、memory、I/O 使用量。
- seccomp-bpf：限制 process 可以執行哪些 system calls。
- namespaces：隔離 process、mount、network 等視角。
- chroot：限制 jailed process 看到的 filesystem 範圍。
這一點很重要，因為 Firecracker 沒有試圖重做一整套作業系統控制平面。Linux 已經有合適 primitive 的地方，它就直接重用。
為什麼不能只用 Container
早期 AWS Lambda 使用 Linux containers 隔離 functions，並在 customer accounts 之間加上額外的 virtualization。Container 讓 Lambda 有很好的啟動速度，但也代表多個 workload 依賴共享 kernel 這條邊界。
對 multi-tenant cloud service 來說，理想模型更強：讓每個客戶 workload 接近一般 Linux 環境，但用 VM 邊界隔離。Firecracker 會被打造出來，就是因為 AWS 不想在 container density 與 VM isolation 之間二選一。
Firecracker 架構
Firecracker 是一個主要以 Rust 撰寫的小型 VMM。它使用 KVM 做 CPU 與 memory virtualization，提供精簡的 device model，並移除 serverless workload 不需要的大量硬體 emulation。
它支援的 virtual devices 刻意維持很小。Firecracker 重點放在 virtio-based block 與 network devices，以及少量輔助裝置，例如 serial console。它不包含 QEMU 那種廣泛的 USB、音訊、圖形或 legacy devices emulation。
結果是更小的 codebase、更小的 attack surface，以及可以透過 Unix socket 上的 HTTP API 控制的 VMM。
資源控制
Firecracker 針對 virtual devices 提供 rate limiter。平台可以限制每個 microVM 的 disk I/O、network bandwidth 與 operation rate。例如 network interface 可以設定 receive bandwidth 與 packet-rate limit：
PATCH /network-interfaces/iface_1 HTTP/1.1
Host: localhost
Content-Type: application/json
Accept: application/json
{
"iface_id": "iface_1",
"rx_rate_limiter": {
"bandwidth": {
"size": 1048576,
"refill_time": 1000
},
"ops": {
"size": 2000,
"refill_time": 1000
}
}
}
這對 serverless 平台很關鍵，因為 guest operating system 是客戶可控制的。host 必須能從 guest 外部強制套用限制。
安全模型
Firecracker 結合了多層防禦：
- 透過 KVM-backed VM isolation 隔離 guest 與 host。
- 使用最小化 device model，減少暴露的 emulation code。
- VMM 使用 Rust，降低 memory-safety 類型風險。
- 使用 cgroups 做 host-side resource control。
- 使用 seccomp-bpf 限制 VMM process 的 syscall surface。
- 使用 jailer process 把 Firecracker 放進受限 Linux sandbox。
jailer 會設定受限的 filesystem view、namespaces、dropped capabilities、cgroups 與 seccomp filters。論文也提到 host-level hardening，例如在敏感部署中關閉 SMT，以及啟用 CPU vulnerability mitigations。
重點是 Firecracker 的安全設計是分層的。VM 邊界是核心，但 VMM process 本身仍然被當成需要 sandbox 的元件。
這裡有一個閱讀論文時需要注意的細節：論文提到的 seccomp syscall 數量反映的是當時版本的狀態。後續 Firecracker 版本的 default seccomp filters 已經有更多 syscall 與 ioctl 規則，因此更適合把論文中的數字當成設計方向，而不是今天部署時一定相同的固定值。真正重要的是 Firecracker 透過 allowlist 思維限制 VMM process 能做的事。
Firecracker 與 AWS Lambda 的關係
從高層來看，Lambda 透過 frontend service 接收 invocation，把 function 放置到 worker，然後把 request 路由到被選到的執行環境。
placement system 會盡量重用 warm execution environments，因為即使 microVM 啟動已經很快，遇到突發擴展時仍可能被使用者感受到。
在 Lambda worker 上，Firecracker 會管理多個 microVM。每個 slot 包含客戶 runtime、function code，以及支援控制流程的 process。
這個模型讓 AWS 可以在同一台實體 worker 上執行大量隔離的客戶環境，同時把維運控制保留在 guest 外部。
論文裡另一段我覺得很有意思的是遷移經驗。AWS 從 2018 年開始把 Lambda 從第一代隔離模型，亦即每個 function 使用 container、每個客戶使用 EC2 instance 的設計，逐步遷移到 EC2 bare metal instances 上的 Firecracker，過程中沒有造成可用性、延遲或其他主要指標上的明顯問題。但這種底層變更仍然會暴露一些平常不容易遇到的行為差異，例如安全考量下關閉 SMT 後改變了部分程式的 timing behavior，進而暴露 AWS 自家 SDK 與 Apache Commons HttpClient 的小 bug，最後需要透過修補依賴函式庫解決。
這個案例對我來說比單純的 benchmark 更有啟發：大規模平台遷移不只是在新架構上跑得動，還要能處理那些只在真實客戶 workload、真實依賴版本與真實硬體設定下才會浮現的邊界情境。
I/O Path
當 microVM 裡的程式要寫入 block device 或送出 network traffic，guest 會使用 virtio driver。request 會被放進 shared memory queue，Firecracker 收到通知後，由 VMM 執行 host-side operation。
這種設計避免完整 device emulation，但它也不是 direct device access。這個取捨可以從 performance 結果中看出來。
Performance Evaluation
論文使用 EC2 m5d.metal host 進行評估，硬體包含 Intel Xeon Platinum 8175M CPU、384 GiB RAM、本機 NVMe storage，作業系統為 Ubuntu 18.04，Linux kernel 版本為 4.15.0-1044-aws。比較對象包含 QEMU、Intel Cloud Hypervisor 等 VMM。
在測試設定下，Firecracker 與 Cloud Hypervisor 的啟動速度明顯優於 QEMU。加入 networking 會增加啟動時間，但 Firecracker 的設計目標仍然是快速建立 microVM。
Memory overhead 是最明顯的優勢之一：論文中的 Firecracker 每個 microVM VMM process 只需要幾 MiB memory，遠低於同組測試裡的 QEMU。
Block I/O 與 network throughput 則呈現另一個取捨。Firecracker 不是為了暴露接近 bare-metal PCI device 的效能；它選擇了足以支撐 Lambda 類型 serverless isolation，以及類似 managed runtime 目標的最小 virtio device model，並優先保留密度與隔離性。
對 serverless 平台來說，這個取捨是合理的。大多數 Lambda functions 不需要 host-level 的 raw network 或 disk throughput，但它們需要強隔離、可預期的限制，以及低啟動負擔。
所以我不會把 Firecracker 的 evaluation 解讀成「全面比 QEMU 快」。更準確地說，它是在 AWS serverless compute infrastructure 需要的維度上做最佳化：啟動時間、memory overhead、隔離性、density 和可控的資源限制。至於需要極致 I/O throughput 的 workload，這套設計本來就不是為了取代所有 VM 或 bare-metal 場景。
重點整理
Firecracker 不是要取代所有 virtualization stack。它的強項來自於把問題範圍縮小：
- 使用 KVM 提供硬體虛擬化隔離邊界。
- 讓 VMM 小而專注。
- 避免不必要的 device emulation。
- 重用 Linux cgroups、namespaces、seccomp 與維運工具。
- 針對 serverless 與 container workload 最在意的密度與隔離性最佳化。
這也是 Firecracker 成為 AWS 重要基礎設施的原因。它讓 AWS 取得一個務實的 multi-tenant compute foundation：密度與啟動行為接近 container，隔離性則更接近 VM。對 Lambda 來說，Firecracker 的關係在公開架構討論中相對直接且核心；對 Fargate 來說，我會比較保守地描述為 AWS 曾公開把 Firecracker 與 Fargate task runtime layer 連在一起，但使用者不應該把 Firecracker 當成 Fargate 的產品介面，也不應把它視為所有 Fargate 實作細節都固定不變的假設。
延伸閱讀
