让我们谈谈欧盟主权（2025）

背景

“欧盟主权”（EU Sovereignty）是科技行业近期频繁使用的术语，尽管作者本人对该词持保留态度，认为其带有军事化色彩、反自由流动等 problematic baggage（有问题的包袱），但鉴于行业惯例，我们暂且沿用这一说法，直到当前的推动期结束，或许未来可以像 Git 分支命名或复制术语那样，悄然替换为更准确的词汇。此外，拼写正确这个术语本身也是一件令人头疼的事。

在最高层面上，该概念的核心前提是：欧盟公民的数据必须保留在欧盟境内。但这仅仅是表象，实际情况远比“数据不出境”复杂得多。

核心内容

1. 传统云区域的局限性

许多人直觉地认为，AWS 的 eu-west-1（位于爱尔兰）区域符合“主权”要求，只需将服务部署于此即可。然而，事实并非如此。

• 全球服务的陷阱：AWS 及其他云提供商拥有区域级（Region-based）、可用区级（Zone-based）以及至关重要的全局服务（Global services）。
• 数据外泄风险：一旦使用任何全局服务，数据就会从 eu-west-1 复制到其他区域，甚至流向 us-east-1（官方名称，非 us-tirefire-1）。
• 关键基础设施依赖：
  • S3：作为全局服务，是大多数人的刚需，但这直接违背了数据本地化原则。
  • 认证与授权：AWS 的所有认证（Auth）流程均通过 us-east-1 进行，包括登录验证和服务间通信规则。
  • DNS：至少有 13 种 AWS 服务依赖 DNS 来启动，而 DNS 基础设施位于 us-east-1，而非用户所在的欧盟区域。

理论上，如果不使用全局服务似乎可行，但法律层面的问题更为棘手。

2. “欧盟主权云”区域的现状

截至 2025 年 10 月 21 日，AWS 所谓的“欧盟主权云”区域仍处于“即将推出”（Coming Soon）状态。

• 交付压力：该区域正在柏林通过高强度的人力投入推进，截止日期过于乐观。
• 服务限制：参考以往 AWS 区域上线的经验，新区域初期可能仅提供有限子集的服务。
• 法律灰色地带：正如后文所述，该模式在法律上仍存在未解决的灰色地带。

其他供应商的情况类似或更糟：

• T-Systems Google Sovereign Cloud：Google 在该区域进展稍快，但仍难以达到其 europe-west3（法兰克福，欧盟常用）或 europe-west1（比利时，较便宜）区域的完整功能对等。它同样试图规避但未能成功解决法律问题。
• Microsoft Azure：据作者了解，Azure 的进展更为滞后（作者因个人偏好避免使用 Azure，故无直接联系，但信息表明其落后）。
• 其他供应商：Oracle、DigitalOcean、Salesforce Cloud 等美国云公司，大多处于 Google 或 AWS 模式的中间地带，或者干脆未提供真正的“主权”方案。

3. 核心法律冲突：美国法 vs 欧盟法

这是问题的实质所在。美国公司必须遵守美国法律，这看似合理，但当其与欧盟法律冲突时，问题便产生了。

• 美国法律视角（Gagging Order/封口令）： 根据美国法律，如果法官下令（或在某些情况下，政府或情报机构要求），针对潜在犯罪的相关活动可以伴随“封口令”。这意味着相关人员被法律强制不得透露此事。其理论依据是防止嫌疑人得知调查后逃逸。这种活动包括扣押（复制）数据。
• 欧盟法律视角（通知义务）： 根据欧盟法律，如果第三方访问公民数据，提供商必须通知该公民。无例外。

这是导致 Safe Harbour（在 Schrems I 案中被欧盟法院认定无效）、EU-US Privacy Shield（在 Schrems II 案中被欧盟法院认定无效）失效的根本原因。目前的 Data Privacy Framework（数据隐私框架）中，作者未找到关于“封口令”的任何提及。虽然该框架声称美国公司必须遵守欧盟法律，但尚无案例在“美欧法律冲突”的情境下对此进行测试。

4. 现有“主权云”方案的法律漏洞

目前的 AWS、Google、Microsoft 主权云方案并未真正解决上述法律冲突：

• Google 方案：将云资源管理置于 T-Systems（一家德国公司，非子公司，这是好的开始）之下，但仍使用 Google 的软件栈。作为云提供商，它需要安全更新。如果某位不了解云计算概念的法官要求“在下次安全更新中植入后门”并下达封口令，谁来阻止？
• AWS 方案：声称“你支付的是 AWS Europe，这是一家独立的（子公司）公司，必须遵守欧盟法律”。作者对此表示怀疑，因为 AWS Europe 在软件、就业安全乃至生存上完全依赖 AWS 总部。
• 结论：这些结构无法提供足够的法律保障。

5. 欧盟的出路与建议

既然无法真正信任美国云提供商的“主权”方案，企业该如何使用“云”而不依赖美国公司？

• 拒绝美国云提供商：直接使用欧盟本土的云提供商。
• 本土供应商崛起：虽然欧盟“云提供商”起步较晚，但正在追赶。Scaleway、Herzner 等已具备竞争力。初创企业在欧盟开展业务时应优先考虑这些选项。
• VPS 提供商：可以查看 VPS 提供商的产品组合。
• 多云策略：在多个欧盟提供商之间运行虚拟机（VM）可能会带来挑战，取决于公司规模，但这能构建极高的韧性（bulletproof）。
• 架构重构：如果考虑迁移，必须深入审视架构，没有捷径。不要嘴上要求详细计划，最后又因成本放弃并准备支付罚款。
• Kubernetes 管理：如果认为云厂商提供的 Kubernetes 服务不佳（作者认为所有“托管” Kubernetes 充其量只是半托管），建议使用 Siderolabs’ Omni 来管理自己的 K8s 节点集群，这是一个非常优秀的选择。

关键要点

• 术语辨析：“EU Sovereignty”是行业惯用语，尽管带有负面联想，但目前仍被广泛使用。
• 数据本地化误区：仅部署在 eu-west-1 等欧盟区域并不等于数据主权，因为全局服务（如 S3、DNS、Auth）会将数据或控制流导向 us-east-1。
• 主权云现状：截至 2025 年 10 月，AWS、Google 等推出的“欧盟主权云”区域大多处于“即将推出”或功能不全状态，且面临法律灰色地带。
• 法律根本冲突：
  • 美国法：允许通过“封口令”强制保密，包括数据扣押，无需通知用户。
  • 欧盟法：强制要求提供商在第三方访问数据时必须通知用户，无例外。
  • 现有框架（如 Data Privacy Framework）未解决此冲突，且无相关判例测试。
• 子公司隔离无效：AWS Europe 等子公司在法律独立性上不足以抵御美国法律（如 FISA 702 条款隐含的执法要求）的长臂管辖，因其技术栈和生存依赖总部。
• 替代方案：
  • 转向欧盟本土云提供商（如 Scaleway, Herzner）。
  • 采用多云策略，分散风险。
  • 使用 Siderolabs’ Omni 等工具自建或半托管 Kubernetes 集群，避免依赖云厂商的托管 K8s 服务。

意义与影响

这篇文章深刻揭示了“数字主权”在技术实现与法律现实之间的巨大鸿沟。对于在欧盟运营的企业而言，简单地购买“欧盟区域”或“主权云”套餐并不能自动获得法律合规性和数据隐私保障。

1. 合规风险升级：企业若误以为部署在欧盟区域即可规避美国法律管辖，可能面临严重的合规