AWS & Google Cloud: Joint Multicloud Preview for DACH IT
AWS and Google Cloud launch a joint multicloud networking preview. Frankfurt is one of three launch regions. Azure follows at the end of 2026.
AWS and Google Cloud launched a joint multicloud networking service into preview in April 2026. The announcement at re:Invent positions the two hyperscalers unusually close together, targeting a pain point many DACH companies have grappled with for years: complex interconnects between clouds that complicate operations. Microsoft Azure is set to follow by the end of 2026. Status: April 14, 2026.
Key Takeaways
- Preview as of April 2026: Three regions, including Frankfurt. Production use for core workloads is premature; testing now makes sense.
- Targeting DACH: Companies with existing AWS-primary and Google-secondary setups will benefit fastest—especially in data-lake architectures using BigQuery analytics on S3 datasets.
- Azure joins late 2026: Those relying on three clouds must wait. Until Microsoft follows, operations remain dual-track.
- CIO relevance: Vendor lock-in risk decreases—but only at the networking layer. Database and workload portability remain separate challenges.
- Definition: Multicloud networking refers to centrally managing private connections across multiple public clouds via a unified control plane, rather than maintaining separate gateway, BGP, and VPN configurations for each cloud pair.
What AWS and Google Actually Announced
The service introduces a shared control plane for private connections between AWS and Google Cloud VPCs. Initially available in three regions—including Frankfurt—customers can now connect subnets through a unified workflow, eliminating the need to manage Direct Connect and Cloud Interconnect in parallel.
For platform teams running multicloud setups under load since 2024, this marks a significant shift. But the devil’s in the details—separating marketing promises from operational benefits. For 2026 planning, a clear-eyed look at what already works today is worth the effort.
According to the announcement, the collaboration simplifies building private connections between the two clouds. Instead of configuring Direct Connect and Partner Interconnect separately, a shared networking layer abstracts both sides. The preview is live in three regions—Frankfurt and, per reports from CIO Dive, two U.S. locations.
Technically, the value lies in reducing configuration overhead. Until now, platform teams had to manage BGP sessions, AS paths, and VPN tunnels separately on both sides. The new service consolidates this into a single abstraction. For the initial rollout: Layer-3 connectivity is supported, but automatic policy synchronization between AWS Security Groups and Google Cloud Firewall Rules isn’t yet available.
Context matters: This announcement follows a series of moves AWS and Google Cloud have made in the German market since late 2025. Frankfurt’s Interconnect launch in March was the technical precursor. The current preview adds the control layer. Reading the infrastructure announcements of the past six months chronologically reveals a clear strategy: both hyperscalers no longer want multicloud to be seen as a last resort but as the standard.
According to Info-Tech Research Group, AWS holds roughly 32% of the global market, Azure 23%, and Google Cloud 11%. The collaboration makes sense precisely for this reason: AWS doesn’t need to cede market share to Google, while Google gains access to AWS-native deployments. For DACH companies, Frankfurt’s data center ecosystem stands to benefit directly.
What’s real today—and what’s still marketing
Before you decide, three things to keep in mind. First: “Preview” means preview. No SLAs, region availability can shift overnight, customer numbers are confidential. If you rely on this service for production-grade multicloud data pipelines, you’re taking on risk that’s operationally tough to mitigate.
Second: the abstraction stops at the network, not identity. IAM policies still need to be modeled separately in each cloud. Anyone aiming for clean single sign-on or cross-cloud service accounts will quickly find themselves back with Terraform or dedicated identity-federation layers. The announcement doesn’t change that—it only cuts overhead at Layer 3 and below, not Layer 7.
Third: Azure is missing. The official timeline targets late 2026 for Microsoft integration. Until then, the three-cloud scenario remains a split process. Teams spanning workloads across AWS, Azure, and Google Cloud must continue dual-track planning. For enterprises with Azure-heavy legacy workloads (Office 365, Dynamics, numerous SaaS integrations), the network advantage of the new preview stays theoretical until Azure support arrives.
Operationally, this means for most DACH IT organizations: the new preview is compelling as a signal and a sandbox, not as a production building block. If you’re planning a two-cloud strategy with AWS and Google Cloud by 2026, you can factor the abstraction into your architecture discussions. If Azure is in the mix, you’ll keep relying on established third-party providers like Megaport or Equinix Fabric.
What Platform Teams in DACH Should Review Now
For most IT organisations across the DACH region, three concrete steps make sense. The first is an inventory check: which workloads currently run across multicloud connections, and how much configuration effort do they require? If it’s under 10 percent of platform engineering time, the preview isn’t a priority. If the overhead is higher, a test setup in Frankfurt is worth considering.
The second step is a comparison with existing alternatives. Megaport, Equinix Fabric and Console Connect have offered cross-cloud interconnects for years. The difference with the new AWS-Google collaboration lies in the pricing model and management layer—not in fundamentally new technology. Our DACH comparison of the three hyperscalers highlights the key differences in network features and pricing.
The third step concerns workload strategy. A simplified multicloud layer reduces operational costs for distributed architectures—but it doesn’t make cloud repatriation obsolete. If you’re asking in 2026 which workloads should return to on-prem data centres, the Cloud Repatriation TCO model analysis provides a structured framework for that decision.
A fourth topic keeps surfacing in project discussions: compliance. If you’re assessed under NIS2 or DORA, you’ll need to walk your auditors through the network abstraction. Responsibility for incident reporting still rests with each cloud provider individually. A shared control plane doesn’t change reporting paths—it simply adds another abstraction layer that IT governance must factor in.
Comparison with Existing Multicloud Interconnect Offerings
The announcement doesn’t land in a vacuum. For at least five years, a market for cross-cloud interconnects has existed, split into three categories. Network brokers like Megaport and Equinix Fabric provide virtual direct connections between all major hyperscalers. They’re physically located in carrier hotels and sell Layer-2 connectivity as a service. Colocation providers like NTT or Interxion extend this with physical cage-to-cage connections. Cloud-native SD-WAN services like Cisco Multicloud Defense or Aviatrix add a software layer on top, complete with their own policy engines.
The AWS-Google collaboration falls into a fourth category: hyperscaler-native cooperation. The difference lies in integration depth and price. A typical Megaport setup for a DACH company spanning two cloud regions costs around 2,000 to 4,000 euros per month, depending on bandwidth and redundancy. The AWS-Google collaboration will likely undercut that, since no third party takes a cut. Exact figures aren’t available yet.
For companies with existing Megaport or Equinix contracts, nothing changes in the short term. Contracts remain in place, and functionality stays broader. But if you’re launching a new multicloud strategy in 2026 and only AWS plus Google Cloud are in scope, you should evaluate the native option once it reaches general availability.
What’s Realistically Next
The next three to six months will reveal whether the preview holds up technically. Three key observations matter. Region availability stability: if one of the three launch regions fails, confidence in the overall architecture drops sharply. Expansion to additional Frankfurt dependencies: will eu-central-2 (Zurich) be added, or will it stay limited to eu-central-1? The answer determines whether Swiss customers with data residency requirements can participate. Clarity on Azure timing: if Microsoft’s late-2026 deadline is met, the network abstraction trio becomes viable. If not, the preview remains an AWS-Google tool with limited reach.
For German mid-market companies with an AWS-dominant cloud strategy, the preview offers a valuable learning opportunity. A test VPC in Frankfurt connected to a Google Cloud counterpart via the new service costs negligible budget and reveals, in operation, how much operational overhead the abstraction actually saves. The results will feed into architecture decisions for 2027, when Azure is expected to join the mix.
Risks and Open Questions
While the simplification is certainly welcome, some risks remain. The first concerns vendor lock-in at the network layer. Companies building their multicloud architecture on a service orchestrated by either hyperscaler have reduced their dependency—but not eliminated it. The abstraction only works within the boundaries jointly defined by AWS and Google. Features exclusive to one of the two clouds remain siloed.
The second risk lies in the support model. When an issue arises, the classic multi-vendor question emerges: Which support team is responsible? The announcement mentions a joint escalation model. How this will function in practice during real P1 incidents is the true stress test. Experience from comparable partnerships shows that shared support processes take 6 to 12 months to run smoothly.
The third open question is roadmap visibility. Will IAM integration arrive in 2027? Will policy synchronization and network policy federation expand to Layer 7? Without these enhancements, the service remains a networking tool—not a full-fledged multicloud management platform. That’s not a criticism—just a clear positioning IT architects need to understand before building on it.
Architecture Recommendations for 2026 Projects
For teams planning a cloud rebuild or refactoring an existing architecture, three guiding principles apply. First: anchor the network layer in open standards. Hyperscaler abstractions are convenient, but a Terraform or Crossplane foundation offers greater long-term stability. Second: decouple identity from networking. Solving single sign-on via dedicated providers like Okta, Entra ID, or Keycloak keeps you more flexible when switching cloud providers. Third: model cost structures before they materialize. Simplified multicloud connectivity reduces operational costs but may inflate data transfer fees if used too liberally. A thoroughly calculated TCO model for 24 months provides a more reliable decision-making basis than any hyperscaler’s pricing announcement.
The fourth consideration is monitoring. When connecting two clouds via an abstracted control plane, observability must span both environments. Prometheus-based setups with Grafana as a unified frontend have proven practical for mid-sized DACH companies. A dedicated multicloud observability platform like Datadog or Dynatrace only pays off at workload complexities most mid-market firms won’t encounter anyway.
Frequently Asked Questions
When will the AWS-Google multicloud collaboration be ready for production use?
The preview is currently underway, with no general availability (GA) date announced yet. For mission-critical production workloads, waiting for GA is advisable. However, the service can already be tested for non-critical workflows, data lake replication, or sandbox environments.
Will this service replace Megaport or Equinix Fabric?
Not in the short term. Megaport and Equinix provide cross-cloud interconnects across more regions, support all three major hyperscalers, and offer proprietary private network features. The AWS-Google collaboration is a more cost-effective and tightly integrated solution—but only for two-cloud setups between these two providers.
What does this mean for compliance assessments under DORA and NIS2?
Network abstraction doesn’t change the data controller’s responsibilities. Both clouds remain separate processors. Regulatory assessments—covering data location, logging, and incident reporting obligations—must still be conducted individually for each cloud environment.
Will the collaboration expand to Frankfurt Region 2 (eu-central-2)?
The initial three regions include Frankfurt (eu-central-1), but an expansion to Zurich (eu-central-2) hasn’t been officially confirmed. For Swiss customers with data residency requirements, this remains a critical consideration.
What does the service cost during the preview phase?
No official pricing has been released with the announcement. Preview access requires account registration, and cost details will be shared post-enrollment. Once GA launches, expect a dedicated pricing model aligned with existing Direct Connect and Cloud Interconnect tariffs.
Editor’s Picks
Source: Pexels / Brett Sayles
