AWS、Google Cloud、Microsoft Azure 和 Cloudflare 均提供代理沙箱，但構建方式各不相同

在本月初於柏林舉行的 WeAreDevelopers 世界大會上，Google Cloud 宣佈 Cloud Run 沙箱進入公開預覽階段，這距離 AWS 推出其版本僅數週。兩款沙箱都試圖回答同一個問題：代理程序剛剛編寫的代碼究竟應該在哪裏運行？

兩個超大規模雲服務商在同一季度推出沙箱，標誌着這一領域格局的完整。如今，四大主流雲平台（AWS、Google Cloud、Microsoft Azure 和 Cloudflare）都已將隔離代碼執行作為原生基礎能力提供，但它們在隔離棧和生命週期模型上存在實質性分歧。

AWS 在 Firecracker 之上構建了 Lambda 微虛擬機，為每個會話提供專用虛擬機，運行時最長可達八小時，並具備掛起-恢復週期以保留內存、磁盤和正在運行的進程。Google 則採用雙軌路徑：GKE 代理沙箱使用 gVisor 內核攔截，而 Cloud Run 則在現有實例內增加輕量隔離執行邊界。

Microsoft 是這一模式的先行者。自 2024 年起，Azure 容器應用的動態會話便運行在 Hyper-V 邊界上，據微軟報告，僅 Copilot 每天就消耗超過 40 萬個這樣的會話。Cloudflare 在容器之上構建沙箱，每個沙箱在其專用虛擬機中隔離，並通過 Workers 和 Durable Objects 進行控制。

四家廠商在安全邊界應置於何處這一問題上存在真實的分歧。但它們出售的產品本質相同：發送不可信代碼，平台將其在調用應用程序隔離的環境中運行，憑據暴露則另行治理。

在 Cloud Run 的實現中，沙箱成為一個標誌。在部署命令中添加 --sandbox-launcher 標誌，即可在容器內掛載一個沙箱二進制文件，應用程序通過普通子進程調用來調用它。Google 對該功能不收取額外費用，因為沙箱借用已分配給運行實例的 CPU 和內存。Google 的演示顯示，一個 Cloud Run 服務在 500 毫秒內平均啓動、執行並停止了 1000 個沙箱。

Google 在公告中將替代方案描述為：在容器集羣上構建複雜的沙箱基礎設施，或付費使用專業的第三方微虛擬機運行時。這句話直指一類廠商——它們在共享內核的容器與啓動需數分鐘的虛擬機之間的空白地帶建立了真實的業務。如今，這四家廠商均提供託管沙箱執行，但各有不同的打包和定價方式。

隔離是一個包含邊界，而非治理層。Firecracker 虛擬機將生成的代碼與宿主機及其他會話隔離，但憑據和網絡可達性仍是配置決策。它無法控制代碼如何利用開發人員有意授予的憑據，治理則完全處在另一層。包含邊界設定了安全授權的上限，而這只是問題中較便宜的部分。

廠商的限制在商品化趨勢中依然存在，且具體而微。Lambda 微虛擬機在五個區域運行於 Graviton 上，上限為八小時，因此需要 x86 或更長時限的團隊仍需自行承擔編排工作。Cloud Run 沙箱共享父實例的 CPU 和內存，這意味着失控腳本會與生成它的服務爭搶資源。如果這些廠商特定的限制保持如此鮮明，那麼中立的混合雲沙箱仍有其價值，這看起來是一種尚未完成的商品化。

每朵雲現在都同意，代理不應在宿主機上運行代碼，這使爭論轉向了代碼一旦被安全包含後，誰來決定其行為。