News

AWS, Google Cloud Frankfurt Multicloud Interconnect: DACH Impact

By Benedikt Langer March 7, 2026 7 min read

On December 1, 2025, AWS and Google Cloud did something unprecedented: they jointly announced a co-developed networking product. Private, MACsec-encrypted connections between the two clouds – provisioned via API in minutes instead of weeks via third-party providers. Frankfurt is one of five launch regions. For multicloud architectures across Germany, Austria, and Switzerland (DACH), this marks a turning point.

TL;DR

🔗 AWS Interconnect (multicloud) and Google Cross-Cloud Interconnect enable the first native interconnection between both clouds (AWS/Google, December 1, 2025).
🇩🇪 Frankfurt (eu-central-1 / europe-west3) is among the five preview launch regions (AWS Docs).
⚡ Provisioning in minutes via API – previously, setting up private cloud connections took weeks to months (InfoQ).
🔒 Encryption via MACsec (IEEE 802.1AE) on the physical link. Zero traffic traverses the public internet (AWS).
📊 Globally, 89% of enterprises use multiple cloud providers (Flexera State of the Cloud, 2024).

What AWS and Google Cloud Built

The announcement came on December 1, 2025 – one day before AWS re:Invent kicked off in Las Vegas. For the first time, two hyperscalers have jointly developed network infrastructure that directly connects their clouds. Technically, it comprises two products: AWS Interconnect – multicloud on the AWS side and Cross-Cloud Interconnect on the Google Cloud side. Both rely on a shared API specification.

The result: customers can now establish private, dedicated connections between their AWS VPCs and Google Cloud VPC Networks. Traffic flows over dedicated physical links between each provider’s edge routers – and is encrypted end-to-end using MACsec (IEEE 802.1AE). Not a single packet touches the public internet.

In practice, this means an enterprise running its database on Google Cloud and application logic on AWS can now connect those workloads with low latency and full bandwidth – no VPN tunnels, no transit providers, and no manual provisioning.

5 Regions

in preview (including Frankfurt)

MACsec

Layer-2 encryption (IEEE 802.1AE)

Minutes

instead of weeks for provisioning

Source: AWS Docs, Google Cloud Blog, InfoQ, December 2025

Why Frankfurt Is a Decisive Launch Region

The five preview launch regions are US-East (Northern Virginia), US-West (Oregon), US-West (North California), Europe (London), and Europe (Frankfurt). Frankfurt’s inclusion from day one is no coincidence. The region eu-central-1 (AWS) and europe-west3 (Google Cloud) is continental Europe’s most important cloud hub.

For DACH enterprises, this eliminates one of the biggest pain points in multicloud architecture: inter-cloud network latency. Until now, companies distributing workloads across AWS and Google Cloud had only two options: route traffic over the public internet – with all associated security and performance risks – or engage a third-party provider like Megaport or Equinix Fabric. That process took weeks, incurred extra cost, and often delivered limited bandwidth.

With the native interconnect, the middleman disappears. Provisioning happens via API; connections go live in minutes; encryption is built-in. For regulated German industries required to demonstrate GDPR-compliant data processing, the guarantee that no traffic crosses the public internet delivers a tangible compliance advantage.

The Open Specification: An Industry Standard in the Making

One easily overlooked detail: AWS has published the underlying Connection Coordinator API Specification as OpenAPI 3.0 on GitHub. This is not a proprietary protocol – it’s an open specification other cloud providers can implement.

According to InfoQ, Microsoft Azure is expected to be the next provider onboarded. AWS has publicly stated its intent to integrate additional cloud providers. If Azure joins in 2026, a native interconnect will exist among all three major hyperscalers – a fundamental shift. Multicloud networking would evolve from a complex infrastructure project into a simple API call.

For cloud architects, the cost-benefit calculus behind multicloud decisions changes dramatically. Until now, network complexity was one of the strongest arguments against multicloud. Remove that complexity, and other factors move to center stage: best-of-breed services, pricing comparisons, availability zones, and regulatory requirements.

// Quote

Connections between clouds – which previously took weeks or months to build – can now be provisioned in minutes.

AWS/Google Cloud · Joint Announcement, December 2025 (paraphrased)

What the Interconnect Can – and Cannot – Do Technically

The Interconnect solves the networking problem. But multicloud involves more than just connectivity.

What it can do: Private, encrypted Layer-3 connections between AWS VPCs and Google Cloud VPC Networks. API-driven provisioning at defined bandwidths (10 Gbps, 100 Gbps). Automatic BGP-based routing. Monitoring via each provider’s native cloud console.

What it cannot do: Unified billing across clouds. Unified IAM policies. Cross-cloud observability from a single console. Automated workload migration. The Interconnect is a network pipe – not a multicloud operating system.

That means teams still need tools for cross-cloud management: Terraform or Pulumi for Infrastructure as Code, Datadog or Grafana for monitoring, and organizational governance processes spanning multiple cloud accounts. The Interconnect eliminates network complexity – but not operational complexity.

Security and Compliance: Implications for Regulated Industries

For financial services firms, healthcare providers, and other regulated sectors across DACH, the Interconnect is more than a performance upgrade. The assurance that no traffic traverses the public internet significantly simplifies GDPR documentation. Data protection officers can demonstrate that personal data travels exclusively over dedicated, encrypted links between two cloud providers.

Within the context of NIS2, this matters too. Organizations falling under the NIS2 Implementation Act must document the security of their network infrastructure. A native interconnect with MACsec encryption is far easier to document than a VPN tunnel over the public internet. Responsibilities are clear: AWS encrypts on one end, Google Cloud on the other – the physical link between them is dedicated.

Still, one question remains open: How does the Interconnect align with data sovereignty? The physical links between edge routers run over infrastructure owned by neither AWS nor Google Cloud. Who operates that infrastructure – and precisely where data flows between Frankfurt (AWS) and Frankfurt (Google Cloud) – is not fully transparently documented.

Impact on Existing Multicloud Setups

Globally, 89% of enterprises use multiple cloud providers, according to the Flexera State of the Cloud Report 2024. Most adopt multicloud not by strategic design – but because different teams selected different clouds. Interconnecting those clouds has historically been improvised: VPN tunnels, public endpoints with IP whitelisting, or expensive direct connections via colocation providers.

The native Interconnect reshapes the rules for three key scenarios:

Scenario 1: Data Pipeline. An enterprise uses BigQuery on Google Cloud for analytics and S3 on AWS for data storage. Previously, data moved over the internet or via a transit provider. Now it flows over a dedicated, encrypted link – faster, safer, and cheaper on egress.

Scenario 2: Disaster Recovery. Primary workloads run on AWS; failover resides on Google Cloud. The Interconnect enables synchronous or asynchronous replication with guaranteed latency – far superior to prior VPN-based replication.

Scenario 3: Best-of-Breed. Kubernetes on GKE (Google), ML inference on SageMaker (AWS), database on Cloud SQL (Google). Instead of architectural compromises, each team selects the optimal service – and delegates network integration to the Interconnect.

What Third-Party Providers Like Megaport and Equinix Must Do Now

For companies like Megaport, Equinix Fabric, and PacketFabric, the native Interconnect represents a strategic threat. Their business model hinges on bridging clouds that couldn’t previously interconnect natively. If AWS and Google Cloud offer this capability – and Azure follows suit – the addressable market shrinks substantially.

Third parties will need to double down on value-adds: multicloud management, visibility, compliance reporting, and connectivity to smaller cloud providers excluded from the native Interconnect. For enterprises relying on European cloud providers like IONOS, OVHcloud, or STACKIT, third-party providers remain the only option for private interconnections – for now.

Conclusion

The AWS-Google Cloud Interconnect is more than a new networking product. It’s a signal: hyperscalers have acknowledged multicloud as reality – and begun opening their infrastructures. Frankfurt’s status as a launch region makes this offering immediately relevant for DACH enterprises.

Cloud architects should evaluate the preview now – not to migrate immediately, but to understand how the cost-benefit equation for multicloud architectures is shifting. If Azure joins in 2026 and the open specification becomes an industry standard, network complexity will vanish as an argument against multicloud.

The question then won’t be whether to adopt multicloud – but which combination of providers and services delivers the optimal architecture for your organization.

Frequently Asked Questions

Is the AWS-Google Cloud Interconnect production-ready yet?

The Interconnect is currently in preview (as of March 2026). It is functional and suitable for testing – but AWS and Google Cloud advise against deploying it for mission-critical production workloads. General Availability (GA) is expected in 2026.

How much does the Interconnect cost?

Pricing remains provisional during the preview. Both providers typically charge a port fee (based on bandwidth) plus egress fees for transferred data. Egress costs are expected to be lower than transfers over the public internet.

Can I combine the Interconnect with existing Direct Connect or Partner Interconnect setups?

Yes. The Interconnect complements existing connections (e.g., AWS Direct Connect, Google Partner Interconnect). It does not replace them – it adds a new option specifically for cloud-to-cloud traffic.

Will Azure also be integrated?

AWS has announced plans to onboard additional cloud providers – including Microsoft Azure. No official timeline has been confirmed, but the open API specification makes technical integration feasible. The community expects Azure integration in 2026.

Do I still need Megaport or Equinix Fabric?

Not for direct AWS-Google Cloud connections within preview regions. However, third-party providers remain essential for connecting to Azure, European cloud providers, or on-premises data centers.