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 和内存，这意味着失控脚本会与生成它的服务争抢资源。如果这些厂商特定的限制保持如此鲜明，那么中立的混合云沙箱仍有其价值，这看起来是一种尚未完成的商品化。

每朵云现在都同意，代理不应在宿主机上运行代码，这使争论转向了代码一旦被安全包含后，谁来决定其行为。