Seamless Multicloud Operations
AWS announced on April 14 the general availability of AWS Interconnect – multicloud.
On April 14, AWS confirmed the general availability of AWS Interconnect – multicloud, with Google Cloud as the first launch partner. For DACH architects, this means that workloads between both clouds now run through a native encrypted bridge with MACsec – including Frankfurt and London as available regions at launch. Microsoft Azure and Oracle will follow later in the year. This eliminates much of the plumbing effort that has defined multi-cloud operations until now.
Key Takeaways
- What’s new: AWS Interconnect – multicloud is available from April 14; Google Cross-Cloud Interconnect for AWS is the counterpart.
- Where it starts: Five AWS regions, including Frankfurt and London – relevant for DACH-compliant data flows without a US hop.
- How it works: A transport resource in Google Cloud, an acceptance in AWS, MACsec encryption always enabled, configuration time in minutes instead of days.
- Why it matters now: With Transit Gateway or Cloud WAN, the bridge scales to the entire AWS backbone – the true operational lever.
- What’s pending: Microsoft Azure and Oracle Cloud are announced but not yet active. Identity and FinOps topics remain separate workstreams.
What is AWS Interconnect – multicloud? AWS Interconnect – multicloud is a private, high-bandwidth connection between Amazon VPCs and other hyperscaler environments. Unlike previous interconnection models, the solution does not require a third-party backbone or separate cabling on the other side – the physical layer, BGP, and VLAN attachments are abstracted. Bandwidth scales from 1 to 100 Gbit/s, with MACsec encryption enabled by default.
The Real Value of General Availability
The key point is not the fiber optic link, but what happens at the end of that link. Until now, “multi-cloud operations” for most DACH teams meant Direct Connect in AWS, Partner Interconnect in Google, a colocation provider in the middle, BGP of their own, encryption of their own, and tickets in three places if something fails. It works, but it’s plumbing effort that has nothing to do with the workload running on top.
With general availability, AWS and Google reduce this stack to a single transport resource. According to the Google Cloud blog, the transport resource is configured in Google, accepted in AWS, and the rest – Cloud Router, VLAN attachments, physical interconnections – are abstracted. Configuration time: minutes instead of days. MACsec encryption is always enabled, and both providers manage key rotation automatically.
The AWS announcement of April 14 brings the second lever: Interconnect can connect to Transit Gateway or Cloud WAN. Thus, a connection reaches not just one VPC, but the entire AWS backbone. Those planning to move workloads between GKE and EKS will no longer see a star topology nightmare, but a single routing model. That’s the difference between network plumbing and workload operations.
Timeline: How Hyperscaler Bridges Have Evolved
What This Specifically Means for DACH Hybrid Configurations
The majority of Multicloud setups in DACH didn’t arise from strategy, but from acquisitions, growing SaaS stacks, and a world of SAP-on-AWS with BigQuery add-ons. Anyone moving data or compute between the two clouds typically operates two separate Network-Stacks and an Excel trigger for failover testing. It’s not bad, but no one wants to plan more hours in operational meetings.
The GA variant exactly addresses this operational friction. Frankfurt and London mean that DACH workloads no longer need to route through U.S. regions – it’s not just latency, but also an RGPD argument that compliance teams can handle without headaches. The open specification on GitHub suggests that Stackit, OVH, or other local cloud providers could implement the same mechanism in the medium term – this is relevant for architects who today cannot rely 100% on U.S. hyperscalers due to regulatory reasons.
Additionally: Google Cloud has deployed Cross-Cloud Caching for data read from AWS and Azure in parallel. Combining both provides an operational Bridge and a data Bridge – but that’s another discussion with its own data sovereignty commitments.
Pros and Cons
Pros
- Configuration time reduced from days to minutes – the gain is in the testing and development stages, not in the productive tunnel.
- MACsec is always active, key rotation is managed – one less audit point per quarter.
- Frankfurt and London regions allow compliant data routes without jumping through the US.
- Free-Slot of 500 Mbit/s since May makes real pilots viable – no need for an internal business case.
- Transit-Gateway and Cloud-WAN connections scale a connection to the entire AWS backbone.
Cons
- Azure and Oracle are still missing – those managing a triple cloud keep the old stack.
- The Bridge resolves Network Operations, not Identity. SCIM, IAM-Federation, and Workload-Identity remain separate issues.
- Pricing based on bandwidth and Geo – modeling should land on FinOps dashboards, or the Free-Slot will consume more than it saves.
- Vendor-Lock-In becomes more subtle: two clouds, one Fabric model – exiting is possible, but more expensive than cutting a VPN setup.
Three Levers for Architects in the Next 60 Days
First: the inventory. What workloads are currently running in both clouds, what transfers are active, and which are remnants of previous migrations? Anyone aiming to work with General Availability (GA) must know the list of real bridges, not the last architecture review slide. This inventory is closely linked to the multi-cloud compliance inventory under NIS2 and C5, which is already mandatory.
Second: operations model. Who manages it? A clear definition of ownership is required for an Operations Bridge; otherwise, it will be left hanging between the network, cloud platform, and SRE. Three tickets per incident is not the desired state. The appropriate approach is a multi-cloud SRE funnel that routes tickets to both consoles and provides end-to-end visibility.
Third: IaC adaptation. Anyone planning a workload migration should already integrate the transport resource block into Terraform modules; provider updates will arrive in the next few weeks, and version locking will determine if the pilot starts in Q3 or after the next update.
Frequently Asked Questions
When will AWS Interconnect multicloud be generally available?
AWS confirmed general availability on April 14, 2026. Google Cloud is the first launch partner, while Microsoft Azure and Oracle Cloud Infrastructure will follow later in the year, according to both providers.
Which regions are relevant for the DACH region?
Frankfurt and London are among the initial five regions, joined by N. Virginia and Oregon. This setup allows DACH region workloads to connect without transatlantic detours, which is crucial for both latency and GDPR compliance.
How does this differ from the previous version of Cross-Cloud Interconnect?
Until now, Cross-Cloud Interconnect was a construct exclusive to Google, where Google provided the connection and AWS required a Direct Connect-style wiring. With the bilateral general availability, a transport resource in Google and an acceptance in AWS are sufficient; the physical layer and routing are abstracted.
What is the cost of the connection in the first few weeks?
Starting from May 2026, a 500 Mbit/s local slot will be available free of charge per region. Higher bandwidths, up to 100 Gbit/s, will be charged based on bandwidth and geographic scope; this should be included in the next FinOps review.
Which AWS services can connect to Interconnect?
According to AWS, Interconnect can connect to AWS Transit Gateway and AWS Cloud WAN. This allows scaling a single multi-cloud connection to multiple VPCs and regions, forming a true operational lever.
Does MACsec encryption make a measurable difference for compliance?
Yes, because MACsec encryption at layer 2 is always active and both providers handle key rotation. With this, auditors no longer need to verify if a tunnel is correctly configured; this was a recurring point in C5 and ISO 27001 reviews until now.
Reading Recommendations
More from MBF Media Network
- MyBusinessFuture – Digitalization, AI, and Business Strategy for DACH SMEs
- SecurityToday – Cybersecurity, NIS2, and Compliance from an Operational Perspective
- Digital Chiefs – C-Level Perspective on Strategy, Governance, and Board Advisory
Image source on cover: Pexels / Brett Sayles (px:4373997)
Translated from the German original using artificial intelligence. The German version is authoritative.
