7 Min. Lesezeit

AWS und Google Cloud haben im April 2026 einen gemeinsamen Multicloud-Networking-Service in die Preview-Phase geschickt. Die Ankündigung auf der re:Invent positioniert die beiden Hyperscaler ungewöhnlich nah beieinander und zielt auf ein Problem, das viele DACH-Unternehmen seit Jahren kennen: komplexe Interconnects zwischen Clouds, die im Betrieb wehtun. Microsoft Azure soll Ende 2026 folgen. Stand: 14. April 2026.

Das Wichtigste in Kürze

• Preview-Status ab April 2026: Drei Regionen inklusive Frankfurt. Produktiveinsatz für Kern-Workloads verfrüht, Testing jetzt sinnvoll.
• Zielgruppe DACH: Unternehmen mit bestehenden AWS-Primär- und Google-Sekundär-Setups profitieren am schnellsten. Besonders bei Data-Lake-Architekturen mit BigQuery-Analytics auf S3-Datenbeständen.
• Azure kommt Ende 2026: Wer auf drei Clouds setzt, muss bis dahin warten. Bis Microsoft folgt, bleibt der Betrieb zweigleisig.
• CIO-Relevanz: Vendor-Lock-in-Risiko sinkt, aber nur auf Netzwerk-Ebene. Datenbank- und Workload-Portabilität bleibt ein separates Thema.
• Definition: Multicloud-Networking beschreibt die zentrale Steuerung privater Verbindungen zwischen mehreren Public Clouds über einen einheitlichen Control Plane, statt pro Cloud-Pair eigene Gateway-, BGP- und VPN-Konfigurationen zu pflegen.

Was AWS und Google konkret angekündigt haben

Konkret geht es um einen gemeinsamen Control Plane für private Verbindungen zwischen AWS- und Google-Cloud-VPCs. Der Dienst läuft zunächst in drei Regionen, darunter Frankfurt. Kunden können Subnetze über einen einheitlichen Workflow verbinden, ohne parallel Direct Connect und Cloud Interconnect zu managen.

Für Platform-Teams, die seit 2024 Multicloud-Setups unter Last betreiben, ist das eine relevante Verschiebung. Die Details trennen Marketing-Versprechen vom operativen Nutzen. Für 2026-Planungen lohnt der nüchterne Blick auf das, was heute schon funktioniert.

Die Kollaboration vereinfacht laut Ankündigung den Aufbau privater Verbindungen zwischen den beiden Clouds. Statt Direct Connect und Partner Interconnect separat zu konfigurieren, soll ein gemeinsamer Networking-Layer beide Seiten abstrahieren. Die Preview läuft zunächst in drei Regionen. Neben Frankfurt sind das nach Berichten von CIO Dive zwei US-Regionen.

Technisch liegt der Wert in der Reduktion des Konfigurations-Overheads. Heute mussten Platform-Teams BGP-Sessions, AS-Pfade und VPN-Tunnel auf beiden Seiten separat verwalten. Der neue Service fasst das in einer gemeinsamen Abstraktion zusammen. Für die erste Charge gilt: Support für Layer-3-Connectivity, aber noch keine automatische Policy-Synchronisation zwischen AWS Security Groups und Google Cloud Firewall Rules.

Wichtig für die Einordnung: Die Ankündigung reiht sich in eine Serie von Bewegungen ein, die AWS und Google Cloud seit Ende 2025 im deutschen Markt machen. Der Frankfurter Interconnect aus dem März war der technische Vorläufer. Die aktuelle Preview bringt den Steuerungs-Layer dazu. Wer die Infrastruktur-Ankündigungen der letzten sechs Monate chronologisch liest, sieht eine klare Stoßrichtung: beide Hyperscaler wollen Multicloud nicht mehr als Notlösung verstanden wissen, sondern als Standard.

Der Info-Tech Research Group zufolge hält AWS global rund 32 Prozent Marktanteil, Azure liegt bei 23 Prozent, Google Cloud bei 11 Prozent. Die Kollaboration macht gerade deshalb Sinn: AWS muss Google keinen Markt abtreten, Google gewinnt dafür Zugang zu AWS-nativen Bestands-Deployments. Für DACH-Unternehmen ist das Rechenzentrum-Ökosystem Frankfurt damit der unmittelbare Nutznießer.

Was davon heute real ist und was Marketing bleibt

Drei Dinge sollte man sich dazu klarmachen, bevor man entscheidet. Erstens: Preview heißt Preview. Es gibt keine SLA, die Region-Verfügbarkeit kann sich ändern, Kundenzahlen sind vertraulich. Wer auf diesen Dienst für produktive Multicloud-Datenpipelines setzt, übernimmt Risiko, das sich operativ nur schwer absichern lässt.

Zweitens: Die Abstraktion betrifft das Netzwerk, nicht die Identität. IAM-Policies müssen weiterhin in beiden Clouds separat modelliert werden. Wer Single-Sign-On und Cross-Cloud-Service-Accounts sauber aufsetzen will, landet schnell wieder bei Terraform oder dedizierten Identity-Federation-Layern. Die Ankündigung ändert daran nichts. Sie reduziert den Overhead auf Layer 3 und darunter, nicht auf Layer 7.

Drittens: Azure fehlt. Die offizielle Zeitlinie nennt Ende 2026 für die Microsoft-Integration. Bis dahin bleibt der Three-Cloud-Fall ein getrennter Prozess. Wer Workloads zwischen AWS, Azure und Google Cloud spannt, muss weiter zweigleisig planen. Für Unternehmen mit Azure-lastigen Bestandsworkloads (Office 365, Dynamics, viele SaaS-Integrationen) bedeutet das: der Netzwerk-Vorteil der neuen Preview bleibt bis zur Azure-Einbindung theoretisch.

Operativ heißt das für die meisten DACH-IT-Organisationen: Die neue Preview ist interessant als Signal und als Experimentierfeld, nicht als Produktionsbaustein. Wer 2026 eine Zwei-Cloud-Strategie mit AWS und Google Cloud plant, kann die Abstraktion in die Architektur-Überlegung einbeziehen. Wer Azure im Mix hat, plant weiter mit etablierten Drittanbietern wie Megaport oder Equinix Fabric.

„Die Ankündigung auf der re:Invent positioniert die beiden Hyperscaler ungewöhnlich nah beieinander und zielt auf ein Problem, das viele DACH-Unternehmen seit Jahren kennen: komplexe Interconnects zwischen Clouds, die im Betrieb wehtun.“

Was Platform-Teams in DACH jetzt prüfen sollten

Für die meisten IT-Organisationen im deutschsprachigen Raum lohnen drei konkrete Schritte. Der erste ist eine Bestandsaufnahme: Welche Workloads laufen heute über Multicloud-Verbindungen und welcher Konfigurationsaufwand liegt darauf? Wenn das unter 10 Prozent der Plattform-Arbeitszeit kostet, ist die Preview keine Priorität. Liegt der Aufwand höher, lohnt ein Test-Setup in Frankfurt.

Der zweite Schritt ist ein Vergleich mit bestehenden Alternativen. Megaport, Equinix Fabric und Console Connect bieten seit Jahren Cross-Cloud-Interconnects. Der Unterschied zur neuen AWS-Google-Kollaboration liegt im Preismodell und im Management-Layer, nicht in grundlegend neuer Technik. Der DACH-Vergleich der drei Hyperscaler zeigt die wichtigsten Unterschiede bei Netzwerk-Features und Pricing.

Der dritte Schritt betrifft die Workload-Strategie. Ein vereinfachter Multicloud-Layer senkt die operativen Kosten für verteilte Architekturen. Er macht Cloud Repatriation aber nicht überflüssig. Wer 2026 die Frage stellt, welche Workloads zurück in eigene Rechenzentren gehören, findet in der Analyse zum Cloud Repatriation TCO-Modell einen strukturierten Rahmen dafür.

Ein viertes Thema taucht in Projekt-Gesprächen immer öfter auf: Compliance. Wer nach NIS2 oder DORA bewertet wird, muss die Netzwerk-Abstraktion mit den Wirtschaftsprüfern durchsprechen. Die Zuständigkeit für Incident-Meldungen liegt weiterhin bei beiden Cloud-Anbietern einzeln. Ein gemeinsamer Control Plane verändert Meldewege nicht, sondern fügt lediglich einen weiteren Abstraktions-Layer hinzu, den IT-Governance mitbewerten muss.

Vergleich mit bestehenden Multicloud-Interconnect-Angeboten

Die Ankündigung kommt nicht ins Vakuum. Seit mindestens fünf Jahren existiert ein Markt für Cross-Cloud-Interconnects, der sich in drei Kategorien aufteilen lässt. Netzwerk-Broker wie Megaport und Equinix Fabric bieten virtuelle Direktverbindungen zwischen allen großen Hyperscalern. Sie sitzen physisch in den Carrier-Hotels und verkaufen Layer-2-Connectivity als Service. Colocation-Anbieter wie NTT oder Interxion erweitern das um physische Cage-to-Cage-Verbindungen. Cloud-native SD-WAN-Dienste wie Cisco Multicloud Defense oder Aviatrix bauen eine Software-Layer darüber und bringen eigene Policy-Engines mit.

Die AWS-Google-Kollaboration fällt in eine vierte Kategorie: Hyperscaler-native Kooperation. Der Unterschied liegt im Integrations-Tiefe und im Preis. Ein Megaport-Setup kostet für ein typisches DACH-Unternehmen mit zwei Cloud-Regionen rund 2.000 bis 4.000 Euro pro Monat, je nach Bandbreite und Redundanz. Die AWS-Google-Kollaboration wird vermutlich darunter liegen, weil keine Drittpartei mitverdient. Genaue Zahlen fehlen bisher.

Für Unternehmen mit vorhandenen Megaport- oder Equinix-Verträgen ändert sich kurzfristig nichts. Die Verträge laufen weiter, die Funktionalität bleibt breiter. Wer aber 2026 eine neue Multicloud-Strategie aufsetzt und nur AWS plus Google Cloud im Plan hat, sollte die native Option mitbewerten, sobald GA erreicht ist.

Was als Nächstes realistisch ist

Die nächsten drei bis sechs Monate werden zeigen, ob die Preview technisch trägt. Entscheidend sind drei Beobachtungspunkte. Stabilität der Region-Verfügbarkeit: Fällt eine der drei Startregionen aus, sinkt das Vertrauen in die Gesamtarchitektur deutlich. Erweiterung auf weitere Frankfurt-Dependencies: Kommt eu-central-2 (Zürich) dazu oder bleibt es bei eu-central-1? Die Antwort entscheidet, ob schweizerische Kunden mit Datenresidenz-Anforderungen mitspielen können. Klarheit beim Azure-Timing: Wenn die Ende-2026-Frist für Microsoft gehalten wird, ist das Netzwerk-Abstraction-Trio realistisch. Wenn nicht, bleibt die Preview ein AWS-Google-Werkzeug mit begrenztem Einsatzradius.

Für deutsche Mittelständler mit einer AWS-dominanten Cloud-Strategie bietet sich die Preview als Lernfeld an. Ein Test-VPC in Frankfurt mit einer Google-Cloud-Gegenseite, verbunden über den neuen Service, kostet keine nennenswerten Budgets und zeigt im Betrieb, wie viel Operations-Overhead die Abstraktion tatsächlich spart. Die Ergebnisse fließen in die Architektur-Entscheidungen für 2027, in dem dann auch Azure dazugehört.

Risiken und offene Fragen

So erfreulich die Vereinfachung ist, ein paar Risiken bleiben. Das erste betrifft den Vendor-Lock-in auf Netzwerk-Layer-Ebene. Wer seine Multicloud-Architektur auf einen von beiden Hyperscalern orchestrierten Service aufbaut, hat die Abhängigkeit zwar reduziert, aber nicht aufgelöst. Die Abstraktion funktioniert nur innerhalb der Grenzen, die AWS und Google gemeinsam definieren. Features, die nur in einer der beiden Clouds existieren, bleiben getrennt.

Das zweite Risiko liegt im Support-Modell. Tritt ein Problem auf, stellt sich die klassische Multi-Vendor-Frage: Welcher Support ist zuständig? Die Ankündigung nennt ein gemeinsames Eskalations-Modell. Wie das in der Praxis bei realen P1-Incidents funktioniert, ist die eigentliche Belastungsprobe. Erfahrungen aus vergleichbaren Kooperationen zeigen: Gemeinsame Support-Prozesse brauchen 6 bis 12 Monate, bis sie wirklich reibungslos laufen.

Das dritte offene Thema ist der Roadmap-Blick. Kommt in 2027 eine IAM-Integration? Werden Policy-Synchronisation und Network-Policy-Federation auf Layer 7 erweitert? Ohne diese Ausbauten bleibt der Service ein Netzwerk-Tool, kein Multicloud-Management-Plattform. Das ist nicht negativ gemeint – es ist einfach eine klare Positionierung, die IT-Architekten kennen müssen, bevor sie darauf aufbauen.

Architektur-Empfehlung für 2026-Projekte

Wer gerade einen Cloud-Neubau plant oder eine bestehende Architektur refaktorisiert, kann drei Leitlinien anwenden. Erstens: Netzwerk-Layer auf offene Standards setzen. Die Abstraktionen der Hyperscaler sind komfortabel, aber eine Terraform- oder Crossplane-Basis bleibt die stabilere Fundierung. Zweitens: Identity-Layer von Netzwerk trennen. Wer Single-Sign-On über dedizierte Provider wie Okta, Entra ID oder Keycloak löst, bleibt bei Cloud-Providerwechseln flexibler. Drittens: Kosten-Modelle modellieren, bevor sie entstehen. Eine vereinfachte Multicloud-Verbindung senkt Operations-Kosten, kann aber Datentransfer-Kosten erhöhen, wenn sie zu großzügig genutzt wird. Ein sauber durchgerechnetes TCO-Modell für 24 Monate Laufzeit liefert die belastbarere Entscheidungsgrundlage als jede Preis-Ankündigung der Hyperscaler.

Der vierte Punkt betrifft das Monitoring. Wer zwei Clouds über einen abstrahierten Control Plane verbindet, muss Observability über beide Seiten zusammenführen. Prometheus-basierte Setups mit Grafana als einheitlicher Frontend-Schicht haben sich bei DACH-Mittelständlern als praxistauglich erwiesen. Eine dedizierte Multicloud-Observability-Plattform wie Datadog oder Dynatrace lohnt sich erst ab einer Workload-Komplexität, die die meisten Mittelständler ohnehin nicht erreichen.

Häufige Fragen

Wann ist die AWS-Google-Multicloud-Kollaboration produktiv nutzbar?

Aktuell läuft die Preview, ein GA-Termin wurde nicht kommuniziert. Für produktive Kern-Workloads ist das Warten auf GA ratsam. Für Test-Umgebungen, Data-Lake-Replikation oder unkritische Workflows lässt sich der Dienst jetzt ausprobieren.

Ersetzt der Dienst Megaport oder Equinix Fabric?

Kurzfristig nein. Megaport und Equinix bieten Cross-Cloud-Interconnects über mehr Regionen, unterstützen alle drei Hyperscaler und bringen eigene Private-Network-Features mit. Die AWS-Google-Kollaboration ist für Zwei-Cloud-Setups zwischen genau diesen beiden Anbietern günstiger und direkter integriert.

Was bedeutet das für die Compliance-Bewertung nach DORA und NIS2?

Die Netzwerk-Abstraktion ändert nichts an der Verantwortung der Data Controller. Beide Clouds bleiben separate Verarbeiter. Die regulatorische Bewertung (Datenstandort, Logging, Incident-Meldepflicht) muss weiterhin pro Cloud einzeln erfolgen.

Kommt die Kollaboration auch nach Frankfurt Region 2 (eu-central-2)?

Die initialen drei Regionen umfassen laut Ankündigung Frankfurt (eu-central-1). Eine Ausweitung auf die Zürich-Region (eu-central-2) wurde nicht offiziell benannt. Für schweizerische Kunden mit Datenresidenz-Anforderungen ist das ein wichtiger Prüfpunkt.

Was kostet der Dienst in der Preview-Phase?

Offizielle Preismodelle wurden mit der Ankündigung nicht veröffentlicht. Preview-Teilnahme läuft über Account-Registrierung. Kostenaspekte werden nach Enrollment kommuniziert. Mit GA-Launch ist ein dediziertes Pricing-Modell zu erwarten, das sich an bestehenden Direct-Connect- und Cloud-Interconnect-Tarifen orientieren dürfte.

Quelle Titelbild: Pexels / Brett Sayles