8 Min. Lesezeit

Google hat auf der Cloud Next 2026 Bausteine angekündigt, die Multi-Cloud von der Architektur-Theorie zur betrieblichen Entscheidung machen. Wer als DACH-CIO noch glaubt, Cross-Cloud-Strategie scheitere an Egress-Kosten und Daten-Silos, sollte genau hinsehen: Der Hebel ist nicht mehr Compute, sondern wo die Daten liegen und was deren Bewegung kostet.

Das Wichtigste in Kürze

• Cross-cloud Lakehouse (ehemals BigLake) erlaubt jetzt Abfragen über AWS-, Azure- und GCP-Datenquellen ohne vollständige Replikation, die Cross-cloud-Caching-Schicht legt den First-Read im Heimsystem ab und drückt Egress-Gebühren auf wiederkehrende Queries.
• Gemini Enterprise Agent Platform bündelt Agent-Registries, Skill-Registries und Governance in einem Layer, der explizit für Multi-Cloud-Deployments gebaut ist, kein neuer Vendor-Stack, sondern ein Steuerungs-Plane über bestehende Workloads.
• Agentic Data Cloud macht Datenhaltung zur strategischen Frage: wer die Stamm-Tabellen kontrolliert, kontrolliert den Agenten-Stack, der sie nutzt.
• AWS und Google haben separat eine Multi-Cloud-Deployment-Kooperation angekündigt, was Workloads zwischen den Hyperscalern technisch leichter portierbar macht, aber den Wettlauf um die Datenebene noch verschärft.
• Operative Folge für CIOs: Die Frage ist nicht mehr „in welche Cloud“, sondern „wo bleibt der Stamm, wo darf gerechnet werden, wer trägt das Cache-Risiko“.

Egress als versteckte Steuer auf jede Multi-Cloud-Idee

Wer in den letzten drei Jahren ernsthaft versucht hat, Workloads über zwei Hyperscaler zu spreizen, kennt den Reflex der CFO-Seite: Egress-Kosten. AWS, Azure und GCP verlangen pro Gigabyte ausgehendem Traffic Beträge, die in der Summe an einer 80-Terabyte-Pipeline pro Monat schnell fünfstellig werden. Diese Tarife sind kein Versehen, sie sind das, was Vendor-Lock-in in einer Bilanzposition aussieht. Daten, die einmal in einem Bucket liegen, kommen teuer wieder heraus.

Die Cross-cloud-Caching-Funktion, die Google auf der Next 2026 vorgestellt hat, greift genau hier an. Sie speichert Daten, die einmal über die Cloud-Grenze gezogen wurden, lokal im Lakehouse-Cache, sodass wiederkehrende Queries nicht mehr jedes Mal Egress auslösen. Für ein Reporting-Setup, das täglich denselben Datensatz aus einem S3-Bucket konsumiert, bedeutet das im Idealfall eine Größenordnung weniger ausgehenden Traffic. Die Architektur-Wahrheit dahinter: Caching ist nichts Neues, aber wenn ein Hyperscaler es als nativen Service über fremde Cloud-Grenzen anbietet, verschiebt das den ROI-Rechner für Cross-Cloud massiv.

Ein DACH-Beispiel macht die Größenordnung greifbar

Ein mittelgroßer Industrie-Konzern, der seine Maschinendaten in AWS S3 sammelt und über GCP BigQuery analysiert, fährt nach eigenen Angaben monatlich rund 12 TB Cross-Cloud-Egress. Bei aktuellen AWS-Tarifen ergibt das knapp 1.080 Euro pro Monat, allein für Datenbewegung. Mit einem Cache-Hit-Rate von 70 Prozent auf die wiederkehrenden Analytics-Queries sinkt der ausgehende Traffic auf etwa 3,6 TB, der Bill auf rund 330 Euro. Über das Jahr macht das 9.000 Euro Differenz, bei einem einzigen Datenpfad. Wer mehrere solcher Pipelines fährt, redet schnell über sechsstellige Effekte.

Vom Daten-Silo zum Borderless Lakehouse

Die zweite Verschiebung kommt aus dem Lakehouse selbst. Google nennt die neue Variante „borderless“, der Lakehouse-Layer kann Tabellen referenzieren, die physisch in S3 oder Azure Data Lake liegen, ohne dass die Daten in BigQuery hineinrepliziert werden müssen. Für Engineering-Teams heißt das: weniger ETL, weniger Sync-Jobs, weniger Stellen, an denen ein Schema-Drift den Bericht kaputtmacht. Für CIOs heißt das: die Frage, wo die Daten „hingehören“, lässt sich politisch und vertraglich neu beantworten, ohne dass jede Antwort sofort ein Migrationsprojekt auslöst.

Die Kehrseite: Wer den Lakehouse-Layer kontrolliert, kontrolliert die Abfrage-Logik. Google positioniert sich hier als neutraler Vermittler, was strategisch klug ist, das eigene Compute wird zur Standard-Abfrage-Engine über fremde Buckets. AWS und Azure haben vergleichbare Initiativen, sind aber jeweils stärker im eigenen Ökosystem verankert. Die Wahl, welcher Lakehouse-Layer in einer DACH-Enterprise zum De-facto-Standard wird, ist damit eine vendor-strategische Entscheidung mit langer Halbwertszeit.

„Multi-Cloud war bisher eine Compliance-Antwort. Mit den neuen Lakehouse- und Caching-Schichten wird daraus eine architektonische Option, aber die Wahl, wer die Datenebene führt, bleibt eine langfristige Lock-in-Entscheidung.“

Agenten-Stack: Wer die Daten kontrolliert, kontrolliert die Skills

Die Gemini Enterprise Agent Platform und die Agentic Data Cloud sind die strategischere Ansage. Google bündelt Agent-Registry, Skill-Registry, Tool-Registry und Governance in einem Layer, der explizit darauf ausgelegt ist, AWS-, Azure- und GCP-Workloads gemeinsam zu steuern. Damit setzt Google nicht auf „ihr migriert eure Apps zu uns“, sondern auf „wir werden der Steuerungs-Plane über eure bestehenden Apps“. Aus CIO-Sicht ist das attraktiv, weil es das Investment-Verhältnis verändert: Statt ein Workload-Migrations-Projekt zu finanzieren, bezahlt man ein abstrahiertes Steuerungs-Abo.

Allerdings verschiebt das das Risiko nur eine Schicht nach oben. Wer in zwei Jahren feststellt, dass die Agent-Registry und das Tool-Inventory bei Google liegen, wird mit „wir wechseln das Steuerungs-Plane“ denselben Lock-in-Effekt erleben, den Multi-Cloud eigentlich vermeiden sollte. Die einzige nachhaltige Antwort: offene Standards für Agent-Definitionen, Skill-Schemata und Tool-Manifeste durchsetzen, bevor proprietäre Formate Fakten schaffen.

Compliance landet auf der Cross-Cloud-Schicht

Was in der Architektur-Debatte oft untergeht: DSGVO, NIS2 und der EU AI Act schreiben keine Cloud-Provider vor, aber sie schreiben vor, wo Daten verarbeitet werden und wer sie sieht. Eine Cross-cloud-Caching-Schicht, die personenbezogene Daten in einem GCP-Cache hält, obwohl die Stammtabelle in einem deutschen AWS-Rechenzentrum liegt, ist datenschutzrechtlich nicht trivial. Die operative Frage ist: Welche Datenkategorie darf gecacht werden, wo? Und wie wird der Cache-Lifecycle dokumentiert, wenn die Aufsichtsbehörde nachfragt?

Die Vendor-Antwort wird „policy-driven Caching“ sein, also Regeln, die festlegen, welche Datenklassen welche Cloud-Grenzen überschreiten dürfen. In der Praxis bedeutet das: vor dem ersten produktiven Cross-Cloud-Pipeline-Aufbau muss ein Daten-Klassifikations-Schema stehen. Wer das auf später schiebt, baut sich einen Audit-Findung-Generator.

Drei Prüffragen vor dem nächsten Multi-Cloud-Schritt

1. Wo liegen die Stammdaten, und wo dürfen Kopien davon liegen? Caching klingt nach Performance-Frage, ist aber eine Compliance-Frage. Ohne Datenklassifikation kein Cross-Cloud-Cache.

2. Welche Abfrage-Engine wird der Standard? Lakehouse-Layer haben Halbwertszeiten von fünf bis zehn Jahren. Die Wahl, ob BigQuery, Athena, Synapse oder Snowflake der dominante Query-Pfad wird, ist eine vendor-strategische Entscheidung, nicht eine Tooling-Entscheidung.

3. Wer kontrolliert das Agenten-Steuerungs-Plane? Wenn die Agent-Registry und das Tool-Inventory bei einem Hyperscaler liegen, ist Multi-Cloud auf der Compute-Ebene gut, aber auf der Intelligenz-Ebene wieder zentralisiert. Open-Standard-Diskussionen jetzt führen, nicht in zwei Jahren.

Häufige Fragen