仅欧洲替代方案 AWS.

Amazon Web Services is the original public cloud - and the original Schrems II problem. The same EU regions that make AWS technically usable for European workloads do not change the parent jurisdiction: AWS Inc. is a Delaware corporation, AWS EMEA SARL is a Luxembourg subsidiary fully controlled by it, and the CLOUD Act applies to both. For audited workloads, regulated industries and any business that has had a customer ask "is your provider US-subpoenable?", the honest answer on AWS is yes. Below is the engineering-grade map for getting off it.

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

预约通话先扫描您的域

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

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

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

驻留

数据物理存储在哪里?

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

次级处理者

您的数据路径中还有谁?

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

司法管辖区

哪些法律可以强制披露?

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

密钥托管

谁实际持有加密密钥?

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

失败 AWS · Azure · GCP · EU 区域

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

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

通过 Binadit 托管技术栈

四项全部通过。

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

为什么团队正在退出 AWS

The drivers we hear in scoping calls are consistent: a procurement gate that now demands "no third-country data processor" (NIS2, DORA, public sector), a customer audit (typically B2B enterprise or healthcare) that flagged the AWS relationship, escalating egress and bandwidth costs that look worse every quarter, or a leadership-level concern after the 2024-2025 round of EU-US transfer mechanism uncertainty. The technical lift to leave AWS is rarely the blocker it appears to be. The real friction is choreography: zero-downtime database migrations, DNS cutover, observability continuity. That is where a managed-infrastructure partner saves months.

AWS 服务及其仅欧盟等效方案

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

AWS 服务	我们改用什么	工程说明
EC2 (compute)	Binadit 托管云平台。基于 Debian 或 Ubuntu 的 KVM 虚拟机，使用 Terraform 供给资源，通过 Ansible 配置。	我们根据您实际的负载情况来确定实例规格，而非套用目录档位，因此大多数迁移最终会使用数量更少、利用率更高的机器。
S3 (object storage)	Binadit 托管云平台。MinIO 或 Ceph RGW，兼容 S3。	兼容 S3 的 API 已成通用标准；大多数应用代码只需修改一个 endpoint。大多数欧盟供应商不收取出口流量费用。
RDS / Aurora (managed DB)	Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。	流式复制可实现零停机切换。托管的欧盟 PostgreSQL 定价通常比同等规格的 RDS 低 30-50%。
CloudFront (CDN)	我们为您部署并运维欧盟 CDN：Bunny.net 或 KeyCDN，并在源站使用 Nginx 和 Varnish 进行缓存。	CDN 是我们少数不自行运行的层级之一。我们会选定 EU 提供商，配置缓存头、清除策略和源站防护，并将其作为托管服务的一部分进行运维。
Route 53 (DNS)	Binadit 托管云平台。PowerDNS 或 Knot，权威 DNS，经 DNSSEC 签名。	Zone 以标准 zone 文件形式导出和导入，因此这通常是迁移中最平稳的部分。请提前一周降低 TTL。
Lambda (serverless)	Binadit 托管云平台。在您的 Kubernetes 集群上运行 Knative 或 OpenFaaS。	对于主权部署，在欧盟计算资源上自托管 Knative 是最简洁的方案。大多数 Lambda 工作负载适合放在小型 Kubernetes 集群中。
SES (email)	Binadit 托管云平台。Postfix 配合 DKIM、SPF 和 DMARC，使用 Rspamd 进行过滤。	对于每月低于 100 万的事务量，配置得当的 Postfix relay 在运维上比 SES 更简单、更经济。
SQS / SNS	Binadit 托管云平台。根据投递保证要求，选用 RabbitMQ、NATS 或 Redis Streams。	在欧盟主权空间中，托管消息代理较为罕见。自行托管是标准方案；我们为客户运营维护。
EKS (managed Kubernetes)	Binadit 托管云平台。基于 Debian 或 Talos 的 Kubernetes，使用 Cilium 网络方案，并通过 cert-manager 管理证书。	欧盟供应商上的托管 K8s 对 95% 的工作负载具有功能对等性。
CloudWatch / X-Ray	Binadit 托管云平台。Prometheus、Grafana、Loki 和 Tempo，通过 OpenTelemetry 串联。	OpenTelemetry 标准让迁移变得轻而易举；运维层面的收益是统一的仪表盘，以及不再按指标数量计费。
IAM	Binadit 托管云平台。使用 Keycloak 或 Authentik 作为身份提供方，支持 OIDC 和 SAML。	没有一对一替代方案；跨平台身份需要通过 Vault、OIDC 提供商（Keycloak）以及按工具划分的角色来重建。
WAF / Shield	Binadit 托管云平台。Coraza 或 ModSecurity 配合 OWASP Core Rule Set，并使用 CrowdSec 进行行为拦截。	规则会根据你的实际流量进行调优，而非直接套用默认规则集，这正是防止 WAF 悄悄拦截真实客户的关键。
KMS	Binadit Private Infrastructure。使用 Vault Transit 进行密钥管理，在合规要求的场景下配备 HSM 支持的密钥。	对于 HYOK 场景，本地部署 HSM 配合云端 BYOK 是标准的主权化方案。
Secrets Manager / SSM Parameter Store	Binadit 托管云平台。自托管的 HashiCorp Vault 或 Infisical，支持自动租约轮换。	在欧盟基础设施上部署 Vault 是生产级的解决方案。我们负责部署和运维。

EC2 (compute)

我们改用什么: Binadit 托管云平台。基于 Debian 或 Ubuntu 的 KVM 虚拟机，使用 Terraform 供给资源，通过 Ansible 配置。
工程说明: 我们根据您实际的负载情况来确定实例规格，而非套用目录档位，因此大多数迁移最终会使用数量更少、利用率更高的机器。

S3 (object storage)

我们改用什么: Binadit 托管云平台。MinIO 或 Ceph RGW，兼容 S3。
工程说明: 兼容 S3 的 API 已成通用标准；大多数应用代码只需修改一个 endpoint。大多数欧盟供应商不收取出口流量费用。

RDS / Aurora (managed DB)

我们改用什么: Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。
工程说明: 流式复制可实现零停机切换。托管的欧盟 PostgreSQL 定价通常比同等规格的 RDS 低 30-50%。

CloudFront (CDN)

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

Route 53 (DNS)

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

Lambda (serverless)

我们改用什么: Binadit 托管云平台。在您的 Kubernetes 集群上运行 Knative 或 OpenFaaS。
工程说明: 对于主权部署，在欧盟计算资源上自托管 Knative 是最简洁的方案。大多数 Lambda 工作负载适合放在小型 Kubernetes 集群中。

SES (email)

我们改用什么: Binadit 托管云平台。Postfix 配合 DKIM、SPF 和 DMARC，使用 Rspamd 进行过滤。
工程说明: 对于每月低于 100 万的事务量，配置得当的 Postfix relay 在运维上比 SES 更简单、更经济。

SQS / SNS

我们改用什么: Binadit 托管云平台。根据投递保证要求，选用 RabbitMQ、NATS 或 Redis Streams。
工程说明: 在欧盟主权空间中，托管消息代理较为罕见。自行托管是标准方案；我们为客户运营维护。

EKS (managed Kubernetes)

我们改用什么: Binadit 托管云平台。基于 Debian 或 Talos 的 Kubernetes，使用 Cilium 网络方案，并通过 cert-manager 管理证书。
工程说明: 欧盟供应商上的托管 K8s 对 95% 的工作负载具有功能对等性。

CloudWatch / X-Ray

我们改用什么: Binadit 托管云平台。Prometheus、Grafana、Loki 和 Tempo，通过 OpenTelemetry 串联。
工程说明: OpenTelemetry 标准让迁移变得轻而易举；运维层面的收益是统一的仪表盘，以及不再按指标数量计费。

IAM

我们改用什么: Binadit 托管云平台。使用 Keycloak 或 Authentik 作为身份提供方，支持 OIDC 和 SAML。
工程说明: 没有一对一替代方案；跨平台身份需要通过 Vault、OIDC 提供商（Keycloak）以及按工具划分的角色来重建。

WAF / Shield

我们改用什么: Binadit 托管云平台。Coraza 或 ModSecurity 配合 OWASP Core Rule Set，并使用 CrowdSec 进行行为拦截。
工程说明: 规则会根据你的实际流量进行调优，而非直接套用默认规则集，这正是防止 WAF 悄悄拦截真实客户的关键。

KMS

我们改用什么: Binadit Private Infrastructure。使用 Vault Transit 进行密钥管理，在合规要求的场景下配备 HSM 支持的密钥。
工程说明: 对于 HYOK 场景，本地部署 HSM 配合云端 BYOK 是标准的主权化方案。

Secrets Manager / SSM Parameter Store

我们改用什么: Binadit 托管云平台。自托管的 HashiCorp Vault 或 Infisical，支持自动租约轮换。
工程说明: 在欧盟基础设施上部署 Vault 是生产级的解决方案。我们负责部署和运维。

我们如何迁移离开 AWS

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

Weeks 1-2

Audit & dependency map

Inventory every AWS service in use, every IAM role, every Lambda, every cross-service call. Tag personal data flows. Output: a remediation plan with risk-ranked findings and an effort estimate per service.
Weeks 3-6

Soft dependencies & egress prep

Replace CloudFront, Route 53, SES and CloudWatch first - zero application code changes for most. Move S3 buckets behind S3-compatible EU storage with dual-write during cutover. Pre-stage replicas of RDS in EU.
Weeks 6-14

Core compute & DB cutover

Blue-green compute migration with DNS-level traffic shift. Streaming-replication database cutover during a low-traffic window. EKS workloads moved to managed EU K8s or self-managed Talos. Decommission AWS account once verified.

5-year TCO modelling on workloads we have actually migrated: typically 30-55% cheaper on EU sovereign infrastructure for predictable workloads, neutral to slightly higher for highly bursty workloads that benefit from sub-second autoscaling. Egress savings alone are often the difference between a positive and negative ROI.

常见问题

查看所有常见问题

Does using an AWS EU region (Frankfurt, Ireland, Stockholm) solve the Schrems II problem?

No. The data residency is in the EU but Amazon Web Services Inc. is the controller of the infrastructure under US law. The CLOUD Act allows US authorities to compel disclosure of data held by US-controlled entities anywhere in the world. The EDPB has explicitly flagged this as a Schrems II issue. AWS EMEA SARL is a Luxembourg subsidiary fully owned by AWS Inc.; that ownership chain is what the analysis turns on.

How long does an AWS exit take in practice?

For a mid-market application (10-50 EC2 instances, a couple of RDS databases, S3, CloudFront, SES) with a 6-10 person engineering team and competent operational support: 10-16 weeks elapsed time. With a managed-infrastructure partner driving the choreography (which is most of the actual work), 6-10 weeks.

What about AWS GovCloud or AWS Sovereign Cloud Europe?

AWS GovCloud is for US federal workloads and is not relevant to EU buyers. AWS European Sovereign Cloud (announced 2023, in build-out) is operated by EU-headquartered AWS staff in EU regions, but the parent legal entity remains Amazon Web Services Inc. Whether it is "sovereign enough" depends on your specific compliance regime; for many Schrems II analyses it is not sufficient because the parent jurisdiction is unchanged.

Will we lose features by leaving AWS?

Specific managed services (DynamoDB single-digit-ms, Aurora Serverless v2, Bedrock model access, SageMaker training on H100s) have no clean EU sovereign equivalents. For 90% of mid-market workloads - web applications, APIs, e-commerce, B2B SaaS, analytics on warehouses - the EU sovereign stack covers it. We tell you upfront if your workload sits in the 10% category.

Can we keep some AWS services and migrate the rest?

Yes - a hybrid is sometimes the right answer. The discipline is to keep AWS only for clearly non-personal workloads, and document the boundary in your DPA. We have run hybrids where AWS handles ML training (no personal data, batch-only) and the EU sovereign stack handles all customer-facing infrastructure.

What does a managed exit cost?

Project-based pricing, scoped after the audit. Typical mid-market AWS exit: €25-80k for the project, plus the ongoing managed-infrastructure retainer for the new EU stack. The first-year savings on AWS spend usually exceed the project cost.

规划您的退出 AWS.

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

预约通话对比其他服务商