5 Min. Lesezeit

Am 14. April hat AWS die General Availability von AWS Interconnect – multicloud bestätigt, mit Google Cloud als erstem Launch-Partner. Was für DACH-Architekten zählt: Workload-Operations zwischen den beiden Clouds laufen jetzt über eine native, MACsec-verschlüsselte Bridge – inklusive Frankfurt und London als Region am Start. Microsoft Azure und Oracle folgen später im Jahr. Damit verschwindet ein großer Teil des Plumbing-Aufwands, der bisher Multicloud-Operations definiert hat.

Das Wichtigste in Kürze

Was ist AWS Interconnect – multicloud? AWS Interconnect – multicloud ist eine native, hochbandbreitige private Verbindung zwischen Amazon VPCs und anderen Hyperscaler-Umgebungen. Anders als bisherige Cross-Connect-Modelle benötigt die Lösung keinen Drittanbieter-Backbone und keine separate Verkabelung auf der Gegenseite – die physische Schicht, BGP und VLAN-Attachments sind abstrahiert. Bandbreite skaliert von 1 bis 100 Gbit/s, MACsec-Encryption läuft per Default.

Was die GA tatsächlich bringt

Der eigentliche Punkt ist nicht das Stück Glasfaser, sondern was am Ende der Glasfaser passiert. Bisher hieß „Multicloud-Operations“ für die meisten DACH-Teams: Direct Connect bei AWS, Partner Interconnect bei Google, ein Colo-Provider in der Mitte, eigenes BGP, eigene Encryption, eigene Tickets bei drei Stellen wenn etwas hakt. Das funktioniert, aber es ist Plumbing-Aufwand, der nichts mit dem Workload zu tun hat, der oben drauf läuft.

Mit der GA verkleinern AWS und Google diesen Stack auf eine einzige Transport-Ressource. Laut Google Cloud Blog wird in Google die Transport-Ressource konfiguriert, in AWS akzeptiert, der Rest – Cloud Router, VLAN-Attachments, physische Interconnects – ist abstrahiert. Setup-Zeit: Minuten statt Tage. MACsec-Verschlüsselung ist immer an, Key-Rotation laufen beide Provider selbst.

Über die AWS-Ankündigung vom 14. April kommt der zweite Hebel: Interconnect lässt sich an Transit Gateway oder Cloud WAN hängen. Damit bekommt eine Verbindung nicht eine VPC, sondern den ganzen AWS-Backbone als Reichweite. Wer einen Workload-Move zwischen GKE und EKS plant, sieht plötzlich keinen Sterntopologie-Albtraum mehr, sondern ein einzelnes Routing-Modell. Das ist der Unterschied zwischen Network-Plumbing und Workload-Operations.

Timeline: Wie sich die Hyperscaler-Brücken entwickelt haben

Was das für DACH-Hybrid-Setups konkret heißt

Die meisten Multicloud-Setups in DACH sind nicht aus Strategie entstanden, sondern aus Akquisitionen, gewachsenen SaaS-Stacks und einer SAP-on-AWS-Welt mit BigQuery-Anhängseln. Wer heute zwischen den beiden Clouds Daten oder Compute bewegt, betreibt in der Regel zwei separate Network-Stacks und einen Excel-Trigger für Failover-Tests. Das ist nicht falsch, aber es kostet Stunden, die niemand mehr in Betriebsmeetings einplanen will.

Die GA-Variante adressiert genau diese Operations-Friktion. Frankfurt und London bedeuten, dass DACH-Workloads nicht über US-Regionen routen müssen – das ist nicht nur Latenz, sondern auch eine DSGVO-Argumentation, die Compliance-Teams ohne Kopfstand führen können. Die offene Spec auf GitHub deutet darauf hin, dass Stackit, OVH oder andere Local-Cloud-Anbieter mittelfristig denselben Mechanismus implementieren können – das ist relevant für Architekten, die heute aus regulatorischen Gründen nicht zu 100 Prozent auf US-Hyperscaler setzen können.

Komplementär: Google Cloud hat parallel Cross-Cloud Caching für gelesene AWS- und Azure-Daten ausgerollt. Wer beides kombiniert, hat eine Operations-Bridge plus eine Daten-Bridge – aber das ist eine andere Diskussion mit eigenen Datenhoheits-Trade-offs.

Was dafür spricht und was dagegen spricht

Drei Hebel für Architekten in den nächsten 60 Tagen

Erstens: Inventur. Welche Workloads laufen heute in beiden Clouds, welche Übergaben sind aktiv, welche sind Resterampen aus alten Migrationen? Wer mit der GA arbeiten will, muss die Liste der echten Brücken kennen, nicht die Folie aus dem letzten Architektur-Review. Diese Inventur ist eng verwandt mit der Multi-Cloud-Compliance-Inventur unter NIS2 und C5, die sowieso fällig ist.

Zweitens: Operations-Modell. Wer steuert das? Eine Operations-Bridge braucht eine klare Owner-Definition – sonst landet sie zwischen Network, Cloud-Plattform und SRE. Drei Tickets pro Incident sind kein Zielzustand. Sinnvoll ist ein Multicloud-SRE-Funnel, der Tickets in beide Konsolen routet und einen End-to-End-View hat.

Drittens: IaC-Anpassung. Wer Workload-Move plant, sollte den Transport-Resource-Block heute schon in Terraform-Module einbauen – Provider-Updates kommen in den nächsten Wochen, das Versions-Pinning entscheidet, ob der Pilot in Q3 startet oder erst nach dem nächsten Refresh.

Häufige Fragen

Wann ist AWS Interconnect – multicloud allgemein verfügbar?

AWS hat die General Availability am 14. April 2026 bestätigt. Google Cloud ist der erste Launch-Partner, Microsoft Azure und Oracle Cloud Infrastructure folgen laut beiden Anbietern später im Jahr.

Welche Regionen sind für DACH relevant?

Frankfurt und London zählen zu den fünf Start-Regionen, hinzu kommen N. Virginia und Oregon. Damit lassen sich DACH-Workloads ohne transatlantischen Umweg verbinden – relevant für Latenz und für DSGVO-Argumentation.

Wie unterscheidet sich das von der bisherigen Cross-Cloud Interconnect-Variante?

Bisher war Cross-Cloud Interconnect ein Google-only-Konstrukt: Google stellte die Verbindung, AWS-seitig musste Direct-Connect-typisch verkabelt werden. Mit der bilateralen GA reicht eine Transport-Ressource in Google und ein Accept in AWS, der physische Layer und das Routing sind abstrahiert.

Was kostet die Verbindung in den ersten Wochen?

Ab Mai 2026 ist ein lokaler 500-Mbit/s-Slot pro Region kostenlos verfügbar. Höhere Bandbreiten bis 100 Gbit/s werden nach Bandbreite und geografischem Scope abgerechnet – die Kalkulation gehört in das nächste FinOps-Review.

Welche AWS-Services lassen sich an Interconnect koppeln?

Laut AWS lässt sich Interconnect mit AWS Transit Gateway und AWS Cloud WAN verbinden. Damit lässt sich eine einzelne Multicloud-Verbindung auf mehrere VPCs und Regionen skalieren – der eigentliche Operations-Hebel.

Bringt MACsec-Encryption für die Compliance einen messbaren Unterschied?

Ja, weil die Verschlüsselung auf Layer-2 immer an ist und beide Provider die Key-Rotation übernehmen. Audit-Teams müssen damit nicht mehr prüfen, ob ein Tunnel sauber konfiguriert wurde – das war bisher ein wiederkehrender Posten in C5- und ISO-27001-Reviews.

Lesetipps der Redaktion

Mehr aus dem MBF Media Netzwerk

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