AWS 于 2026 年 11 月 9 日在 What’s New 发布公告，宣布 Nitro Sandboxes 在 Amazon EKS、Amazon ECS 和 Amazon EC2 上可用。它把每个工作负载放进由 Nitro Hypervisor 管理的轻量虚拟机，获得独立的硬件隔离边界，用于运行不可信代码、多租户负载或 AI 代理。本文面向在 AWS 上部署代理类应用、插件沙箱或多租户服务的技术团队，讲清它解决什么问题、三种接入方式怎么选、上线前要核对哪些条件。个人站长若没有不可信代码执行需求，短期不必为此调整架构。

Nitro Sandboxes 到底隔离了什么

理解这项能力，先要区分两层隔离。普通容器共享宿主机内核，隔离依赖命名空间、cgroups 和安全策略；一旦内核或运行时出现漏洞，边界就可能被穿透。Nitro Sandboxes 换了一个层级：每个 Pod、Task 或轻量 VM 运行在自己的 Nitro 隔离虚拟机里，隔离边界由虚拟化层提供。

公告中的几个关键表述值得逐条看：

• 由 Nitro Hypervisor 管理，属于轻量虚拟机形态，不是传统重型虚拟机；
• 每个工作负载获得一个 Nitro 隔离虚拟机的隔离边界；
• AWS 称其具备接近原生 EC2 的性能，并继承 Nitro Hypervisor 的隔离能力；
• 支持通过加密证明校验工作负载完整性，密钥只释放给通过校验的 Sandbox。

“接近原生性能”是 AWS 的官方表述，公告未给出延迟、吞吐或启动时间的量化基准，本文也不替它补数字。实际开销需要按自己的负载类型做验证。

三种接入方式：EKS Pod、ECS Task、EC2 自管 VM

同一套隔离能力有三种用法，选择取决于你现有的编排方式和控制需求。

EKS Pod：已有集群的团队优先评估

公告称在 EKS 中启用后，每个 Pod 获得自己的隔离环境，且被描述为一行改动。Pod Identity、VPC CNI、EBS/EFS/S3 存储和 CloudWatch 可开箱使用，工作负载保持原生形态。对已经在用 EKS 的团队，这意味着不必重写应用，评估成本主要在配置核对和试点验证。

需要留意的是，公告摘要没有列出具体配置项、Kubernetes 版本要求和节点实例族限制。托管节点组与自管节点在启用方式上是否完全一致，也要按 EKS 用户指南确认后再动手，不要仅凭“一行改动”直接改生产集群。

ECS Task：任务型负载的同类路径

ECS 的接入逻辑与 EKS 平行：每个 Task 运行在自己的隔离环境中，同样被描述为一行改动。适合以任务为单位调度、已经使用 ECS 管理容器的工作负载。具体参数与版本条件同样以 ECS 用户指南为准。

EC2 自管 VM：需要完全控制时使用

如果不走托管编排，可以直接在 EC2 上运行 Nitro Sandboxes，自带 AMI、自有编排和虚拟机监视器（VMM）。公告称原生支持 Amazon Linux 与 Firecracker，其他 VMM 选项已有补丁可用。这条路径灵活度最高，也意味着隔离策略、生命周期和密钥管理要自己设计，运维负担相应上升。

对实际部署意味着什么

AI 代理与 LLM 生成代码

让大模型生成的代码在受控环境里执行，是这类隔离最直接的场景。过去常见做法是为不可信执行单独开实例或单独建集群，资源利用率偏低。Nitro Sandboxes 允许在单台 EC2 实例的资源内，把多个代理类工作负载分到各自的隔离虚拟机中，公告将其描述为提升利用率、降低计算成本的方式。注意这是架构层面的成本影响，不等于账单一定下降，最终取决于实例选型、内存开销和实际密度。

多租户与受监管负载

多租户 SaaS 或受监管行业团队，可以把隔离粒度从容器级提升到微 VM 级，作为安全设计的一部分。但监管是否认可某种隔离形态，取决于具体合规框架和审计要求，需要团队自行对照，不能仅凭产品公告下结论。

加密证明与密钥释放

公告提到可通过加密证明验证工作负载完整性，密钥仅释放给通过校验的 Sandbox。这对“代码不可信但需要访问敏感凭据”的场景有价值：凭据发放前先确认运行环境未被篡改，而不是只靠网络策略限制。不过公告未展开证明流程和与密钥管理服务的具体集成方式，落地前需要查阅 EC2 用户指南中的 Nitro Sandboxes 文档，确认自己的密钥管理方案能否接入。

可用范围与费用口径

按公告，Nitro Sandboxes 在大多数基于 Nitro 的 EC2 实例上提供，覆盖全球所有商业区域，且不额外收费。这里有三个边界要说清：

• “大多数”不等于全部，具体实例族清单需在官方文档核对；
• 不额外收费指该功能本身，底层 EC2 实例、存储和网络仍按原有计费方式产生费用；
• 隔离带来的资源开销可能改变实例规格选择，实际支出要按负载测算。

本文引用的信息来自 2026 年 11 月 9 日的 AWS What’s New 公告，核验日期为 2026 年 11 月 10 日，发布仅一天，尚无独立第三方评测可供交叉验证。

哪些团队值得现在评估

可以按现有痛点判断，而不是按产品热度：

• 值得评估：在 EC2 或 EKS 上运行 LLM 生成代码、第三方插件、用户上传脚本的团队；为隔离而维护多套实例、利用率偏低的团队；需要向客户或审计方说明租户隔离机制的多租户服务商。
• 可以观望：容器隔离已满足需求、没有不可信代码执行场景的业务；对启动延迟和密度有严格要求但尚未做验证的团队。
• 短期不必迁移：个人站长、小型展示站和常规 Web 应用，现有隔离模型通常够用，迁移收益有限。

上线前的核对清单

1. 在 AWS What’s New 公告页确认功能范围，再到 EC2 用户指南确认目标实例族是否在支持范围内，以及所在区域是否覆盖。
2. 在 EKS 或 ECS 用户指南核对启用方式的具体配置项、集群版本和节点条件，不要仅凭“一行改动”的描述直接改生产环境。
3. 选一个非核心场景做小规模试点，例如单个 AI 代理或插件沙箱，记录资源占用与调度表现。
4. 若使用加密证明，先梳理密钥管理流程，确认证明校验与凭据释放的集成路径。
5. 自管 EC2 路径需额外评估 AMI 兼容性、VMM 选择和补丁维护责任。
6. 对比试点前后的实例数量与规格，再判断成本结构是否真的改善。

常见问题

Nitro Sandboxes 和普通容器隔离有什么区别？

普通容器共享宿主机内核，隔离依赖内核提供的机制；Nitro Sandboxes 为每个工作负载提供 Nitro 隔离虚拟机的边界，隔离发生在虚拟化层。两者粒度不同，适用场景也不同。

需要额外付费吗？

AWS 公告称在支持的 Nitro 实例上不额外收费。底层 EC2 实例、存储和网络仍按原有方式计费，实际支出变化取决于实例选型和资源开销。

现有 EKS 集群要改多少？

公告描述为一行改动，但具体配置项、版本要求和节点实例族限制未在公告中列出，需查 EKS 用户指南后再操作。

能跑 Amazon Linux 以外的系统吗？

公告称原生支持 Amazon Linux 与 Firecracker，其他 VMM 选项已有补丁可用。补丁的成熟度和维护责任需要自行验证。

个人站长需要关注吗？

如果没有不可信代码执行或多租户隔离需求，短期没有迁移必要。这项能力主要解决隔离粒度问题，不改变常规建站的成本结构。

对技术团队来说，更稳妥的路径是先确认实例与区域支持情况，再挑一个不可信执行场景做试点，用资源占用和运维复杂度说话，而不是一次性把生产负载整体切换。