微软正式发布 Azure Container Apps Express 与沙箱层，实现亚秒级启动与按秒计费

一句话结论

微软发布 Azure Container Apps Express 与沙箱层，提供亚秒级启动、按秒计费且空闲缩零的隔离计算环境。

关键要点

• Azure Container Apps Express 正式发布，它省去环境预置步骤，使用带有偏好性的默认配置取代大部分配置项。
• Express 运行在 Azure Container Apps Sandboxes 之上，后者是硬件隔离的 microVM 边界，支持从预热资源池实现亚秒级启动。
• Sandboxes 支持挂起与恢复，能对包括内存和磁盘在内的完整状态进行快照，并能在亚秒内完成恢复。
• Express 应用运行在按秒计费的 CPU 上，空闲时缩容至零，且不收取环境预置费用。
• Express 不支持自定义域名、可用区冗余、Key Vault 密钥引用、GPU 工作负载以及系统分配的管理身份。

背景与事实

微软近期宣布 Azure Container Apps Express 正式发布。这是一种部署模型，省去了环境预置这一步骤，并用带有偏好性的默认配置取代了大部分配置项。它与 Azure Container Apps Sandboxes 同步正式发布，后者正是 Express 所运行的隔离计算层。这一组合与谷歌今年在 Kubernetes Engine 上推出的方案在形态上一致。Express 接收一个容器镜像、一个区域以及应用所需的任意配置，随后自行完成计算、入口和扩缩容的预置。应用运行在按秒计费的 CPU 之上，空闲时缩容至零，且不收取环境预置费用。微软将 Express 定位为“开发者优先”与“智能体优先”，并明确强调了后者，指出 AI 辅助的工作流创建和更新应用的速度，远比任何人手工配置基础设施要快。

这种速度源自底层。微软的文档指出，Express 完全构建于 Container Apps Sandboxes 之上，这是一种平台原语，它能从预热的资源池中预置以实现亚秒级启动，将每个工作负载分隔在各自硬件隔离的 microVM 边界内，并能突发扩展至数千个并发沙箱。Sandboxes 还支持挂起与恢复，对包括内存和磁盘在内的完整状态进行快照，并能在亚秒内完成恢复。开发者可以直接使用 Sandboxes，而不必通过 Express。微软将 Sandboxes 定位于智能体平台与安全代码执行服务。其顶层 ARM 资源为 Microsoft.App/SandboxGroups，被描述为共享配置的沙箱之间的管理边界，可类比为 Container Apps 环境。Reddit 上的反应表明，这一原语在正式发布之前便早已被使用。评论者 MuhBlockchain 提供了一个细节：ACA Sandboxes 实际上是众多核心 Azure 服务（包括 Foundry Hosted Agents）的底层支撑。评论者 Minute_Passion_8077 描述了通过 Bicep 为客户部署它们的方式：只要把它指向一个镜像就可以开始运行了。如果不需要了怎么办？直接缩容到 0。

Express 本身则是位于其上的、带有偏向性的应用层，提供了 Container Apps 能力的一个精简子集：缩容至零、多副本、运行在微软托管域名上的 HTTP 入口、环境变量、手动密钥、IP 限制、日志流式传输，以及基于 HTTP、CPU 或内存规则的自动扩缩容。被排除在外的能力确定了它的边界。Express 不支持自定义域名、可用区冗余、Key Vault 密钥引用、Easy Auth、OpenTelemetry、Dapr、jobs、工作负载配置文件、GPU 工作负载、多修订版本与流量切分，也不支持系统分配的管理身份。它缺少服务发现，因此应用之间通过各自的公网 URL 通信，且入口仅支持 HTTP。访问权限同样比标准 Container Apps 更窄。Express 要求使用受 Microsoft Entra ID 支持的账户，不支持个人 Microsoft 账户。管理是通过专用界面而非 Azure 门户进行的：Container Apps 使用 containerapps.azure.com，Sandboxes 使用 sandboxes.azure.com。

在正式发布时，Express 已经覆盖超过 40 个 Azure 区域，几乎涵盖了提供 Container Apps 的所有公有区域。微软表示，在公测期间已创建了数千个 Express 应用，并且客户反馈确立了本次发布的优先级。自助迁移通过“归档与恢复”来实现：先归档现有环境，再将其恢复为 Express 环境。微软表示，该过程会保留应用与环境配置，耗时约 15 分钟，且不改变免费用量额度。FAQ 还提到，迁移通知中包含一份退出表单，供需要额外审批或协调的组织使用，并指出处于非活动状态的环境可能会被归档并转入休眠。

影响分析

对于中文开发者与从业者而言，这一发布显著降低了智能体应用原型验证的门槛。由于免除了环境预置费用且空闲时缩容至零，团队在开发测试阶段可以更低成本地创建和销毁大量隔离环境。这对于需要频繁迭代智能体工作流、执行不受信任代码或进行安全沙箱测试的团队具有直接吸引力。分析判断认为，Express 的“开发者优先”定位意味着它更适合快速原型开发和非生产环境。然而，对于生产环境，开发者需要仔细权衡 Express 缺失的功能。例如，不支持 Key Vault 密钥引用和自定义域名可能迫使团队在从开发迁移到生产时重新设计安全架构和网络策略。若团队依赖 GPU 进行模型推理或需要复杂的微服务通信（如 Dapr），则必须选择标准 Container Apps 环境。因此，决策者需明确负载是否涉及高级网络控制、GPU 计算或环境级能力，以避免因功能缺失而导致后期重构成本。

适用边界

该结论主要适用于以 CPU 为核心、需要快速启动与隔离执行、且对网络策略和高级身份管理要求较低的场景。它不适用于需要自定义域名、可用区冗余、Key Vault 密钥引用、GPU 工作负载、Dapr 集成或多修订版本流量切分的生产级高可靠负载。若团队运行 Azure Kubernetes Service 以满足 Container Apps 无法满足的需求，则 Sandboxes 并非直接替代品。

孤本观察

微软将 microVM 隔离与基于快照的挂起/恢复搭配，旨在解决智能体零成本空闲与快速恢复的矛盾。编辑判断认为，这一原语正在成为底层核心服务支撑，而非独立产品。

来源：InfoQ 中文 AI