5 Min. Lesezeit

Am 24. April hat Google Cloud beim Wrap-Up zu Cloud Next 2026 Cross-Cloud Caching als neues Feature angekündigt. Die Idee: AWS- und Azure-Daten werden beim ersten Read in den Google-Cloud-Storage gespiegelt und liegen ab dann für wiederholte Querys lokal. Egress-Gebühren auf der Zweit-, Dritt- und Tausendsten-Abfrage entfallen. Für DACH-Multi-Cloud-Architekten ist das auf dem Papier ein hartes Cost-Argument. Praktisch öffnet es eine Frage, die selten so direkt auf dem Tisch lag: Wie viel Datenhoheit ist eine Egress-Rechnung wert?

Das Wichtigste in Kürze

• Was ist neu: Google Cloud Cross-Cloud Caching lädt AWS-S3- und Azure-Blob-Daten beim ersten Read in den GCP-Storage und cacht sie für Folge-Querys.
• Warum jetzt relevant: Egress aus AWS und Azure bleibt der teuerste Posten in Multi-Cloud-Setups. Wer wiederholt aus Drittclouds liest, zahlt jedes Mal.
• Was bleibt offen: Daten landen physisch im GCP-Storage. DACH-Teams mit Datenhoheits-Auflagen müssen die Frage beantworten, bevor das Feature scharf gestellt wird.

Die Ankündigung kam im Cloud-Next-2026-Wrap-Up vom 24. April (cloud.google.com). Cross-Cloud Caching reiht sich in die Strategie ein, mit der Google die Multi-Cloud-Realität adressiert, die viele DACH-Unternehmen seit Jahren leben aber selten elegant verwalten. Wir hatten den größeren Roadmap-Block schon eingeordnet: Was DACH-Architekten aus der Cloud-Next-2026-Roadmap liefern müssen. Cross-Cloud Caching ist der praktische Hebel daraus.

Wie das Feature funktioniert

Das Prinzip ist Caching, wie es Frontend-Developer aus dem CDN-Kontext kennen, nur eine Schicht tiefer und über Cloud-Grenzen hinweg. Ein Job in BigQuery oder Vertex AI liest einen Datensatz aus AWS S3. Beim ersten Read fließt der Traffic durch die übliche Pipe und kostet Egress. Cross-Cloud Caching kopiert das Objekt parallel in den Google-Cloud-Storage. Folge-Queries gegen denselben Datensatz lesen aus dem lokalen Cache. Aus AWS-Sicht ist nach dem ersten Read Funkstille.

Technisch ist das eine Kombination aus Storage-Mirror und Smart-Routing: Cache-Lookup vor Cross-Cloud-Read, TTL-basierte Invalidierung und eine Kontrollebene die entscheidet, was sich zu cachen lohnt. Wer schon einmal mit Edge-Caches und Stale-While-Revalidate gearbeitet hat, kennt die Pattern. Neu ist, dass Google das auf Storage-Layer anbietet und mit den eigenen Analytics-Diensten verzahnt.

Warum DACH-Teams genau hinsehen

Egress ist seit Jahren der unangenehmste Posten auf der Cloud-Rechnung. AWS und Azure verlangen pro GB, das die Provider-Grenze verlässt, im Bereich von rund 8 bis 9 Cent pro GB in den ersten Tiers (Quelle: AWS Data-Transfer-Pricing, Azure Bandwidth-Pricing, Stand April 2026). Bei Workloads die wiederholt mehrere TB aus Drittclouds ziehen, summiert sich das schnell auf Beträge, die einen Architektur-Refactor rechtfertigen. Cross-Cloud Caching greift genau da ein.

Für DACH-Architekten ist das interessant, weil viele produktive Setups genau diesen Lese-Pattern haben: Datenbestand liegt historisch in AWS oder Azure, aber das Analytics-Team arbeitet in BigQuery. Ohne Cache wird derselbe Datensatz Monat für Monat aus AWS gezogen. Mit Cache fällt der Traffic einmal an, dann nie mehr. Wenn der Kostenposten halbwegs stabil ist, ist die Rechnung schnell gemacht. Eine vergleichbare Logik haben wir letzte Woche im Praxis-Check zu CloudFormation vs Terraform für Multi-Cloud diskutiert: Tooling-Entscheidungen drehen sich oft um genau diese wiederkehrenden Operations-Kosten.

„Die Idee: AWS- und Azure-Daten werden beim ersten Read in den Google-Cloud-Storage gespiegelt und liegen ab dann für wiederholte Querys lokal.“

Was bricht, was trägt

Die ehrliche Diskussion ist nicht „Feature ja oder nein“, sondern „für welche Daten und unter welchen Bedingungen“. Personenbezogene Daten unter DSGVO-Vorgaben, regulierte Datenklassen aus dem KRITIS-Umfeld oder Bestände mit ausdrücklicher Geo-Restriktion sind keine Caching-Kandidaten. Telemetrie-, Click-Stream- oder Trainings-Datensets ohne Personenbezug sind es eher. Der Trennstrich gehört in die Architektur-Entscheidung dokumentiert, nicht in das jährliche FinOps-Review nachgereicht.

Was DACH-Architekten in den nächsten 90 Tagen tun sollten

Erstens: Ein sauberer Egress-Report aus AWS und Azure, gegliedert nach Datensatz und Ziel-Cloud. Wer den nicht hat, kann den Hebel nicht beziffern. Zweitens: Eine Klassifizierung der Datenbestände nach Caching-Eignung, mit Compliance-Sign-Off. Drittens: Ein Pilot für einen einzelnen Read-Heavy-Datensatz, am besten Telemetrie oder Trainings-Daten. So entsteht eine reale Zahl statt einer Kalkulation auf Vendor-Folien.

Strategisch verdient die Frage nach dem Lock-in-Trade-off einen ehrlichen Workshop: Cross-Cloud Caching reduziert den Egress-Schmerz, schafft aber neue Abhängigkeit von Googles Storage-Layer. Wer schon einen Multi-Cloud-Exit-Plan in der Schublade hat, sollte das Feature in dem Plan unterbringen, bevor es leise produktiv geht.

Häufige Fragen

Was kostet Cross-Cloud Caching?

Google Cloud hat beim Wrap-Up keine konkreten Listenpreise veröffentlicht. Erwartet wird eine Kombination aus Storage-Kosten für den Cache und reduzierten Egress-Aufschlägen. Erste Beispielrechnungen lohnen sich erst nach Veröffentlichung der Preisliste.

Wer ist die Zielgruppe?

Multi-Cloud-Setups mit produktiven Lese-Pipelines zwischen AWS oder Azure und Google-Cloud-Analytics. Vor allem BigQuery- und Vertex-AI-Anwender, die wiederholt aus Drittclouds lesen.

Was bedeutet das für die Datenhoheit?

Daten werden physisch in den Google-Cloud-Storage gespiegelt. Wer Geo-Restriktionen oder regulatorische Vorgaben für den Speicherort hat, muss vor Aktivierung prüfen, in welche GCP-Region der Cache liegt und ob der Mirror compliancegerecht ist.

Foto: Lovelano / Wikimedia Commons (CC BY 4.0)