AWS and Google Cloud Just Made Multicloud Real

New to multicloud? Start with the What Actually Launched section for the facts, then jump to What This Means for Architects for the practical takeaways.

Topic	When	Key Detail
AWS Interconnect Multicloud	Q1 2026	Native cross-cloud links from AWS console
Google Cross-Cloud Interconnect	Q1 2026	GCP-side provisioning via Cloud Console
Open interoperability spec	2026	Shared API surface for provisioning and monitoring
Azure support	Later 2026	Microsoft confirmed participation in the spec
Egress pricing	Now	Interconnect traffic at reduced rates vs standard egress

What Actually Launched

In early 2026, AWS and Google Cloud did something that the cloud industry has talked about for years but never actually delivered: they launched a joint multicloud interconnect service built on an open interoperability specification.

On the AWS side, the service is called AWS Interconnect Multicloud. It allows you to provision a dedicated, low-latency link from an AWS VPC directly to a Google Cloud VPC network — all from the AWS Management Console. No third-party colocation provider, no manual BGP configuration, no stitching together VPN tunnels and hoping they stay up.

On the Google side, the corresponding service is Google Cross-Cloud Interconnect. It does the same thing in reverse — you can set up the connection from the Google Cloud Console and have a private, high-bandwidth path into AWS. Google had already been offering Cross-Cloud Interconnect to Azure and Oracle since 2023, but this is the first time it has been backed by a shared, open specification with the other provider actively participating.

The critical difference between this and earlier cross-cloud networking options is the open interoperability specification. Both AWS and Google have agreed to a common API surface for provisioning, monitoring, and managing these links. That means tooling built for one side works with the other, and third-party infrastructure-as-code tools can manage the full connection lifecycle through a single abstraction.

The Open Specification

The open interoperability spec is what elevates this from “another interconnect product” to a genuine shift in how cloud providers relate to each other. Here is what it covers:

• Provisioning API — A shared interface for requesting, approving, and activating cross-cloud links. One Terraform provider or SDK call can create both ends of the connection.
• Monitoring and telemetry — Both providers expose link health, throughput, latency, and error metrics through a common schema. Your existing monitoring stack can ingest data from both sides without custom translation.
• Security model — Mutual authentication, encryption in transit, and consistent firewall rule semantics. The spec defines how security groups and firewall rules on each side interact, so you do not end up with a gap between two different security models.
• Routing — BGP peering is automated. You define your CIDR blocks on each side, and the interconnect handles route advertisement without manual configuration.

This matters because it means multicloud networking can finally be treated as infrastructure-as-code rather than a manual networking project. If you are already using Terraform or Pulumi to manage your cloud resources, the cross-cloud link becomes just another resource in your state file.

Azure Is Joining Later

Microsoft has confirmed that Azure will adopt the open interoperability specification later in 2026. This is significant for two reasons.

First, it means the specification is not a bilateral deal between AWS and Google — it is becoming an industry standard. When the third major provider commits to the same API surface, it becomes much harder for any of them to walk it back or fragment it.

Second, Azure joining completes the big-three picture. Most enterprises that run multicloud workloads are spread across some combination of AWS, Azure, and GCP. Having all three on the same interconnect specification means a single networking architecture can cover every combination: AWS-GCP, AWS-Azure, GCP-Azure, or all three.

For teams that have been avoiding multicloud because the networking layer was too fragmented, this removes the biggest technical objection.

What This Means for Architects

If you are a cloud architect or platform engineer, this changes how you think about workload placement. Here are the practical implications.

Best-of-breed is now viable

The old argument against multicloud was simple: the networking overhead and egress costs wiped out any benefit you gained from using a different provider’s specific service. That argument is now substantially weaker.

With interconnect pricing at a fraction of standard egress rates and a native, managed link between providers, you can genuinely consider running your ML training on GCP (where TPUs live), your production API on AWS (where your team has the deepest expertise), and your analytics on BigQuery — without the networking layer being a constant source of pain and cost.

Disaster recovery gets simpler

Cross-cloud DR has always been theoretically attractive but practically painful. The interconnect changes the calculus. You can now replicate data between AWS and GCP over a private, low-latency link at reduced cost, making a genuine cross-provider DR strategy feasible for the first time without a massive egress bill.

Data residency and sovereignty

For organisations operating under data sovereignty requirements, the ability to connect two providers within the same region via a private link means you can use services from both providers without data leaving the geographic boundary. The interconnect supports region-specific provisioning, so you can keep traffic within Europe, for example, even when it crosses provider boundaries.

Negotiating leverage

Let us be honest about the commercial angle. When your workloads can move between providers without a six-month networking migration, your position in contract negotiations improves dramatically. Cloud providers know this, which is partly why they are investing in making multicloud work — it is better to share a customer than to lose one entirely.

Practical Implications for Existing Deployments

If you already run workloads on both AWS and GCP, here is what you should be doing right now.

Audit your cross-cloud traffic

Before you can evaluate the interconnect, you need to know how much data actually moves between your AWS and GCP environments. Check your egress bills, identify the top data flows, and calculate what the same traffic would cost over the interconnect. For most organisations, the savings on egress alone will justify the interconnect fee.

Replace your VPN tunnels

If you are currently running IPsec VPN tunnels between AWS and GCP, those are the first things to migrate. The interconnect provides higher bandwidth, lower latency, and better reliability than VPN tunnels, and it is managed natively by both providers. You can decommission your VPN gateways and save on both the gateway costs and the engineering time spent maintaining them.

Update your IaC

The open specification means both the AWS and GCP Terraform providers will support the interconnect as a first-class resource. Start by adding the interconnect to your infrastructure code in a non-production environment. Validate that the provisioning, monitoring, and teardown lifecycle works end-to-end before rolling it out to production.

Review your security posture

The interconnect introduces a new network path between your environments. Make sure your security team understands how the mutual authentication works, how firewall rules map between AWS security groups and GCP firewall rules, and what logging is available for cross-cloud traffic. The open specification standardises the security model, but you still need to verify it matches your compliance requirements.

Before vs After: What Changes

The shift from the old multicloud model to the new interconnect model is substantial. Here is a side-by-side comparison of what changes in practice.

The “after” column is not theoretical — these are capabilities that are available now for AWS-GCP connections, and will extend to Azure when Microsoft completes its adoption of the open specification.

Does This Actually Change Cloud Strategy?

Here is my honest take: yes, but not overnight.

The interconnect removes the two biggest barriers to multicloud — networking complexity and egress costs. Those were real, legitimate reasons to stay single-cloud. With those barriers lowered, the remaining arguments for single-cloud are mostly about team expertise and operational simplicity, which are valid but less absolute.

What I do not expect is a sudden rush to multicloud. Most organisations will start by using the interconnect for specific use cases — DR, data analytics, or accessing a service that only one provider offers — rather than redesigning their entire architecture around multicloud principles.

The more interesting long-term effect is on vendor lock-in. Even if you never actually run workloads on two clouds simultaneously, the fact that you could move them — cheaply and quickly — changes the power dynamic in your cloud vendor relationship. That is arguably more valuable than the technical capabilities themselves.

For platform engineering teams, the open specification is the real prize. It means cross-cloud networking is no longer a bespoke, fragile integration but a standardised layer that you can build on with confidence. That is the kind of infrastructure foundation that lets you make workload placement decisions based on merit rather than inertia.

What to Watch Next

• Azure adoption timeline — Microsoft has committed to the spec but has not given a firm date. Watch for announcements at Build or Ignite later in 2026.
• Terraform provider updates — Both HashiCorp and the provider maintainers are adding interconnect resources. Check the changelogs for the AWS and Google providers.
• Egress pricing changes — The interconnect puts competitive pressure on standard egress pricing. Watch for broader egress reductions across all three providers.
• Regional availability — The interconnect is initially available in select regions. Track expansion as both providers build out the physical infrastructure.

Bottom line: AWS and Google Cloud have built the infrastructure layer that makes multicloud work as a practical architecture rather than a theoretical aspiration. Whether you adopt it today or in two years, it changes the landscape you are planning for.