AWS 推出 Nitro Sandboxes：每个 EKS Pod、ECS 任务都能跑在独立的硬件隔离 VM 里，AI Agent 执行生成代码一会话一沙箱，支持加密证明，不额外收费

核心背景与行业痛点

容器之所以流行，是因为一台主机上的多个容器共用一个 Linux 内核，部署轻、资源利用率高。但这也意味着共享内核里的一个漏洞可能波及同机所有容器，集群运维也能看到所有任务。AI Agent 让这个问题更尖锐：Agent 会自己写代码、自己执行，一旦被提示注入，跑的可能就是攻击者的代码。过去要硬隔离，只能给每个工作负载单独一台实例，或者自己搭 Firecracker、gVisor 等方案。这两天 Google 的 Gemini 自托管环境、NVIDIA OpenShell 也都在解决“Agent 代码在哪执行、怎么隔离”的问题。

架构亮点与底层机制

Nitro Sandbox 是从你的 EC2 实例启动和控制的轻量 VM：对实例来说像一台子 VM，实际上它和实例并列运行在 Nitro Hypervisor 上，由硬件强制隔离父实例、沙箱之间以及 AWS 运维人员。它沿用 Nitro Enclaves 的隔离技术，但做了三点调整：vCPU 可以和父实例分时共享核心；可以挂标准 virtio 网卡和块设备，不再只有 vsock；可以用 Firecracker 等标准 VMM 运行。安全组和网络策略在沙箱外的父实例上执行，被攻破的工作负载无法关掉它们。Confidential 模式还会通过 Nitro Secure Module 生成证明文档，配合 KMS 策略实现“证明代码身份后才发密钥”。

权威 Benchmark 与实测跑分对比

AWS 未公布具体的启动时延或性能跑分，只说明计算和内存接近原生 EC2 性能，并指出 Isolated 模式比 Confidential 模式启动更快。成本上的卖点是不额外收费，多个隔离工作负载可以合并到同一台实例上，提高利用率。

开发者实战落地与开箱指南

EKS：推荐用 EKS Auto Mode，在 Pod spec 里加 runtimeClassName: isolated-sandbox 或 confidential-sandbox，实例选择和调度由 EKS 处理；自管 EKS 需要兼容的 AMI。ECS：在 ECS Managed Instances 的容量提供方开启 nitroEnclavesEnabled，在任务定义里加 trustedExecutionConfiguration，把 isolationMode 设为 ISOLATED_SANDBOX 或 CONFIDENTIAL_SANDBOX，网络模式用 awsvpc。自建平台可以在 EC2 上直接用 Firecracker 启动 Nitro Sandbox，前提是启动父实例时开启 Nitro Enclaves。