Europa-only Alternative zu Google Cloud Platform.

Google Cloud ist der kleinste der drei US-Hyperscaler nach EU-Marktanteil, hat aber die stärkste Data-Engineering-Marke. Genau diese Marke ist die Migrationsherausforderung: BigQuery, Vertex AI, Spanner und der Rest des GCP-Katalogs sind exzellente Tools, und für einige davon gibt es keinen gleichwertigen souveränen EU-Ersatz. Die ehrliche Antwort ist, dass der souveräne EU-Stack für die meisten Mid-Market-Workloads - Webanwendungen, APIs, E-Commerce - gut passt. Für spezialisierte Data-Engineering- oder ML-Workloads ist die Angelegenheit differenzierter. Wir sagen Ihnen, in welche Kategorie Ihr Fall fällt.

Vereinigte Staaten Ersatz-Stack, ausschließlich EU 14 Dienste zugeordnet

Gespräch vereinbaren Erst Domain scannen

Anbieter: Google Cloud Platform
Hauptsitz: Mountain View, CA
Rechtsmacht: Vereinigte Staaten
Rechtsregime: CLOUD Act, FISA 702, EO 12333

"EU-Region" ist keine Souveränität. Vier Fragen entscheiden.

Data-Residency sagt, wo die Bits liegen. Souveränität sagt, welches Rechtssystem Zugriff erzwingen kann. Die Antwort muss auf allen vier Punkten halten, sonst ist der Stack nicht souverän.

Residenz

Wo sind die Daten physisch gespeichert?

Nicht "in der Cloud": welches Rechenzentrum, in welchem Land, unter welcher Jurisdiktion.

Subprozessoren

Wer ist sonst noch in Ihrem Datenpfad?

Jeder Anbieter, der die Daten berührt: das CDN, das E-Mail-Relay, der Error-Tracker, die Analytics-Pipeline.

Rechtsmacht

Wessen Gesetze können die Offenlegung erzwingen?

Ein Anbieter mit US-Hauptsitz untersteht FISA 702 und dem CLOUD Act, auch wenn die Bits in Frankfurt liegen.

Schlüsselverwahrung

Wer hält tatsächlich die Verschlüsselungsschlüssel?

Wenn der Cloud-Anbieter sowohl die Daten als auch die Schlüssel hält, sind die Daten für ihn lesbar, unabhängig von jedem AVV.

Erfüllt nicht AWS · Azure · GCP · EU-Region

Scheitert an Rechtsmacht und Schlüsselverwahrung.

EU-Daten, US-Mutterkonzern, US-Subprozessoren im Standardpfad, vom Anbieter verwaltete Schlüssel.

Erfüllt Binadit Managed Stack

Besteht in allen vier Punkten.

EU-gehostet auf Infrastruktur mit EU-Hauptsitz. Null US-Subprozessoren im Standardpfad. Kunden- oder EU-KMS-Schlüssel. Namentlich in Ihrer Artikel-28-AVV aufgeführt.

Warum Teams aussteigen Google Cloud Platform

GCP-Ausstiege, die wir bewertet haben, resultieren tendenziell aus einem von zwei Ansätzen: einem regulierten Workload, der klein auf GCP gestartet ist und nun Schrems-II-Konformität benötigt, um zu wachsen, oder einem B2B-SaaS, dessen Enterprise-Kunden (deutsche Banken, französische Behörden, niederländisches Gesundheitswesen) vertraglich explizit keinen US-jurisdiktionellen Verarbeiter verlangten. Die rechtlichen Anfechtungen des EU-US Data Privacy Framework von 2024 haben einen dritten Auslöser hinzugefügt - Bedenken auf Führungsebene hinsichtlich einer erneuten Aufhebung des Transfermechanismus. Lizenzierte souveräne Angebote verbessern die Dokumentation, erben aber die zugrunde liegende US-Technologie.

Google Cloud Platform Dienste und ihre EU-only Äquivalente

Eine Migration ist nicht "eine Box gegen eine andere tauschen". Die Zuordnung unten ist das, was wir für Kunden ausführen, die Folgendes verlassen: Google Cloud Platform auf Grundlage von Schrems II: vollständige EU-Jurisdiktion, kein US-Mutterkonzern im Datenpfad.

Google Cloud Platform Dienst	Was wir stattdessen betreiben	Engineering-Hinweis
Compute Engine (GCE)	Binadit Managed Cloud Platform. KVM-VMs auf Debian oder Ubuntu, provisioniert mit Terraform und konfiguriert mit Ansible.	Preise pro vCPU sind bei EU-Anbietern deutlich niedriger; reservierte Instanzen sind bei typischem Maßstab nicht erforderlich.
Cloud Storage	Binadit Managed Cloud Platform. MinIO oder Ceph RGW, S3-kompatibel.	S3-kompatible APIs bei allen diesen Optionen; SDK-Änderungen sind minimal.
Cloud SQL	Binadit Managed Cloud Platform. PostgreSQL oder MySQL mit Patroni für Failover und pgBackRest für Point-in-Time Recovery.	Streaming-Replikation ermöglicht uns eine Umschaltung mit Sekunden statt eines Wartungsfensters an Ausfallzeit, und Restores werden nach Plan getestet statt vorausgesetzt.
GKE (managed Kubernetes)	Binadit Managed Cloud Platform. Kubernetes auf Debian oder Talos, mit Cilium-Networking und cert-manager für Zertifikate.	GKE Autopilot hat kein direktes Äquivalent; für die meisten Workloads reicht managed K8s aus. Talos auf Bare-Metal ist unser bevorzugtes High-Trust-Setup.
Cloud Run	Binadit Managed Cloud Platform. Docker-Images, gebaut in GitLab CI und deployed auf Kubernetes, mit Review-Umgebungen pro Branch.	Knative ist der Upstream von Cloud Run; die Migration ist im Wesentlichen ein Redeploy auf einen EU-gehosteten Knative-Cluster.
BigQuery	Binadit Managed Cloud Platform. ClickHouse oder PostgreSQL mit spaltenorientierten Erweiterungen, modelliert mit dbt.	Kein 1:1-souveränes Äquivalent im BigQuery-Maßstab. ClickHouse self-hosted ist das Produktionsmuster; für echtes Schrems II ist dies die Workload, die die meisten Kunden in einem dokumentierten Hybrid belassen.
Cloud Pub/Sub	Binadit Managed Cloud Platform. RabbitMQ, NATS oder Redis Streams, je nach Zustellgarantien.	Kafka ist das Standardmuster für hochvolumige Event-Streams; NATS ist leichtgewichtiger.
Cloud Functions	Binadit Managed Cloud Platform. Knative oder OpenFaaS auf Ihrem Kubernetes-Cluster.	Die Migration von Functions ist mechanisch; die Cold-Start-Performance bei souveränen EU-Optionen ist wettbewerbsfähig.
Cloud DNS	Binadit Managed Cloud Platform. PowerDNS oder Knot, autoritativ, DNSSEC-signiert.	Standard-Zonenmigration via AXFR oder Zonen-Export.
Cloud CDN / Cloud Armor	Wir implementieren und betreiben ein EU-CDN für Sie: Bunny.net oder KeyCDN, mit Nginx- und Varnish-Caching an Ihrem Origin.	Ein CDN ist eine der wenigen Schichten, die wir nicht selbst betreiben. Wir wählen den EU-Anbieter aus, konfigurieren Cache-Header, Purge-Strategie und Origin Shielding und betreiben es als Teil des Managed Service.
IAM / Cloud Identity	Binadit Managed Cloud Platform. Keycloak oder Authentik als Identity Provider, mit OIDC und SAML.	OIDC/SAML-Migration ist gut erprobt; die Workspace-Identität ist eine separate Entscheidung.
Cloud Operations (Stackdriver)	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki und Tempo, verbunden mit OpenTelemetry.	OpenTelemetry-Instrumentierung macht die anwendungsseitige Migration trivial.
Vertex AI / model APIs	Binadit Private Infrastructure. Selbst gehostete Open-Weight-Modelle auf dedizierter GPU-Hardware, bereitgestellt über vLLM oder Ollama.	Dies ist der Punkt, bei dem wir Ihnen am ehesten ehrlich sagen: Die Antwort ist ein Hybrid. Die Qualität von Frontier-Modellen erreicht Self-Hosting heute nicht.
Firestore / Firebase	Binadit Managed Cloud Platform. MongoDB Replica Sets, oder PostgreSQL mit JSONB, wo das Dokumentenmodell dünner ist, als es aussieht.	Die Echtzeit-Synchronisation von Firestore ist am schwierigsten zu ersetzen; für Dokument-Workloads passt PostgreSQL + LISTEN/NOTIFY meist gut.

Compute Engine (GCE)

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. KVM-VMs auf Debian oder Ubuntu, provisioniert mit Terraform und konfiguriert mit Ansible.
Engineering-Hinweis: Preise pro vCPU sind bei EU-Anbietern deutlich niedriger; reservierte Instanzen sind bei typischem Maßstab nicht erforderlich.

Cloud Storage

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. MinIO oder Ceph RGW, S3-kompatibel.
Engineering-Hinweis: S3-kompatible APIs bei allen diesen Optionen; SDK-Änderungen sind minimal.

Cloud SQL

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. PostgreSQL oder MySQL mit Patroni für Failover und pgBackRest für Point-in-Time Recovery.
Engineering-Hinweis: Streaming-Replikation ermöglicht uns eine Umschaltung mit Sekunden statt eines Wartungsfensters an Ausfallzeit, und Restores werden nach Plan getestet statt vorausgesetzt.

GKE (managed Kubernetes)

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Kubernetes auf Debian oder Talos, mit Cilium-Networking und cert-manager für Zertifikate.
Engineering-Hinweis: GKE Autopilot hat kein direktes Äquivalent; für die meisten Workloads reicht managed K8s aus. Talos auf Bare-Metal ist unser bevorzugtes High-Trust-Setup.

Cloud Run

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Docker-Images, gebaut in GitLab CI und deployed auf Kubernetes, mit Review-Umgebungen pro Branch.
Engineering-Hinweis: Knative ist der Upstream von Cloud Run; die Migration ist im Wesentlichen ein Redeploy auf einen EU-gehosteten Knative-Cluster.

BigQuery

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. ClickHouse oder PostgreSQL mit spaltenorientierten Erweiterungen, modelliert mit dbt.
Engineering-Hinweis: Kein 1:1-souveränes Äquivalent im BigQuery-Maßstab. ClickHouse self-hosted ist das Produktionsmuster; für echtes Schrems II ist dies die Workload, die die meisten Kunden in einem dokumentierten Hybrid belassen.

Cloud Pub/Sub

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. RabbitMQ, NATS oder Redis Streams, je nach Zustellgarantien.
Engineering-Hinweis: Kafka ist das Standardmuster für hochvolumige Event-Streams; NATS ist leichtgewichtiger.

Cloud Functions

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Knative oder OpenFaaS auf Ihrem Kubernetes-Cluster.
Engineering-Hinweis: Die Migration von Functions ist mechanisch; die Cold-Start-Performance bei souveränen EU-Optionen ist wettbewerbsfähig.

Cloud DNS

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. PowerDNS oder Knot, autoritativ, DNSSEC-signiert.
Engineering-Hinweis: Standard-Zonenmigration via AXFR oder Zonen-Export.

Cloud CDN / Cloud Armor

Was wir stattdessen betreiben: Wir implementieren und betreiben ein EU-CDN für Sie: Bunny.net oder KeyCDN, mit Nginx- und Varnish-Caching an Ihrem Origin.
Engineering-Hinweis: Ein CDN ist eine der wenigen Schichten, die wir nicht selbst betreiben. Wir wählen den EU-Anbieter aus, konfigurieren Cache-Header, Purge-Strategie und Origin Shielding und betreiben es als Teil des Managed Service.

IAM / Cloud Identity

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Keycloak oder Authentik als Identity Provider, mit OIDC und SAML.
Engineering-Hinweis: OIDC/SAML-Migration ist gut erprobt; die Workspace-Identität ist eine separate Entscheidung.

Cloud Operations (Stackdriver)

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki und Tempo, verbunden mit OpenTelemetry.
Engineering-Hinweis: OpenTelemetry-Instrumentierung macht die anwendungsseitige Migration trivial.

Vertex AI / model APIs

Was wir stattdessen betreiben: Binadit Private Infrastructure. Selbst gehostete Open-Weight-Modelle auf dedizierter GPU-Hardware, bereitgestellt über vLLM oder Ollama.
Engineering-Hinweis: Dies ist der Punkt, bei dem wir Ihnen am ehesten ehrlich sagen: Die Antwort ist ein Hybrid. Die Qualität von Frontier-Modellen erreicht Self-Hosting heute nicht.

Firestore / Firebase

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. MongoDB Replica Sets, oder PostgreSQL mit JSONB, wo das Dokumentenmodell dünner ist, als es aussieht.
Engineering-Hinweis: Die Echtzeit-Synchronisation von Firestore ist am schwierigsten zu ersetzen; für Dokument-Workloads passt PostgreSQL + LISTEN/NOTIFY meist gut.

Wie wir migrieren von Google Cloud Platform

Eine typische Mittelstand-Migration läuft in drei Phasen. Die Zahlen unten gehen von einem 6-10-köpfigen Engineering-Team und einem mäßig komplexen Anwendungs-Stack aus.

Wochen 1-2

Audit- und Data-Engineering-Umfang

GCP-Dienste inventarisieren und nach Souveränitätsnotwendigkeit klassifizieren. Besonderes Augenmerk auf BigQuery- und Vertex-Nutzung - diese bestimmen die Form der Migration. Ergebnis: gestufter Plan plus die explizite Entscheidung zu Data-Engineering-Workloads.
Wochen 3-6

Edge, weiche Abhängigkeiten, IAM-Staging

Cloud DNS, CDN, Monitoring und Cloud Storage wurden zuerst verschoben. Keycloak wurde parallel zu Cloud Identity für einen Parallelbetrieb bereitgestellt. Compute wird vorab auf EU-Infrastruktur bereitgestellt.
Wochen 6-14

Core-Umstellung + Analytics-Entscheidung

GCE/GKE-Workloads werden per Blue-Green umgestellt. Cloud SQL wird repliziert und umgeschaltet. BigQuery wird entweder zu ClickHouse migriert oder in einem dokumentierten Hybridmodell beibehalten, wobei personenbezogene Daten an der Grenze entfernt werden. Vertex-AI-Workloads werden zu Mistral oder selbst gehosteten Äquivalenten verschoben.

5-Jahres-TCO bei GCP-Exits, die wir durchgeführt haben: 30-50% günstiger bei planbaren Workloads. Die Ausnahme sind BigQuery-intensive Analytics - hier rechtfertigt die operative Einsparung von GCP oft, es in einem Hybrid-Modell zu belassen (mit Anonymisierung personenbezogener Daten an der Grenze), statt zu migrieren.

Häufig gestellte Fragen

Alle häufig gestellten Fragen anzeigen

Lösen GCP „Sovereign Controls“ oder ein lizenziertes souveränes Angebot das Problem?

Sovereign Controls (ehemals Google Cloud Sovereign) fügt operative Trennung hinzu: in der EU ansässiges Personal, Kontrolle über Verschlüsselungsschlüssel, Audit-Logging. Es ändert nichts an der zugrunde liegenden Jurisdiktion - Google LLC bleibt Eigentümer der Technologie. Lizenzierte souveräne Angebote nutzen dieselbe Technologie unter Lizenz; der Vorbehalt liegt auf der Technologieebene. Für die meisten Schrems-II-Analysen sind beide Verbesserungen, aber keine vollständige Souveränität.

Können wir BigQuery behalten und alles andere migrieren?

Ja, und das ist ein gängiges Muster. Die Disziplin: Personenbezogene Daten an der Eingangsgrenze bereinigen oder anonymisieren, sodass das, was in BigQuery gelangt, nicht mehr der DSGVO unterliegt. Dokumentieren Sie die Grenze in Ihrem DPA. Wir haben dieses Muster für mehrere Analytics-Workloads im Mid-Market-Segment implementiert.

Was ist die realistische ML/KI-Alternative?

Mistral AI (FR) für Foundation-Modelle mit vergleichbarer Qualität zu GPT-4-Klasse unter europäischer Jurisdiktion. Aleph Alpha (DE) für von Grund auf souveräne LLM-Workloads. Für Training deckt dedizierte EU-GPU-Hardware die meisten Anwendungsfälle ab. Die Lücke gegenüber Vertex AI liegt im Tooling-Feinschliff, nicht in der reinen Leistungsfähigkeit.

Wie unterscheidet sich die GKE-Migration von AKS oder EKS?

Mechanisch ähnlich - Helm Charts, Manifests und CI/CD-Pipelines lassen sich sauber übertragen. GKE-spezifische Addons (Workload Identity, GKE-managed cert-manager) müssen durch Standardäquivalente ersetzt werden. Planen Sie 1-2 Wochen für die K8s-Addon-Migration ein.

Wie lange dauert ein GCP-Exit?

Für eine Mid-Market-Anwendung (GCE, Cloud SQL, GKE, Cloud Storage, ohne BigQuery): 10-14 Wochen Gesamtdauer. Mit einem Managed-Infrastructure-Partner: 6-10 Wochen. BigQuery im Umfang fügt je nach Migrationsziel 4-8 Wochen hinzu.

Was ist mit Workspace (Gmail, Docs, Drive)?

Workspace ist ein eigenständiges Thema, getrennt von der GCP-Infrastruktur. Viele Kunden betreiben ein Hybridmodell: Die GCP-Infrastruktur wird ersetzt, Workspace bleibt mit dokumentierter Risikoexposition bestehen. Der Migrationspfad von mailbox.org für Workspace ist gut unterstützt.

Plane deinen Exit von Google Cloud Platform.

30-minütiges Scoping-Gespräch. Wir bilden Ihren Stack auf EU-only Alternativen ab, schätzen den Migrationsaufwand und sagen Ihnen, ob es die richtige Entscheidung ist.

Gespräch vereinbaren Anderen Anbieter vergleichen