仅欧洲替代方案 Microsoft Azure.

Microsoft Azure是最常被以“但我们所有业务都已经在用Microsoft”为由来辩护的云平台。但这套说辞经不起Schrems II分析的考验：Microsoft Corporation是一家美国公司，每个Azure子公司均由美国实体控制，且Microsoft已在法庭上明确承认（Microsoft Ireland案，2018年）其会配合美国有效法律程序调取全球任何地方的数据，这正是后来CLOUD Act所明文规定的内容。“Microsoft Cloud for Sovereignty”以及Bleu（Microsoft×Capgemini×Orange）等计划固然有意思，但其技术仍是从美国母公司获得授权的。若要实现真正的EU主权，唯一办法是退出。下面是具体路线图。

美国仅限 EU 的替代技术栈 14 已梳理的服务

预约通话先扫描您的域

供应商: Microsoft Azure
总部: Redmond, WA
司法管辖区: 美国
法律制度: CLOUD Act, FISA 702, EO 12333

"欧盟区域"不等于主权。四个问题决定一切。

数据驻留告诉你数据存放在哪里。主权则告诉你哪个法律体系可以强制访问。这四点的答案必须都成立 - 否则该技术栈就不具备主权性。

驻留

数据物理存储在哪里?

不只是笼统的“在云端” - 而是具体在哪个数据中心、哪个国家、受哪种司法管辖。

次级处理者

您的数据路径中还有谁?

每一个接触数据的供应商:CDN、邮件中继、错误追踪、分析管道。

司法管辖区

哪些法律可以强制披露?

总部位于美国的提供商受 FISA 702 和 CLOUD Act 管辖 - 即使数据存放在法兰克福也不例外。

密钥托管

谁实际持有加密密钥?

如果云服务商同时持有数据和密钥，无论签订何种 DPA，数据对其而言都是可读的。

失败 AWS · Azure · GCP · EU 区域

在司法管辖权和密钥托管上失败。

欧盟数据、美国母公司、默认路径中的美国次级处理者、供应商管理的密钥。

通过 Binadit 托管技术栈

四项全部通过。

托管在欧盟、由欧盟总部基础设施提供。默认路径中零美国次级处理者。客户持有或欧盟 KMS 密钥。在您的第 28 条 DPA 中按名称列出。

为什么团队正在退出 Microsoft Azure

Azure 退出通常由三种诱因之一触发：明确排除美国司法管辖处理商的公共部门招标、将 Microsoft 365 + Azure 标记为 DORA 下单一集中风险的医疗或金融服务审计，或是计算出许可证补差费用与“免费” Azure 积分实际上等同于价值六位数的供应商锁定的 CISO。Azure 生态系统的耦合度比 AWS 更紧密，Active Directory、Office 365、Defender、Sentinel 通常都牵涉其中，这使得迁移比对应的 AWS 迁移更具侵入性。但仍然可行；我们已经做到过。

Microsoft Azure 服务及其仅欧盟等效方案

迁移不是"换一个盒子"。下面的映射是我们为离开以下平台的客户运行的 Microsoft Azure 基于 Schrems II 的考量 - 完全适用欧盟司法管辖，数据链路中不涉及美国母公司。

Microsoft Azure 服务	我们改用什么	工程说明
Azure Virtual Machines	Binadit 托管云平台。基于 Debian 或 Ubuntu 的 KVM 虚拟机，使用 Terraform 供给资源，通过 Ansible 配置。	IaaS 迁移较为直接；Windows 许可部分则需要更多考量（BYOL 或尽可能迁移至 Linux）。
Azure Blob Storage	Binadit 托管云平台。MinIO 或 Ceph RGW，兼容 S3。	迁移目标是兼容 S3 的欧盟存储；SDK 改动极小。
Azure SQL Database	Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。	从 Azure SQL（T-SQL 方言）迁移数据库结构是耗时最长的单项任务；可借助 AWS SCT 或 pgloader 等工具。这也是重新审视 ORM 选型的好时机。
Azure Front Door / CDN	我们为您部署并运维欧盟 CDN：Bunny.net 或 KeyCDN，并在源站使用 Nginx 和 Varnish 进行缓存。	CDN 是我们少数不自行运行的层级之一。我们会选定 EU 提供商，配置缓存头、清除策略和源站防护，并将其作为托管服务的一部分进行运维。
Azure DNS	Binadit 托管云平台。PowerDNS 或 Knot，权威 DNS，经 DNSSEC 签名。	Zone 以标准 zone 文件形式导出和导入，因此这通常是迁移中最平稳的部分。请提前一周降低 TTL。
AKS (managed Kubernetes)	Binadit 托管云平台。基于 Debian 或 Talos 的 Kubernetes，使用 Cilium 网络方案，并通过 cert-manager 管理证书。	Helm charts 和 YAML 可直接迁移；Azure 专有插件（Application Gateway Ingress、Azure CNI）需替换为标准等效方案。
Azure Functions	Binadit 托管云平台。在您的 Kubernetes 集群上运行 Knative 或 OpenFaaS。	大多数 Azure Functions 工作负载适合运行在一个运行 Knative 的小型欧盟 Kubernetes 集群上。
Azure Active Directory / Entra ID	Binadit 托管云平台。使用 Keycloak 或 Authentik 作为身份提供方，支持 OIDC 和 SAML。	最难的单项迁移任务。请规划3个月的并行运行窗口。跨SaaS的SSO集成需要重新映射。
Azure Service Bus / Event Grid	Binadit 托管云平台。根据投递保证要求，选用 RabbitMQ、NATS 或 Redis Streams。	欧盟主权空间中的托管队列选项有限；自行托管是标准做法。
Azure Monitor / Application Insights	Binadit 托管云平台。Prometheus、Grafana、Loki 和 Tempo，通过 OpenTelemetry 串联。	OpenTelemetry 埋点使应用代码层面的切换变得机械化、可按步骤完成。
Azure Cosmos DB	Binadit 托管云平台。MongoDB 副本集，或在文档模型并不复杂的场景下使用带 JSONB 的 PostgreSQL。	没有针对全球多区域 active-active 的一对一替代方案；如果您的工作负载确实需要这种模式，那需要另作讨论。
Defender / Sentinel (security)	Binadit 托管云平台。Coraza 或 ModSecurity 配合 OWASP Core Rule Set，并使用 CrowdSec 进行行为拦截。	CrowdSec 总部位于法国，在 SIEM/IDS 领域的竞争力日益增强。
Key Vault	Binadit 托管云平台。自托管的 HashiCorp Vault 或 Infisical，支持自动租约轮换。	Vault是生产级的自主可控解决方案；我们为客户运营管理该系统。
Microsoft 365 (email, Teams, OneDrive)	Binadit 托管云平台。Postfix 配合 DKIM、SPF 和 DMARC，使用 Rspamd 进行过滤。	这往往比基础设施迁移本身更难协调的是内部立场问题。很多情况下会选择继续使用 M365，并以文档记录相关风险，而非直接迁移。

Azure Virtual Machines

我们改用什么: Binadit 托管云平台。基于 Debian 或 Ubuntu 的 KVM 虚拟机，使用 Terraform 供给资源，通过 Ansible 配置。
工程说明: IaaS 迁移较为直接；Windows 许可部分则需要更多考量（BYOL 或尽可能迁移至 Linux）。

Azure Blob Storage

我们改用什么: Binadit 托管云平台。MinIO 或 Ceph RGW，兼容 S3。
工程说明: 迁移目标是兼容 S3 的欧盟存储；SDK 改动极小。

Azure SQL Database

我们改用什么: Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。
工程说明: 从 Azure SQL（T-SQL 方言）迁移数据库结构是耗时最长的单项任务；可借助 AWS SCT 或 pgloader 等工具。这也是重新审视 ORM 选型的好时机。

Azure Front Door / CDN

我们改用什么: 我们为您部署并运维欧盟 CDN：Bunny.net 或 KeyCDN，并在源站使用 Nginx 和 Varnish 进行缓存。
工程说明: CDN 是我们少数不自行运行的层级之一。我们会选定 EU 提供商，配置缓存头、清除策略和源站防护，并将其作为托管服务的一部分进行运维。

Azure DNS

我们改用什么: Binadit 托管云平台。PowerDNS 或 Knot，权威 DNS，经 DNSSEC 签名。
工程说明: Zone 以标准 zone 文件形式导出和导入，因此这通常是迁移中最平稳的部分。请提前一周降低 TTL。

AKS (managed Kubernetes)

我们改用什么: Binadit 托管云平台。基于 Debian 或 Talos 的 Kubernetes，使用 Cilium 网络方案，并通过 cert-manager 管理证书。
工程说明: Helm charts 和 YAML 可直接迁移；Azure 专有插件（Application Gateway Ingress、Azure CNI）需替换为标准等效方案。

Azure Functions

我们改用什么: Binadit 托管云平台。在您的 Kubernetes 集群上运行 Knative 或 OpenFaaS。
工程说明: 大多数 Azure Functions 工作负载适合运行在一个运行 Knative 的小型欧盟 Kubernetes 集群上。

Azure Active Directory / Entra ID

我们改用什么: Binadit 托管云平台。使用 Keycloak 或 Authentik 作为身份提供方，支持 OIDC 和 SAML。
工程说明: 最难的单项迁移任务。请规划3个月的并行运行窗口。跨SaaS的SSO集成需要重新映射。

Azure Service Bus / Event Grid

我们改用什么: Binadit 托管云平台。根据投递保证要求，选用 RabbitMQ、NATS 或 Redis Streams。
工程说明: 欧盟主权空间中的托管队列选项有限；自行托管是标准做法。

Azure Monitor / Application Insights

我们改用什么: Binadit 托管云平台。Prometheus、Grafana、Loki 和 Tempo，通过 OpenTelemetry 串联。
工程说明: OpenTelemetry 埋点使应用代码层面的切换变得机械化、可按步骤完成。

Azure Cosmos DB

我们改用什么: Binadit 托管云平台。MongoDB 副本集，或在文档模型并不复杂的场景下使用带 JSONB 的 PostgreSQL。
工程说明: 没有针对全球多区域 active-active 的一对一替代方案；如果您的工作负载确实需要这种模式，那需要另作讨论。

Defender / Sentinel (security)

我们改用什么: Binadit 托管云平台。Coraza 或 ModSecurity 配合 OWASP Core Rule Set，并使用 CrowdSec 进行行为拦截。
工程说明: CrowdSec 总部位于法国，在 SIEM/IDS 领域的竞争力日益增强。

Key Vault

我们改用什么: Binadit 托管云平台。自托管的 HashiCorp Vault 或 Infisical，支持自动租约轮换。
工程说明: Vault是生产级的自主可控解决方案；我们为客户运营管理该系统。

Microsoft 365 (email, Teams, OneDrive)

我们改用什么: Binadit 托管云平台。Postfix 配合 DKIM、SPF 和 DMARC，使用 Rspamd 进行过滤。
工程说明: 这往往比基础设施迁移本身更难协调的是内部立场问题。很多情况下会选择继续使用 M365，并以文档记录相关风险，而非直接迁移。

我们如何迁移离开 Microsoft Azure

典型的中端市场迁移分为三个阶段进行。以下数据假设工程团队规模为 6-10 人，应用程序技术栈复杂度中等。

第 1-3 周

审计与 ID 映射

对Azure服务、Entra ID依赖关系、SSO集成和许可情况进行清点。身份层是耗时最长的部分。输出：将SSO迁移单独划定范围的分阶段计划。
第 3-6 周

边缘节点、监控、软依赖项

替换Front Door、Azure DNS、App Insights和Blob Storage。预先配置欧盟计算资源并复制数据库。如适用，将CI/CD从Azure DevOps迁出。
第 6-18 周

Compute、数据库、身份切换

将AKS工作负载迁移至托管的欧盟K8s。将SQL Database迁移至PostgreSQL，并通过逻辑复制实现在线切换。身份系统迁移采用并行运行方式，按应用逐个切换SSO。

我们所执行的Azure迁出项目的5年TCO：通常便宜25-45%，最大的节省来自避免许可证补差（licence true-up）以及带宽/出口流量费用。请注意：如果您的团队使用Microsoft 365并计划继续使用，身份层的迁移只能部分解耦，这一决策应由董事会层面决定。

常见问题

查看所有常见问题

Microsoft Cloud for Sovereignty 能解决 Schrems II 问题吗？

这改善了文档层面的说明，但并未改变底层的司法管辖权：Microsoft Corporation 仍然是母公司。对于分析结果取决于母公司司法管辖权的工作负载（即 Schrems II 之后的大多数受监管工作负载）而言，仅凭这一点是不够的。

Bleu 怎么样？

许可式主权方案，即由欧盟实体在许可下运营美国技术，本质上是伪主权方案，由总部位于欧盟的实体在美国技术合作伙伴的许可下运营。它们可以满足特定的监管要求（尤其是法国针对 Bleu 的 SecNumCloud 认证），但继承了一套自身无法独立维护的技术栈。对于大多数买家而言，采用纯粹的欧盟原生技术栈是架构上更简单的答案。

我们可以离开 Azure 但保留 Microsoft 365 吗？

是的，我们许多客户都在运行这种混合方案。其取舍在于：流经M365的个人数据（邮件内容、OneDrive文件、Teams聊天记录）仍处于Microsoft的处理范围内。请在DPA中记录这一点，采取补充措施（对敏感文件夹使用欧盟持有密钥的静态加密），并将客户数据基础设施保留在主权技术栈上。

这对我们的 Microsoft 企业协议有何影响?

现有的 EA 通常有一年或多年期限；迁移的目标是终止下一次续约或对其进行合理调整，而不是终止当前合同。当您的客户经理听到“我们正在评估主权替代方案”时，通常会主动提供优惠条件。请善用这一点。

Active Directory在实践中可以被替代吗？

可分阶段替换。Keycloak 对 OIDC/SAML/SCIM 支持良好；针对物理桌面的 Windows 域认证，Samba 4 配合 FreeIPA 是成熟的开源方案。这一过渡通常伴随着「现代化工作场所」的简化，减少各应用独立的 SSO，转向标准化的 OIDC。

Azure 迁移退出需要多长时间?

对于一个中型工作负载（50-200 台虚拟机、1-2 个 SQL 数据库、AKS、Entra ID）：耗时 16-24 周。如果由托管基础设施合作伙伴主导整体协调：10-16 周。身份层是进度风险所在，而非计算层。

规划您的退出 Microsoft Azure.

30 分钟范围确定通话。我们将您的技术栈映射到仅欧盟替代方案,估算迁移工作量,并告诉您这是否是正确的选择。

预约通话对比其他服务商