6 Min. Lesezeit

Am 1. Dezember 2025 haben AWS und Google Cloud etwas gemacht, das es noch nie gab: ein gemeinsam entwickeltes Netzwerkprodukt vorgestellt. Private, MACsec-verschlüsselte Verbindungen zwischen beiden Clouds, provisioniert per API in Minuten statt in Wochen über Drittanbieter. Frankfurt ist eine der fünf Launch-Regionen. Für Multi-Cloud-Architekturen in DACH ist das ein Wendepunkt.

Das Wichtigste in Kürze

• 🔗 AWS Interconnect (multicloud) und Google Cross-Cloud Interconnect verbinden beide Clouds erstmals nativ (AWS/Google, 01.12.2025).
• 🇩🇪 Frankfurt (eu-central-1 / europe-west3) ist eine der fünf Launch-Regionen im Preview (AWS Docs).
• ⚡ Provisionierung in Minuten per API. Bisher dauerte der Aufbau privater Cloud-Verbindungen Wochen bis Monate (InfoQ).
• 🔒 Verschlüsselung per MACsec (IEEE 802.1AE) auf der physischen Leitung. Kein Traffic über das öffentliche Internet (AWS).
• 📊 Weltweit nutzen 89 Prozent der Unternehmen mehrere Cloud-Anbieter (Flexera State of the Cloud, 2024).

Was AWS und Google Cloud gebaut haben

Die Ankündigung fiel auf den 1. Dezember 2025, einen Tag vor dem Start der AWS re:Invent in Las Vegas. Erstmals haben zwei Hyperscaler gemeinsam eine Netzwerkinfrastruktur entwickelt, die ihre Clouds direkt verbindet. Technisch sind es zwei Produkte: AWS Interconnect – multicloud auf der AWS-Seite und Cross-Cloud Interconnect auf der Google-Cloud-Seite. Beide nutzen eine gemeinsam entwickelte API-Spezifikation.

Das Resultat: Kunden können private, dedizierte Verbindungen zwischen ihren AWS VPCs und Google Cloud VPC Networks aufbauen. Der Traffic läuft über dedizierte physische Leitungen zwischen den Edge-Routern beider Anbieter, verschlüsselt mit MACsec (IEEE 802.1AE). Kein Paket berührt das öffentliche Internet.

Für die Praxis bedeutet das: Ein Unternehmen, das eine Datenbank auf Google Cloud betreibt und die Applikationslogik auf AWS, kann beide Workloads jetzt mit niedrigen Latenzen und voller Bandbreite verbinden. Ohne VPN-Tunnel, ohne Transit-Provider, ohne manuelle Provisionierung.

Warum Frankfurt als Launch-Region entscheidend ist

Die fünf Launch-Regionen des Previews sind US-East (Northern Virginia), US-West (Oregon), US-West (N. California), Europe (London) und Europe (Frankfurt). Dass Frankfurt von Anfang an dabei ist, ist kein Zufall. Die Region eu-central-1 (AWS) bzw. europe-west3 (Google Cloud) ist der wichtigste Cloud-Standort in Kontinentaleuropa.

Für DACH-Unternehmen eliminiert das einen der größten Schmerzpunkte bei Multi-Cloud-Architekturen: die Netzwerk-Latenz zwischen Clouds. Bisher mussten Unternehmen, die Workloads auf AWS und Google Cloud verteilen wollten, entweder über das öffentliche Internet routen (mit allen Sicherheits- und Performance-Risiken) oder einen Drittanbieter wie Megaport oder Equinix Fabric zwischenschalten. Das dauerte Wochen, kostete extra, und die Bandbreite war oft limitiert.

Mit dem nativen Interconnect entfällt der Mittelsmann. Die Provisionierung erfolgt per API, die Verbindung steht in Minuten, und die Verschlüsselung ist Standard. Für regulierte Branchen in Deutschland, die DSGVO-konforme Datenverarbeitung nachweisen müssen, ist die Garantie, dass kein Traffic über das öffentliche Internet fließt, ein handfester Compliance-Vorteil.

Die offene Spezifikation: Ein Industriestandard in der Entstehung

Ein Detail, das leicht übersehen wird: AWS hat die zugrundeliegende Connection Coordinator API Specification als OpenAPI 3.0 auf GitHub veröffentlicht. Das ist kein proprietäres Protokoll, sondern eine offene Spezifikation, die andere Cloud-Anbieter implementieren können.

Microsoft Azure soll laut InfoQ als nächster Anbieter angebunden werden. AWS hat angekündigt, weitere Cloud-Provider onboarden zu wollen. Wenn Azure tatsächlich 2026 folgt, entsteht ein nativer Interconnect zwischen allen drei großen Hyperscalern. Das wäre ein fundamentaler Wandel: Multi-Cloud-Networking würde vom komplexen Infrastrukturprojekt zum API-Call.

Für Cloud-Architekten ändert sich die Kosten-Nutzen-Rechnung bei Multi-Cloud-Entscheidungen. Bisher war Netzwerk-Komplexität eines der stärksten Argumente gegen Multi-Cloud. Wenn diese Komplexität wegfällt, rücken andere Faktoren in den Vordergrund: Best-of-Breed-Services, Preisvergleich, Verfügbarkeitszonen und regulatorische Anforderungen.

„Verbindungen zwischen Clouds aufzubauen, die bisher Wochen oder Monate dauerten, lassen sich jetzt in Minuten provisionieren.“
– AWS/Google Cloud, Joint Announcement, Dezember 2025 (sinngemäß)

Was der Interconnect technisch kann und was nicht

Der Interconnect löst das Netzwerk-Problem. Aber Multi-Cloud hat mehr Dimensionen als Konnektivität.

Was er kann: Private, verschlüsselte Layer-3-Verbindungen zwischen AWS VPCs und Google Cloud VPC Networks. Provisionierung per API mit definierten Bandbreiten (10 Gbps, 100 Gbps). Automatisches Routing über BGP. Monitoring über die jeweiligen Cloud-Konsolen.

Was er nicht kann: Unified Billing zwischen Clouds. Einheitliche IAM-Policies. Cross-Cloud-Observability aus einer Konsole. Automatische Workload-Migration. Der Interconnect ist eine Netzwerkleitung, kein Multi-Cloud-Betriebssystem.

Das bedeutet: Teams brauchen weiterhin Tools für Cloud-übergreifendes Management. Terraform oder Pulumi für Infrastructure as Code, Datadog oder Grafana für Monitoring, und organisatorische Prozesse für die Governance über mehrere Cloud-Konten. Der Interconnect eliminiert die Netzwerk-Komplexität, aber nicht die Betriebs-Komplexität.

Sicherheit und Compliance: Was der Interconnect für regulierte Branchen bedeutet

Für Finanzdienstleister, Gesundheitsunternehmen und andere regulierte Branchen in DACH ist der Interconnect mehr als eine Performance-Verbesserung. Die Garantie, dass kein Traffic über das öffentliche Internet fließt, vereinfacht die DSGVO-Dokumentation erheblich. Datenschutzbeauftragte können nachweisen, dass personenbezogene Daten ausschließlich über dedizierte, verschlüsselte Leitungen zwischen zwei Cloud-Anbietern übertragen werden.

Im Kontext von NIS2 ist das ebenfalls relevant. Unternehmen, die unter das NIS2-Umsetzungsgesetz fallen, müssen die Sicherheit ihrer Netzwerkinfrastruktur dokumentieren. Ein nativer Interconnect mit MACsec-Verschlüsselung ist einfacher zu dokumentieren als ein VPN-Tunnel über das öffentliche Internet. Die Verantwortlichkeiten sind klar: AWS verschlüsselt auf der einen Seite, Google Cloud auf der anderen, die physische Leitung dazwischen ist dediziert.

Trotzdem bleibt eine offene Frage: Wie verhält sich der Interconnect zur Datensouveränität? Die physischen Leitungen zwischen den Edge-Routern laufen über Infrastruktur, die weder AWS noch Google Cloud gehört. Wer diese Infrastruktur betreibt und wo genau die Daten auf dem Weg zwischen Frankfurt (AWS) und Frankfurt (Google Cloud) durchlaufen, ist nicht vollständig transparent dokumentiert.

Auswirkungen auf bestehende Multi-Cloud-Setups

Weltweit nutzen 89 Prozent der Unternehmen mehrere Cloud-Anbieter, zeigt der Flexera State of the Cloud Report 2024. Die meisten tun das nicht aus strategischer Überzeugung, sondern weil verschiedene Teams verschiedene Clouds gewählt haben. Die Verbindung zwischen diesen Clouds war bisher oft improvisiert: VPN-Tunnel, öffentliche Endpunkte mit IP-Whitelisting oder teure Direktverbindungen über Colocation-Provider.

Der native Interconnect ändert die Spielregeln für drei Szenarien:

Szenario 1: Daten-Pipeline. Ein Unternehmen nutzt BigQuery auf Google Cloud für Analysen und S3 auf AWS für die Datenhaltung. Bisher mussten die Daten über das Internet oder einen Transit-Provider geschoben werden. Jetzt fließen sie über eine dedizierte, verschlüsselte Leitung. Schneller, sicherer, günstiger im Egress.

Szenario 2: Disaster Recovery. Primary Workloads auf AWS, Failover auf Google Cloud. Der Interconnect ermöglicht synchrone oder asynchrone Replikation mit garantierter Latenz. Kein Vergleich zur bisherigen VPN-basierten Replikation.

Szenario 3: Best-of-Breed. Kubernetes auf GKE (Google), ML-Inferenz auf SageMaker (AWS), Datenbank auf Cloud SQL (Google). Statt Architektur-Kompromisse einzugehen, kann jedes Team den besten Service nutzen und die Netzwerk-Integration dem Interconnect überlassen.

Was Drittanbieter wie Megaport und Equinix jetzt tun müssen

Für Unternehmen wie Megaport, Equinix Fabric und PacketFabric ist der native Interconnect eine strategische Bedrohung. Ihr Geschäftsmodell basiert darauf, die Verbindung zwischen Clouds herzustellen, die es bisher nicht selbst konnten. Wenn AWS und Google Cloud das nativ anbieten und Azure folgt, schrumpft der adressierbare Markt erheblich.

Die Drittanbieter werden sich auf Mehrwerte konzentrieren müssen: Multi-Cloud-Management, Visibility, Compliance-Reporting und die Anbindung kleinerer Cloud-Anbieter, die nicht Teil des nativen Interconnects sind. Für Unternehmen, die auf europäische Cloud-Anbieter wie IONOS, OVHcloud oder STACKIT setzen, bleiben Drittanbieter vorerst die einzige Option für private Verbindungen.

Fazit

Der AWS-Google-Cloud-Interconnect ist mehr als ein neues Netzwerkprodukt. Es ist ein Signal: Die Hyperscaler haben erkannt, dass Multi-Cloud Realität ist, und beginnen, ihre Infrastrukturen zu öffnen. Frankfurt als Launch-Region macht das Angebot für DACH-Unternehmen sofort relevant.

Cloud-Architekten sollten den Preview jetzt evaluieren. Nicht um sofort umzusteigen, sondern um zu verstehen, wie sich die Kosten-Nutzen-Rechnung für Multi-Cloud-Architekturen verändert. Wenn Azure 2026 folgt und die offene Spezifikation zum Industriestandard wird, wird Netzwerk-Komplexität als Argument gegen Multi-Cloud verschwinden.

Die Frage ist dann nicht mehr ob Multi-Cloud, sondern welche Kombination von Anbietern und Services die beste Architektur für das eigene Unternehmen ergibt.

Häufige Fragen

Ist der AWS-Google-Cloud-Interconnect schon produktionsreif?

Der Interconnect befindet sich im Preview-Status (Stand März 2026). Er ist funktionsfähig und kann getestet werden, aber AWS und Google Cloud empfehlen, ihn noch nicht für geschäftskritische Produktions-Workloads einzusetzen. GA (General Availability) wird für 2026 erwartet.

Was kostet der Interconnect?

Die Preisgestaltung ist während des Previews noch nicht final. Beide Anbieter berechnen typischerweise eine Port-Gebühr (abhängig von der Bandbreite) plus Egress-Kosten für den transferierten Datenverkehr. Die Egress-Kosten dürften niedriger ausfallen als bei Transfer über das öffentliche Internet.

Kann ich den Interconnect mit bestehenden Direct Connect oder Partner Interconnect Setups kombinieren?

Ja. Der Interconnect ergänzt bestehende Verbindungen (AWS Direct Connect, Google Partner Interconnect). Er ersetzt sie nicht, sondern fügt eine neue Option für den Cloud-zu-Cloud-Verkehr hinzu.

Wird Azure ebenfalls angebunden?

AWS hat angekündigt, weitere Cloud-Anbieter onboarden zu wollen, darunter Microsoft Azure. Ein konkreter Termin steht noch nicht fest, aber die offene API-Spezifikation macht die Integration technisch möglich. Die Community rechnet mit 2026.

Brauche ich noch Megaport oder Equinix Fabric?

Für die direkte Verbindung zwischen AWS und Google Cloud in den Preview-Regionen nicht mehr. Für Verbindungen zu Azure, europäischen Cloud-Anbietern oder On-Premises-Rechenzentren bleiben Drittanbieter weiterhin relevant.

Weiterführende Artikel

• Sovereignty-Washing – Warum EU-Rechenzentrum noch keine Datensouveränität bedeutet (cloudmagazin)
• VMware-Kostenfalle 2026 – Warum IT-Teams jetzt über Alternativen entscheiden müssen (cloudmagazin)
• KI-Cloud-Kosten außer Kontrolle – Warum GPU-Workloads die IT-Budgets 2026 sprengen (cloudmagazin)

Mehr aus dem MBF Media Netzwerk

• Edge Computing – Warum die Cloud für den Mittelstand nicht immer reicht (MyBusinessFuture)
• Cloud-Repatriation 2026 – Warum CIOs Workloads zurückholen (Digital Chiefs)

Quelle Titelbild: Brett Sayles / Pexels