7 Min. Lesezeit · Stand: 21.04.2026

Nach fünf Monaten Preview sind Partner Cross-Cloud Interconnect für AWS mit VPC Network Peering in Google Cloud seit dem 16.04.2026 Generally Available. Für Enterprise-Architekten ist damit der erste nativ von zwei Hyperscalern gemeinsam gebaute Multi-Cloud-Pfad produktiv nutzbar, ohne dass ein Drittanbieter wie Megaport oder Equinix in der Kette steht. Das ändert nicht die Grundsatzfrage, warum Unternehmen Multi-Cloud betreiben. Es ändert die Execution-Economics der nächsten zwei Quartale, weil Datentransfer, Latenz und Sovereignty-Pfade jetzt anders kalkuliert werden können als noch im Q4 2025.

VerwandtFinOps im Maturity-Check 2026  /  Platform Engineering 2026 mit Backstage und Golden Paths

Was GA ist, was Preview bleibt und wie Azure im Hintergrund vorbereitet wird

Was ist Partner Cross-Cloud Interconnect? Partner Cross-Cloud Interconnect ist ein von Google Cloud und AWS gemeinsam gebauter Netzwerk-Pfad, bei dem ein AWS Direct Connect Gateway über einen zertifizierten Partner-Router direkt mit einem GCP-VPC verbunden wird. Der Traffic läuft nicht über das öffentliche Internet und benötigt keinen eigenen Colocation-Vertrag bei einem Exchange-Betreiber. Seit dem 16.04.2026 ist die Variante mit VPC Network Peering in Google Cloud GA, die Integration mit Network Connectivity Center bleibt in Preview.

Die Ankündigung vom 01.12.2025 war ein Signal. Die Freigabe am 16.04.2026 ist die operative Realität. Was Google Cloud in den Release Notes konkret auf GA hebt, ist Partner Cross-Cloud Interconnect für AWS mit VPC Network Peering. Das heißt in der Praxis: Ein AWS Direct Connect Gateway im eigenen Konto kann nun über einen von Google zertifizierten Partner-Netzwerk-Knoten direkt an ein GCP-VPC angeschlossen werden, ohne dass der Traffic den öffentlichen Internet-Pfad berührt oder ein eigener Colocation-Vertrag bei einem Exchange-Betreiber nötig ist.

Was bewusst noch nicht GA ist, ist die Integration mit Google Cloud Network Connectivity Center. NCC ist der Dienst, mit dem Google eine Hub-and-Spoke-Topologie über mehrere Clouds, Standorte und VPC-Grenzen hinweg abbildet. Die NCC-Spoke-Variante für Partner Cross-Cloud Interconnect bleibt in Preview. Für Teams, die eine zentrale Multi-Cloud-Routing-Ebene betreiben wollen, heißt das: produktiver Einsatz ist frühestens im Q3 2026 realistisch, wahrscheinlicher mit der Herbst-GA-Welle.

Die dritte Ebene ist die offene Netzwerk-Interoperabilitäts-Spezifikation. AWS und Google haben im Dezember 2025 gemeinsam eine Architektur vorgelegt, die nicht als proprietäres Interconnect-Protokoll gedacht ist, sondern als Blueprint. Microsoft Azure wurde explizit als Beitritts-Kandidat für 2026 genannt. Konkrete Roadmap-Daten hat Microsoft bislang nicht veröffentlicht. Für Architektur-Teams heißt das: Die Zwei-Cloud-Option ist jetzt produktiv, die Drei-Cloud-Option bleibt strategische Planung.

Warum Multi-Cloud Networking jetzt anders kalkuliert wird

Der klassische Grund gegen produktive Multi-Cloud-Setups waren nicht die Architektur-Entscheidungen, sondern die Datentransfer-Preise zwischen den Hyperscalern. AWS Egress nach Google, Google Egress nach AWS: Je nach Region bewegt sich das zwischen 0,08 und 0,12 USD pro GB, bei Enterprise-Volumen im Petabyte-Bereich pro Monat läppert sich das in signifikante Posten. Partner Cross-Cloud Interconnect ändert die Abrechnung strukturell. Der Direct-Connect-basierte Traffic läuft zu reduzierten Egress-Raten, typischerweise zwischen 0,02 und 0,05 USD pro GB je nach Region und Commit-Volumen. Für einen ernsthaften Daten-Workload zwischen AWS-Analytics und Google-BigQuery kann das eine Halbierung der Netzwerk-OpEx bedeuten.

Latenz ist der zweite Hebel, der sich verschiebt. Ein AWS-zu-GCP-Pfad über öffentliches Internet liegt je nach Region bei 12 bis 40 Millisekunden Round-Trip. Mit Partner Cross-Cloud Interconnect sinkt das auf 2 bis 8 Millisekunden, weil die Pakete direkt zwischen den Interconnect-Routern laufen. Für latenz-sensitive Kopplungen, beispielsweise zwischen AWS-basierten Transaktionssystemen und Google-basierten Analytics-Pipelines, öffnet das die Tür zu Architekturen, die vorher operativ schwierig waren.

Der dritte Punkt ist Sovereignty. Deutsche und europäische Enterprise-Kunden fahren Multi-Cloud oft nicht aus Architektur-Gründen, sondern aus Vertrags- und Compliance-Gründen. BaFin-regulierte Institute brauchen nachweisbare Exit-Pfade, der EU Data Act verlangt dokumentierte Portabilität. Partner Cross-Cloud Interconnect vereinfacht diese Dokumentation, weil der Netzwerk-Pfad zwischen den Clouds kontraktuell klar definiert ist und in der Audit-Trail beider Hyperscaler erscheint. Die reine Existenz eines nativen Interconnects zwischen AWS und Google ist damit ein Argument in Compliance-Gesprächen, das vorher einer Drittanbieter-Lösung gehörte.

Fünf Entscheidungen, die Enterprise-Architekten diese Woche treffen sollten

Die Ankündigung ist nicht trivial zu bewerten. Nicht jede Enterprise-Architektur profitiert sofort. Nicht jede Architektur-Abteilung hat die Kapazität, eine Re-Evaluation anzusetzen. Aus Gesprächen mit DACH-Architekten in den letzten zwei Wochen kristallisieren sich fünf konkrete Entscheidungsmomente heraus, bei denen Partner Cross-Cloud Interconnect das Rechenmodell verändert.

Die erste Entscheidung betrifft bestehende Multi-Cloud-Setups mit Drittanbieter-Pfad. Wer heute produktiv über Megaport, Equinix Fabric oder PCCW Console Connect zwischen AWS und GCP fährt, sollte im zweiten Quartal einen technischen Kostenvergleich ansetzen. Der Drittanbieter-Layer bleibt aus organisatorischen Gründen (bestehende Verträge, etablierte Support-Prozesse) oft sinnvoll, aber die Default-Annahme dreht sich. Bei Neuinstallationen ist der native Pfad zur Default-Option geworden. Für Architektur-Boards heißt das konkret: Jedes neue Multi-Cloud-Projekt startet mit der Frage, ob Partner Cross-Cloud Interconnect die Anforderung erfüllt. Erst danach kommt die Drittanbieter-Option ins Spiel als ergänzende oder ersetzende Variante, je nach regulatorischem und operativem Kontext des Projekts.

Die zweite Entscheidung betrifft geplante Data-Analytics-Migrationen. Teams, die gerade einen Wechsel von AWS Redshift zu Google BigQuery planen oder umgekehrt, können die Netzwerk-Komponente jetzt mit belastbaren Zahlen kalkulieren. Die Cost-Modelle in den Business Cases, die im Q4 2025 noch mit konservativen Egress-Annahmen arbeiten mussten, bekommen eine neue Baseline. Für die Freigabe-Entscheidung in zwei oder drei Wochen kann das die Kapitalrendite entscheidend verbessern. Besonders relevant wird das, wenn das Migrations-Team den Netzwerk-Posten bisher als fixe Reibung betrachtet hat. Sobald die Zahl beweglich wird, rücken Szenarien nach vorne, die vorher aus Egress-Gründen auf der langen Bank lagen.

„Der interessante Teil ist nicht die Reduktion der Egress-Kosten, sondern das, was danach möglich wird. Wenn Cross-Cloud-Traffic preislich nicht mehr wehtut, werden Architekturen machbar, die man vorher aus guten Gründen vermieden hat.“ Lee Sustar, Forrester, sinngemäß im Kontext der Kyndryl-Pressekonferenz, April 2026

Die dritte Entscheidung betrifft Disaster-Recovery-Topologien. Cross-Cloud-DR war bis 2025 eine der teuersten Varianten, weil der Recovery-Pfad typischerweise über öffentlichen Egress lief. Mit dem nativen Interconnect wird ein aktiver-aktiver Aufbau zwischen einer AWS-Region und einer Google-Region rechnerisch realistischer. Teams mit bestehenden Single-Cloud-DR-Setups sollten mindestens ein Architektur-Sketch anfertigen, wie Cross-Cloud-DR unter den neuen Kosten-Annahmen aussehen würde. Das Ergebnis gehört in die nächste Risikobewertung.

Die vierte Entscheidung betrifft KI- und ML-Workloads. Google Cloud hat in den letzten Quartalen auf TPU v6 und spezialisierte Inference-Hardware gesetzt, AWS auf Trainium2 und eigene Bedrock-Integrationen. Für Teams, die in beiden Stacks arbeiten, ist die Netzwerk-Frage nicht trivial: Modelle trainieren auf GCP, Inference läuft auf AWS-Edge. Der native Interconnect senkt die Datenbewegungs-Kosten so weit, dass solche Split-Architekturen aus der Machbarkeits-Zone in die Default-Zone rücken. Für ML-Plattform-Teams ist das die stärkste Änderung der letzten zwölf Monate, weil der Split zwischen Trainings-Stack und Inference-Stack vorher an der Netzwerk-Abrechnung scheiterte und nicht an der Architektur-Idee selbst.

Die fünfte Entscheidung betrifft die Governance-Seite. Cross-Cloud-Konnektivität war in vielen deutschen Enterprise-Kontexten der Punkt, an dem Governance und Netzwerk-Sicherheit gemeinsam Nein sagten, weil der Traffic-Flow zwischen Cloud-Domains schlecht dokumentierbar war. Mit einem nativen Pfad, der in beiden Hyperscaler-Konsolen auftaucht, sinkt der Dokumentationsaufwand spürbar. Wer eine Multi-Cloud-Strategie schon als Policy niedergeschrieben hat, sollte die Governance-Passagen im Mai aktualisieren. Für die interne Revision heißt das: Ein Multi-Cloud-Pfad, der in beiden Audit-Trails erscheint, ist prüfbar, ein über Dritt-Anbieter geführter Pfad braucht Zusatz-Evidenz. Diese Unterscheidung hatte im Governance-Gespräch bisher wenig Gewicht, weil es keine Alternative gab. Jetzt gibt es eine.

Parallel zu diesen fünf Entscheidungen bleibt eine sechste Überlegung, die weniger operativ und mehr strategisch ist: Wie verändert sich die Verhandlungsposition gegenüber den Hyperscalern, wenn der Wechsel zwischen AWS und GCP technisch einfacher wird? Enterprise-Einkäufer, die ihre Cloud-Kontrakte in den nächsten zwölf Monaten neu verhandeln, bekommen ein zusätzliches Argument in den Preisgesprächen, weil die Exit-Kosten messbar sinken. Das ist kein Argument, das am ersten Tag nach GA greift, aber es wird in der nächsten Vertrags-Runde sichtbar.

Was all diese Entscheidungen gemeinsam haben: Sie sind keine Ein-Sprint-Themen. Eine Re-Kalkulation von Egress-Kosten über zwei Cloud-Accounts hinweg dauert typischerweise zwei bis drei Wochen, weil die Telemetrie aus beiden Seiten zusammengeführt werden muss. Eine DR-Neubewertung kann ein ganzes Quartal kosten. Die Wette, die AWS und Google mit der GA am 16. April eingehen, ist nicht die Adoption in vier Wochen, sondern die Verschiebung der Default-Annahmen in zwei bis drei Quartalen. Für Architektur-Teams, die planvoll arbeiten, ist jetzt der richtige Moment, die eigenen Annahmen zu prüfen. Für Teams, die reaktiv fahren, wird der Druck von Finanz- und Compliance-Seite spätestens im Herbst kommen.

Häufige Fragen

Was genau ist am 16. April 2026 GA geworden?

Partner Cross-Cloud Interconnect für AWS mit VPC Network Peering in Google Cloud. Das ist der Pfad über einen zertifizierten Partner-Router von einem AWS Direct Connect Gateway zu einem GCP-VPC. Die Integration mit Google Network Connectivity Center (NCC) als Spoke bleibt in Preview. Für Zwei-Cloud-Szenarien AWS-GCP ist die GA produktiv nutzbar. Für Hub-and-Spoke über mehrere Clouds plant man frühestens Q3 2026.

Welche Kostenreduktion ist realistisch?

Für reinen Datentransfer zwischen AWS und GCP typischerweise eine Halbierung der Egress-Kosten, je nach Region und Commit-Volumen. Öffentlicher Internet-Egress liegt zwischen 0,08 und 0,12 USD pro GB, Direct-Connect-Egress reduziert auf 0,02 bis 0,05 USD pro GB. Die reale Einsparung hängt vom Traffic-Muster ab. Bei bursty Analytics-Lasten ist der Hebel größer, bei kontinuierlichen Streaming-Verbindungen kleiner.

Bleibt Megaport oder Equinix als Drittanbieter relevant?

Für Multi-Cloud-Setups, die mehr als AWS und GCP abdecken müssen, ja. Für reine AWS-GCP-Pfade wird der native Interconnect bei Neuinstallationen zur Default-Option. Bestehende Megaport- oder Equinix-Verträge mit laufender Support-Integration bleiben oft sinnvoll, weil der Wechsel operative Arbeit erzeugt. Die Kostenvergleichs-Rechnung sollte man aber neu aufsetzen.

Wann folgt Microsoft Azure?

Microsoft wurde in der gemeinsamen AWS-Google-Ankündigung vom 1. Dezember 2025 explizit als Beitrittskandidat zur offenen Netzwerk-Interoperabilitäts-Spezifikation für 2026 genannt. Konkrete Roadmap-Daten hat Microsoft bislang nicht kommuniziert. Für Drei-Cloud-Architekturen mit nativem Inter-Hyperscaler-Pfad ist die strategische Planung das richtige Format, nicht die produktive Implementierung.

Was ändert sich für DACH-Compliance-Teams konkret?

Der Netzwerk-Pfad zwischen AWS und GCP ist jetzt in beiden Hyperscaler-Audit-Logs sauber dokumentierbar, ohne dass ein Dritt-Anbieter-Vertrag separat in die Evidenz-Sammlung muss. Für BaFin-Audits, DORA-Resilienz-Nachweise oder EU-Data-Act-Portabilitätsanforderungen vereinfacht das die Nachweisführung. Wer eine Multi-Cloud-Policy bereits schriftlich verfasst hat, sollte die Netzwerk-Passagen im Mai aktualisieren.

Mehr aus dem MBF Media Netzwerk

Quelle Titelbild: Pexels / Brett Sayles (px:4330787)