摘要

  • 第一个 AWS 欧洲主权云区域落在德国勃兰登堡州，AWS 说它的基础设施整体位于欧盟境内，与其他 AWS 区域在物理和逻辑上都隔开。
  • 隔离是有代价的：现有 AWS 账户不能用，主权云账户自成一套，不与其它区域互通。想搬进去的团队要先把自己的身份体系拆开。
  • 真正硬的部分不在市场页面，而在 2026 年 5 月 14 日更新的《欧洲主权云附录》里：它把“只有符合条件的欧盟人员才能操作系统”写成了可以引用的合同条款，并声明非欧盟人员无从访问，AWS 在欧盟之外没有可用的技术手段。
  • 同一批文件也把剩下的缝列了出来：内部系统指标可以出境、全球技术专家可经“受控机制”被咨询、支持实体注册在爱尔兰和卢森堡、某些消息服务的下游路由是全球的。
  • 地址这一层没有文件：本文不陈述该公司的 RIPE NCC 会员状态、自治系统号、公告前缀，也不说服务地址由哪一个实体持有。

先说结论：墙的语言，清单的内容

AWS 的措辞读起来像在砌墙。“完全位于欧盟境内”“与其他 AWS 区域在物理和逻辑上分离”“对非欧盟基础设施没有关键依赖”——这几句话出自 AWS 自己的欧洲主权云常见问题页，aws.eu 的主权云问答 与 AWS 数字主权常见问题 用的是同一套说法。

但继续往下读，墙就变成了清单。主权不是“什么都不许过”，而是“哪些东西可以过、依据哪一条、由谁批准”。这个区别看起来很学术，直到你需要在事故之后向监管者解释，你的客户数据在半夜由哪个法域的哪个人看过。前者给不了答案，后者可以。

四家德国法人，四种职能

AWS 说它为欧洲主权云设了一个新的欧洲组织：一家新母公司，加三家在德国注册的子公司（AWS 治理页面）。分工是明确写出来的：

  • AWS European Sovereign Cloud GmbH 是母公司，也是合同附录里指定的“主权云实体”；
  • Amazon Data Services European Sovereign Cloud GmbH 拥有并运营底层基础设施——这正是名录里这一条所指的对象；
  • AWS European Sovereign Cloud Development Centre GmbH 雇佣运营人员；
  • Amazon European Sovereign Cloud Trust Services GmbH 持有信任证书。

这段的意义不在于“它们都是德国公司”，而在于责任的落点。当你要问“谁碰过我的机器”，答案不是“亚马逊”这个抽象品牌，而是一个在德国商业登记里有名字、有住所、可以被传唤的法人。品牌不会出庭，法人会。

账户与身份：切得最干净的一刀

AWS 说得很直白：现有 AWS 账户不能用于主权云；主权云账户独立，且不与其他 AWS 区域互通。设计说明里补上了机制——独立的计费、账户和身份系统构建在一套专门的主权云栈上，全球 AWS 账户既不能配置也不能访问主权云服务（设计说明）。

这是整套方案里最容易被低估的一条，因为它表面上只是“要重新注册”。实际上它是组织性的断点：跨国团队不能“顺手”把工作负载挪进去，也不能靠既有的身份关系把权限桥接过去。要进去，得重新建一套人、角色和审批。

网络：专用，但不等于脱离公共互联网

文件在这里用的词是“专用”（dedicated），不是“独立”。来自欧洲供应商的专用网络、通过 AWS Direct Connect 提供的主权接入点、专用的 Amazon Route 53、以及一套欧洲根证书颁发机构（设计说明）。专用意味着这些路径不为其他区域服务，不意味着它们飘在互联网之外。

一个主权云区域仍然要被路由到，仍然要有地址。而恰恰在地址这一层，这批文件什么都没说。

合同层：把运营承诺变成可引用的条款

市场页面可以说得很好听，合同附录不能。《AWS 欧洲主权云附录》最后更新于 2026 年 5 月 14 日，只适用于欧洲主权云账户，并明确排除 AWS Training & Certification 与 AWS Professional Services（附录原文）。它写下的东西比问答页硬得多：

只有符合条件的主权云人员才操作服务、提供 AWS Support、运营计算基础设施、控制那些承载客户内容与客户创建元数据的系统。所谓“符合条件”，定义同时要求三件事：受雇于一家在欧盟注册的 AWS 实体、是欧盟居民或欧盟公民、履职时人在欧盟。国籍、居留、位置三者缺一不可。

同一份附录还声明：欧盟之外的 AWS 人员无法访问客户内容与客户创建元数据，AWS 在欧盟之外没有可用的技术手段访问它们（受附录所列例外约束）；主权云被设计为可以独立且无限期运行，包括不依赖任何通往非欧盟基础设施的连接。

这段话的分量在于它是承诺，而不是描述。“我们的人都在欧盟”是描述，“只有这些人，而且我们没给他们留远程通道”是承诺。承诺可以被引用，也可以在出事之后被追究。

缝的清单

同一批文件自己把剩余的口子逐条列了出来。这才是这篇文章真正想让你看的段落。

一、内部系统指标可以出境。 AWS 明确写到，有些数据既不是客户内容，也不是客户创建元数据——例如内部系统指标——可能会离开欧盟，用于容量管理、性能监控、安全功能，以及协助主权云人员（设计说明）。这在工程上说得通：容量规划要全局视野。但请注意它的分类逻辑——判断标准是“是不是客户内容”，不是“是不是数据”。

二、全球技术专家仍可被咨询。 文件说，主权云的所有人员——包括支持和数据中心操作员——限于符合条件的主权云人员，而全球 AWS 技术团队可以通过受控机制被咨询（同上）。这是唯一一处文件没有把机制细节写死的地方，也是采购谈判里最值得追问的地方：受控机制到底怎么控，控不到谁会签字。

三、支持实体在爱尔兰和卢森堡。 子处理者页面把 Amazon Development Centre Ireland Limited 与 Amazon Web Services EMEA SARL 列为提供客户发起支持的两个 AWS 实体，并说明除非客户在支持过程中同意共享，否则它们不处理客户数据；同一页面列出的状态最后更新于 2026 年 7 月 28 日（子处理者页面）。逻辑上是干净的：你不找它们，它们碰不到你。反过来也成立——你在工单里贴的那段日志，就是你自己把数据递了出去。

四、域名注册在 Key-Systems GmbH。 同一页面把德国的 Key-Systems GmbH 列为 Amazon Route 53 域名注册的实体。域名是主权叙事里最容易被忘掉的一层：云在勃兰登堡，DNS 记录却在另一个法人的系统里。

五、部分消息服务的下游是全球的。 页面对某些消息服务写明，下游提供商可能按需在全球范围内路由和处理数据。这是一条例外的例外：服务级的，不是区域级的。

六、合同方在卢森堡。 对客户位置在欧盟的账户，签约方是主要营业地在卢森堡的 Amazon Web Services EMEA SARL（aws.eu 问答）。也就是说，机房在德国、法人在德国，而你在纸面上打交道的对手方在卢森堡。这不影响数据在哪，但影响争议在哪打。

这张清单不是丑闻。它比多数云厂商公开得细。它的价值在于把“主权”从形容词变成了条款编号：每一个“会”都写着条件，每一个“不会”都写着例外。

证据边界：地址这一层没有文件

有一层本文没有拿到可读文件：网络号。对 Amazon 公布的 IP 段数据、以及 RIPE NCC 数据库里这家德国实体的记录，检索都没有返回可读内容。因此本文不陈述这家公司的 RIPE NCC 会员或组织状态，不陈述自治系统号，不陈述公告前缀，也不陈述服务地址由哪个实体持有。

这个缺口对主权论证不是小事。合同能保证谁在机房里，注册记录才能说明谁在路由表里。前者是私法文书，只对签约双方有效；后者是公共账本，任何人可以查。一个客户如果只核对前者，他核对的是承诺；如果他能核对后者，他核对的是事实。

文档版本也在漂移

一个细节值得记下来：设计说明描述的是一个四名成员的咨询委员会，而现行的治理页面写的是五名（设计说明；治理页面）。另外，问答页与设计说明描述的是“逐步过渡到完全由欧盟公民运营”，而附录接受欧盟居民或欧盟公民。

这些不是矛盾的证据，而是同一份文件在被继续编辑的证据。主权云不是一个铸好的碑，是一份还在改的章程。对买方来说，这意味着你签的那一版和你三年后引用的一版可能不是同一版——把版本号和日期写进采购文件，比写一句“要求主权”有用。

所以该核对什么

五个问题，按顺序问：

一、签约主体是谁？机房在德国不等于合同方在德国。

二、“受控机制”的具体形态写在哪个附件里，谁能改，改了通知谁？

三、内部系统指标里到底有什么？如果你的合规结论依赖“欧盟境内无出境”，这一条是否已经被你在架构里排除？

四、哪些服务属于“某些消息服务”这类全球路由的例外？名单在哪里，会变吗？

五、地址与路由层，你打算用哪一份公共记录来核？

前四个问题这批文件都能回答，第五个不能。这就是这张清单的尽头，也是采购真正开始的地方。