摘要

  • AWS 为 European Sovereign Cloud 提出了少见的具体运营、法律和架构承诺；采购方应把这些承诺转化为可验证的控制图，而不是直接接受一个地域标签。
  • 一项站得住脚的主权判断至少要检查六条路径：特权运维、身份与密钥、技术支持、软件供应、治理以及紧急变更权限。

一套受监管的业务可以把全部客户数据留在德国勃兰登堡，却仍然没有回答最关键的非常规问题：正常指挥链不可用时，谁有权批准紧急变更？提出这个问题并不是指控供应商失职。它揭示了数据驻留与运营主权的区别。前者说明信息存放在哪里；后者说明哪些人员、凭据、法律实体和供应商能够改变系统接下来发生的事情。

AWS 的新方案并非简单的区域营销标签。AWS European Sovereign Cloud 于 2026 年 1 月 14 日正式可用，首个区域位于勃兰登堡，设有三个可用区。AWS 表示，该环境与其他 AWS 区域在物理和逻辑上分离，拥有独立的身份、计费和 DNS 系统；客户内容以及客户创建的元数据留在欧盟；即使与世界其他地区的连接中断，也可继续运行。日常运营由居住在欧盟的人员控制，相关岗位将逐步过渡到欧盟公民。专门设立的德国法律实体和由欧盟公民组成的顾问委员会，又增加了一层治理边界。

这些控制具有实质意义，但它们仍是供应商陈述和合同承诺，并不能自动证明每个客户架构都会得到同样结果。身份联合、支持升级、可观测性、密钥管理、部署工具或第三方软件，都可能重新引入跨界依赖。因此，主权评估必须从依赖清单开始。

第一条路径是特权运维。采购方应列出所有能够改变生产状态的角色、其所在司法辖区和雇佣实体、审批顺序，以及紧急访问的触发方式。第二条是身份和密码学权限：根凭据、签名系统和密钥材料由谁控制，外部身份服务是否仍在关键路径上。第三条是支持。一道本地服务入口并不充分；复杂事故如果必须交由边界外的团队或诊断系统处理，控制面就仍有外部依赖。

第四条是软件供应。云区域可以位于欧洲，却依赖其他地区的源代码管理、构建系统、签名密钥、漏洞情报或发布权限。AWS 表示该服务不存在对非欧盟基础设施的关键依赖；采购方需要把这句话展开为组件清单、失效测试和证据。第五条是治理：由哪个实体签约、雇佣、分包，又有哪些实体可能被依法要求采取行动。AWS European Sovereign Cloud Addendum 对人员、治理、分包商、连续性和通知作出承诺；在特定重大变更或计划停止服务的情形下，承诺至少提前十二个月通知，但也列明了例外。

第六条是紧急权限。隔离不只是网络中断。采购方应演练法律冲突、关键人员不可用、更新渠道受损，以及严重漏洞需要立即修补等情形。每个场景都应回答同一组问题：谁决策、谁执行、哪个系统授权、要调用什么外部依赖、事后留下什么证据？

欧盟委员会提出的 Cloud and AI Development Act 提供了一套相容的分级思路。第一级关注数据位于欧盟；更高级别增加对第三国法律的独立性、软件供应透明度、欧盟所有权与控制，最高一级则要求完整软件供应链控制并防止第三国干预。该提案仍可能在立法过程中改变，但其结构说明了一个重要事实：地域只是保证论证的起点，而不是结论。

因此，验收材料应包括控制面隔离图、特权角色与司法辖区登记、密钥保管说明、支持和分包升级路径、构建与签名来源、治理承诺，以及隔离与紧急变更演练结果。公开资料无法证明某个具体客户业务已经满足这些条件，采购方必须针对实际部署索取并检验这些证据。

AWS 已经推动市场用更具体的方式讨论主权。合理回应既不是本能接受，也不是本能怀疑。只有当日常条件失效时，某项业务的关键依赖仍然处在约定且可审计的边界内，该服务才对这项业务具有可证明的主权属性。

来源