仅欧洲替代方案 Microsoft Azure.

Microsoft Azure is the cloud most often defended with the words "but we already use Microsoft for everything." That defence does not survive a Schrems II analysis: Microsoft Corporation is a US company, every Azure subsidiary is US-controlled, and Microsoft has explicitly acknowledged in court (Microsoft Ireland, 2018) that it would comply with valid US legal process for data anywhere globally - which is precisely what the CLOUD Act later codified. The "Microsoft Cloud for Sovereignty" and Bleu (Microsoft × Capgemini × Orange) initiatives are interesting but technology-licensed from a US parent. For genuine EU sovereignty, you exit. Below is the map.

United States 仅限 EU 的替代技术栈 14 已梳理的服务

预约通话先扫描您的域

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

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

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

驻留

数据物理存储在哪里?

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

次级处理者

您的数据路径中还有谁?

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

司法管辖区

哪些法律可以强制披露?

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

密钥托管

谁实际持有加密密钥?

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

失败 AWS · Azure · GCP · EU 区域

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

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

通过 Binadit 托管技术栈

四项全部通过。

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

为什么团队正在退出 Microsoft Azure

Azure exits typically come from one of three triggers: a public-sector tender that explicitly excludes US-jurisdiction processors, a healthcare or financial services audit that flagged Microsoft 365 + Azure as a single concentration risk under DORA, or a CISO who calculated that the licence true-up costs and "free" Azure credits actually translate to vendor lock-in worth six figures. The Azure ecosystem has tighter coupling than AWS - Active Directory, Office 365, Defender, Sentinel are typically all in the mix - which makes the migration more invasive than its AWS equivalent. It is still doable; we have done it.

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 人，应用程序技术栈复杂度中等。

Weeks 1-3

Audit & ID-mapping

Inventory Azure services, Entra ID dependencies, SSO integrations and licensing. The identity layer is the longest tail. Output: phased plan with the SSO migration scoped separately.
Weeks 3-6

Edge, monitoring, soft dependencies

Replace Front Door, Azure DNS, App Insights and Blob Storage. Pre-stage EU compute and replicate database. Move CI/CD off Azure DevOps if applicable.
Weeks 6-18

Compute, DB, identity cutover

AKS workloads to managed EU K8s. SQL Database to PostgreSQL with logical replication for live cutover. Identity migration with parallel-run; cut SSO over per application.

5-year TCO on Azure exits we have run: typically 25-45% cheaper, with the largest savings coming from licence true-up avoidance and bandwidth/egress. Bear in mind: if your team uses Microsoft 365 and is staying on it, the identity-layer migration only partially decouples - that decision belongs at board level.

常见问题

查看所有常见问题

Does Microsoft Cloud for Sovereignty solve the Schrems II problem?

It improves the documentation story but does not change the underlying jurisdiction: Microsoft Corporation remains the parent. For workloads where the analysis turns on parent-jurisdiction (i.e. most regulated workloads after Schrems II), it is not sufficient on its own.

What about Bleu?

Licensed sovereign offerings, where an EU entity operates US technology under licence, are pseudo-sovereign - operated by EU-headquartered entities under licence from a US technology partner. They can satisfy specific regulatory requirements (notably the French SecNumCloud certification for Bleu) but inherit a stack they cannot independently maintain. For most buyers, a clean EU-native stack is the architecturally simpler answer.

Can we leave Azure but keep Microsoft 365?

Yes, and many of our clients run that hybrid. The trade-off is that personal data flowing through M365 (email content, OneDrive files, Teams chat) remains under Microsoft processing. Document it in your DPA, apply supplementary measures (encryption at rest with EU-held keys for sensitive folders), and keep customer-data infrastructure on the sovereign stack.

How does this affect our Microsoft Enterprise Agreement?

Existing EAs typically have annual or multi-year terms; the migration target is to stop the next renewal or right-size it, not to break the current contract. Your account manager will offer concessions when they hear "we are evaluating sovereign alternatives." Use that.

Is Active Directory replaceable in practice?

Replaceable in stages. Keycloak handles OIDC/SAML/SCIM well; for Windows-domain authentication on physical desktops, Samba 4 with FreeIPA is the established open-source path. The transition typically runs alongside a "modern workplace" simplification - fewer per-app SSOs, more standard OIDC.

How long does an Azure exit take?

For a mid-size workload (50-200 VMs, 1-2 SQL DBs, AKS, Entra ID): 16-24 weeks elapsed time. With a managed-infrastructure partner driving the choreography: 10-16 weeks. The identity layer is the schedule risk, not the compute.

规划您的退出 Microsoft Azure.

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

预约通话对比其他服务商