仅欧洲替代方案 Google Cloud Platform.

在三大美国超大规模云厂商中，Google Cloud 在欧盟市场份额最小，但拥有最强的数据工程品牌形象。而这正是迁移的难点所在：BigQuery、Vertex AI、Spanner 以及 GCP 目录中的其他产品都是优秀的工具，其中部分产品在欧盟主权替代方案中并无对等产品。坦率地说，对于大多数中端市场工作负载，Web 应用、API、电子商务，欧盟主权技术栈可以很好地适配。但对于专业的数据工程或机器学习工作负载，情况则更为复杂。我们会告诉您您的场景属于哪一类。

美国 仅限 EU 的替代技术栈 14 已梳理的服务
预约通话 先扫描您的域
供应商
Google Cloud Platform
总部
Mountain View, CA
司法管辖区
美国
法律制度
CLOUD Act, FISA 702, EO 12333

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

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

驻留

数据物理存储在哪里?

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

次级处理者

您的数据路径中还有谁?

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

司法管辖区

哪些法律可以强制披露?

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

密钥托管

谁实际持有加密密钥?

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

失败 AWS · Azure · GCP · EU 区域

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

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

通过 Binadit 托管技术栈

四项全部通过。

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

为什么团队正在退出 Google Cloud Platform

我们评估过的 GCP 退出案例通常来自两类情况：一类是最初在 GCP 上小规模启动的受监管工作负载，如今需要满足 Schrems II 合规要求以扩展业务；另一类是 B2B SaaS，其企业客户（德国银行、法国政府、荷兰医疗机构）在合同中明确要求不得有美国司法管辖权下的处理方。2024 年欧盟-美国数据隐私框架（Data Privacy Framework）面临的法律挑战又带来了第三种诱因，管理层层面对传输机制再次被推翻的担忧。已获许可的主权产品虽改善了合规文档，但底层技术仍源自美国。

Google Cloud Platform 服务及其仅欧盟等效方案

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

Compute Engine (GCE)

我们改用什么
Binadit 托管云平台。基于 Debian 或 Ubuntu 的 KVM 虚拟机，使用 Terraform 供给资源，通过 Ansible 配置。
工程说明
欧盟提供商的每 vCPU 定价明显更低；在常规规模下无需使用预留实例。

Cloud Storage

我们改用什么
Binadit 托管云平台。MinIO 或 Ceph RGW，兼容 S3。
工程说明
以上所有方案均兼容 S3 API；SDK 改动极小。

Cloud SQL

我们改用什么
Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。
工程说明
流式复制让我们能够以数秒的停机时间完成切换，而无需专门的维护窗口，且恢复流程会按计划定期测试，而不是想当然地假设可行。

GKE (managed Kubernetes)

我们改用什么
Binadit 托管云平台。基于 Debian 或 Talos 的 Kubernetes，使用 Cilium 网络方案，并通过 cert-manager 管理证书。
工程说明
GKE Autopilot 没有直接对应的替代方案；对于大多数工作负载，托管 K8s 已经足够。我们首选的高信任度方案是在 bare metal 上运行 Talos。

Cloud Run

我们改用什么
Binadit 托管云平台。在 GitLab CI 中构建 Docker 镜像并部署到 Kubernetes，为每个分支提供审查环境。
工程说明
Knative 是 Cloud Run 的上游项目；迁移本质上就是重新部署到欧盟托管的 Knative 集群上。

BigQuery

我们改用什么
Binadit 托管云平台。ClickHouse 或带列式扩展的 PostgreSQL，使用 dbt 建模。
工程说明
在 BigQuery 规模下没有一对一的主权等效方案。自托管 ClickHouse 是生产环境的常见模式；对于真正的 Schrems II 合规需求，这是大多数客户会保留在有文档记录的混合架构中的工作负载。

Cloud Pub/Sub

我们改用什么
Binadit 托管云平台。根据投递保证要求，选用 RabbitMQ、NATS 或 Redis Streams。
工程说明
Kafka 是处理高吞吐事件流的标准方案；NATS 则更为轻量。

Cloud Functions

我们改用什么
Binadit 托管云平台。在您的 Kubernetes 集群上运行 Knative 或 OpenFaaS。
工程说明
函数迁移是机械化的过程；欧盟主权方案的冷启动性能具有竞争力。

Cloud DNS

我们改用什么
Binadit 托管云平台。PowerDNS 或 Knot，权威 DNS，经 DNSSEC 签名。
工程说明
通过 AXFR 或区域导出进行标准区域迁移。

Cloud CDN / Cloud Armor

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

IAM / Cloud Identity

我们改用什么
Binadit 托管云平台。使用 Keycloak 或 Authentik 作为身份提供方，支持 OIDC 和 SAML。
工程说明
OIDC/SAML 迁移是成熟的路径；Workspace 身份管理则是另一个需要单独考虑的决策。

Cloud Operations (Stackdriver)

我们改用什么
Binadit 托管云平台。Prometheus、Grafana、Loki 和 Tempo，通过 OpenTelemetry 串联。
工程说明
OpenTelemetry 埋点让应用层的迁移变得非常简单。

Vertex AI / model APIs

我们改用什么
Binadit Private Infrastructure。在专用 GPU 硬件上自托管开放权重模型，通过 vLLM 或 Ollama 提供服务。
工程说明
在这一项上，我们最有可能坦率地告诉您答案是混合方案。目前自建部署无法达到前沿模型的质量水准。

Firestore / Firebase

我们改用什么
Binadit 托管云平台。MongoDB 副本集，或在文档模型并不复杂的场景下使用带 JSONB 的 PostgreSQL。
工程说明
Firestore 的实时同步功能是最难替代的部分；对于文档类工作负载，PostgreSQL + LISTEN/NOTIFY 通常足以胜任。

我们如何迁移离开 Google Cloud Platform

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

  1. 第 1-2 周

    审计与数据工程范围

    对GCP服务进行清点，按主权必要性分类。特别关注BigQuery和Vertex的使用情况，这些决定了迁移的整体形态。输出：分阶段计划，以及对数据工程工作负载的明确决策。

  2. 第 3-6 周

    边缘节点、软依赖项、IAM 预配置

    Cloud DNS、CDN、监控和Cloud Storage率先迁移。Keycloak与Cloud Identity并行部署，用于并行运行验证。在EU基础设施上预先部署compute。

  3. 第 6-14 周

    核心切换 + 分析决策

    GCE/GKE 工作负载通过蓝绿部署完成切换。Cloud SQL 进行复制并切换。BigQuery 要么迁移至 ClickHouse，要么保留在有文档记录的混合架构中，并在边界处清除个人数据。Vertex AI 工作负载迁移至 Mistral 或自托管的等效方案。

我们所执行的GCP迁出项目的5年TCO：对于可预测的工作负载，通常便宜30-50%。例外情况是重度依赖BigQuery的分析型场景，在这种情况下，GCP带来的运维成本节省，往往足以支撑采用混合架构（在边界处对个人数据进行匿名化处理），而不必完全迁移。

常见问题

查看所有常见问题

GCP 的“Sovereign Controls”或获授权的主权方案能解决这个问题吗？
Sovereign Controls（原 Google Cloud Sovereign）增加了运营层面的隔离：EU 居民员工、加密密钥控制、审计日志。但它并未改变底层的司法管辖权，Google LLC 仍然是技术所有者。经许可的主权方案在授权下使用相同的技术；限制存在于技术层面。对于大多数 Schrems II 分析而言，两者都是改进，但都不是完全的主权。
我们可以保留 BigQuery 并迁移其余部分吗？
是的，这是一种常见的方案。关键原则是：在数据摄入边界处清洗或匿名化个人数据，使进入BigQuery的数据不再受GDPR约束。请在DPA中记录该边界。我们已为多个中型市场的分析工作负载实施过这一方案。
现实可行的 ML/AI 替代方案是什么？
Mistral AI（法国）提供的基础模型质量可与GPT-4级别相媲美，且符合欧洲司法管辖要求。Aleph Alpha（德国）专注于设计上即具备主权特性的LLM工作负载。在训练方面，专用的EU GPU硬件可满足大多数应用场景需求。与Vertex AI相比的差距主要在于工具链的成熟度，而非底层能力本身。
GKE 迁移与 AKS 或 EKS 迁移相比如何?
机制上相似，Helm charts、manifests和CI/CD pipelines可以顺利迁移。GKE专有插件（Workload Identity、GKE托管的cert-manager）需要替换为标准等效方案。K8s插件迁移预计需1-2周时间。
GCP 迁移退出需要多长时间?
对于一个中型市场应用（GCE、Cloud SQL、GKE、Cloud Storage，不含 BigQuery）：耗时 10-14 周。如果有托管基础设施合作伙伴：6-10 周。若将 BigQuery 纳入范围，根据迁移目标不同，还会增加 4-8 周。
Workspace（Gmail、Docs、Drive）怎么样？
Workspace是与GCP基础设施相独立的话题。许多客户采用混合方案：替换GCP基础设施，同时保留Workspace并记录其数据暴露情况。针对Workspace的mailbox.org迁移路径已得到充分支持。

规划您的退出 Google Cloud Platform.

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

预约通话 对比其他服务商