Multicloud Networking Is Becoming a Cloud Service: What AWS, Google and Azure Are Standardizing

AWS, Google Cloud and Azure are turning cross-cloud connectivity into a managed service. The important change is not that all cloud networking is standardized, but that providers are beginning to standardize the interconnect layer itself.

For years, using more than one cloud created an awkward networking problem.

A company could run applications in AWS, analytics in Google Cloud and Microsoft services in Azure. But connecting those environments privately often meant building another layer underneath them: dedicated circuits, colocation facilities, routers, VPNs, BGP configuration, third-party network providers and separate support arrangements.

The cloud resources were available on demand.

The network connecting the clouds often was not.

That is beginning to change.

AWS, Google Cloud and Microsoft Azure are moving toward a model where cloud-to-cloud connectivity itself can be ordered, configured and managed more like a cloud service.

And something more important is happening underneath that change: parts of the connection between cloud providers are beginning to use common specifications and APIs.

This does not mean multicloud networking has become one standardized system.

But it does mean an important part of the infrastructure is moving away from custom engineering.

The old multicloud network

Imagine a company with this setup:

Its customer application runs in AWS.
Its data platform runs in Google Cloud.
Microsoft services and some internal systems run in Azure.

The company wants private communication between all three.

Traditionally, that could involve several independent pieces.

The network team might have to order cloud interconnect ports, work with a carrier or colocation provider, configure VLANs, establish BGP sessions, design redundant connections and coordinate changes between multiple providers.

Google’s documentation still describes this traditional Cross-Cloud Interconnect model clearly. For a direct connection between Google Cloud and another provider, customers may need redundant ports, corresponding ports from the remote cloud and BGP configuration on both sides.

The technology works.

The problem is the operational burden.

What cloud providers are now trying to remove is not routing itself. BGP, private networks and physical connectivity still exist underneath.

What is changing is who has to assemble and operate those pieces.

AWS and Google changed the model

A major step came from AWS and Google Cloud.

In late 2025, the companies announced a jointly engineered multicloud networking system using AWS Interconnect (multicloud) and Google Cloud’s Cross-Cloud Interconnect.

Instead of requiring customers to coordinate the physical connection themselves, the new model provides managed cloud-to-cloud connectivity that can be provisioned through cloud interfaces and APIs. AWS and Google said the system was designed to reduce provisioning from weeks or months to minutes for supported connections.

Google describes the jointly engineered model as an on-demand service where the providers manage more of the underlying connectivity and redundancy.

That is an important architectural shift.

The customer is no longer buying several networking components and assembling them into a multicloud connection.

The customer is consuming a connection as a managed service.

The more important part: an open specification

The AWS-Google collaboration went beyond a product integration.

The two companies developed an open specification for network interoperability.

AWS describes the specification as a set of standardized specifications and APIs that other cloud providers can adopt. The underlying API specification is published publicly and licensed under Apache 2.0.

Google describes the work similarly: a jointly engineered open specification intended to allow other providers to contribute and implement the model in their own environments.

This is where the word standardization becomes meaningful.

The clouds are not standardizing everything about networking.

They are beginning to standardize how providers establish and automate parts of the connection between their networks.

That is a narrower claim, but a more defensible and useful one.

Microsoft Azure has now joined the same direction

In August 2026, Microsoft and AWS expanded this model to Azure.

Azure Multicloud Interconnect is currently in preview and supports AWS during that preview. Microsoft describes it as managed private cloud-to-cloud connectivity built on Azure ExpressRoute, with automated provisioning and managed resiliency.

Customers create an Azure Multicloud Interconnect resource and exchange an activation key with the other provider. Microsoft says this removes the need for the customer to coordinate individual provider circuits, routers, VLANs, point-to-point addressing and BGP sessions for the supported model.

AWS, from its side, describes Azure as adopting the open specification that powers AWS Interconnect (multicloud).

So this is no longer only an AWS-Google experiment.

The model is expanding.

Google has been building toward this for several years

Google’s strategy is broader than the new jointly managed interconnect model.

Cross-Cloud Interconnect has supported dedicated connectivity between Google Cloud and AWS, Azure, OCI and Alibaba Cloud. Google also uses Network Connectivity Center to let customers use Google’s network as a wide area network between external sites and clouds.

For example, Google documents an architecture where an Azure network and an AWS network each connect into Google Cloud and Network Connectivity Center carries traffic between them.

This starts to blur an older boundary.

A cloud provider is no longer only offering compute, storage and networking inside its own cloud.

It can also become part of the transport layer connecting other environments.

AWS is making the same transition

AWS Interconnect (multicloud) is a managed private Layer 3 connectivity service between AWS and other cloud providers.

Google Cloud is generally available through this model. OCI is also generally available, while Azure support is currently in preview.

AWS can connect Interconnect (multicloud) into services such as Transit Gateway and Cloud WAN. Cloud WAN can provide a global routing and policy layer around those connections.

This matters because the value is no longer just the physical circuit.

The larger model becomes: connectivity, routing, policy, monitoring, resiliency and automation, delivered through cloud control planes.

That looks much more like a cloud service than traditional enterprise networking.

Azure is also moving beyond the traditional ExpressRoute model

Azure has supported multicloud networking for years through combinations of ExpressRoute, VPN and other network services.

Azure Multicloud Interconnect changes the experience by adding a managed provider-to-provider layer on top of the ExpressRoute foundation.

Microsoft explains the distinction directly: ExpressRoute remains the private-connectivity foundation, while Multicloud Interconnect adds managed cloud-to-cloud connectivity, automated provisioning with supported providers and built-in resiliency management.

That is the same broader pattern visible at AWS and Google.

The cloud providers are not replacing networking.

They are absorbing more of its operational complexity.

What is actually becoming standardized?

It is useful to separate two developments.

1. The operational model is converging

AWS, Google and Azure are increasingly moving toward:

Private cloud-to-cloud connectivity.
Managed provisioning.
Built-in redundancy.
Automated provider coordination.
Cloud APIs and consoles.
Centralized routing and policy around the interconnect.
Integrated monitoring.
Less customer-managed physical infrastructure.

This is convergence.

All three providers are moving toward a similar operational experience, even when the products underneath remain different.

2. Parts of provider interoperability are becoming standardized

The AWS-Google work introduced an open specification.

AWS published the underlying API specification for other providers to implement.

Azure has now adopted the same AWS Interconnect specification for its AWS connectivity preview.

That is actual standardization, although currently at a limited layer of the overall networking stack.

The distinction matters.

Figure 1: From custom circuits to managed cloud-to-cloud connectivity. Provider-specific routing, security, pricing and control planes still remain.

Accessible text alternative for Figure 1

Traditional model: Cloud A, then carrier or colocation facility, then router, then manually configured BGP and VLANs, then another router, then Cloud B. Emerging model: Cloud A, then a managed interconnect resource and API, then provider-managed interconnect, then Cloud B. A closing note states the physical pieces still exist underneath both models, and provider-specific routing, security, pricing and control planes still remain.

What is not standardized

An enterprise should not read these announcements and assume AWS, Azure and Google Cloud have become one network.

They have not.

Each provider still has its own:

Virtual network model.
Routing controls.
Security policies.
Identity system.
Private-service connectivity.
Observability tools.
Pricing.
Quotas.
Regional availability.
Operational APIs outside the emerging interconnect specification.

AWS Cloud WAN is not Azure Virtual WAN.

Azure Private Link is not Google Private Service Connect.

A VPC in AWS is not operationally identical to a VNet in Azure or a VPC in Google Cloud.

The open interconnect model simplifies an important boundary between providers.

It does not remove the boundaries inside them.

A practical enterprise example

Consider a company that runs its customer-facing system in AWS.

Its analytics team uses Google Cloud because several data services are already there.

Its corporate applications and Microsoft-based workloads run in Azure.

In the older model, the infrastructure team could end up creating three separate networking projects:

AWS to Google Cloud.
AWS to Azure.
Azure to Google Cloud.

Each might involve different carriers, circuits, routing designs and support procedures.

The emerging model is different.

For supported cloud pairs, the organization increasingly starts with a managed cloud resource: connect this cloud network to that cloud network, at this location, with this bandwidth.

The providers deal with more of the physical connectivity, redundancy and provisioning underneath.

The network architects still need to make important decisions:

Which workloads are allowed to communicate?
Which prefixes should be advertised?
Where should inspection happen?
What happens if one provider or region fails?
How much data will cross cloud boundaries?
What will that traffic cost?
Which provider becomes the transit point?

The work does not disappear.

But it moves upward.

Instead of spending as much time constructing connectivity, teams can spend more time deciding how that connectivity should be used.

There is also a new architectural risk

Managed multicloud networking may simplify infrastructure, but it can also create another form of dependency.

If an organization uses one provider’s global network as the transit layer between several environments, that provider becomes strategically important even when workloads remain distributed across clouds.

Google, for example, documents using Network Connectivity Center and its network to carry traffic between AWS and Azure networks.

AWS Cloud WAN can similarly become the global routing and policy layer around AWS Interconnect attachments.

That may be exactly what an enterprise wants.

But “multicloud” does not automatically mean “provider independent.”

The network architecture still determines where operational dependency sits.

Cost also becomes more important

Making multicloud connectivity easier could encourage applications to communicate across cloud boundaries more frequently.

That does not make data movement free.

Customers still need to understand:

Interconnect capacity charges.
Data-transfer charges.
Regional pricing.
Provider-specific egress rules.
The cost of traffic inspection.
The cost of routing through additional regions or hubs.

AWS, for example, prices Interconnect by bandwidth and geographic scope, while the other cloud provider determines its own charges.

Better automation removes provisioning friction.

It does not remove network economics.

Why this change matters

Cloud computing changed infrastructure partly because servers, storage and databases stopped being projects that had to be physically assembled before they could be used.

Networking has taken longer to reach the same level of abstraction.

Cross-cloud networking is now beginning to follow that path.

The physical links still exist. BGP still exists. Routers still exist. Redundancy still matters.

But increasingly, those details are becoming part of a managed provider service rather than something every enterprise must assemble itself.

That is the real change.

Where we are today

We are not yet at a universal multicloud network.

Google’s established Cross-Cloud Interconnect supports several providers, but the newer jointly managed model has different maturity by cloud pair. AWS Interconnect (multicloud) is generally available with Google Cloud and OCI, while Azure connectivity is still in preview as of September 2026.

So the technology should not be described as finished.

A better description is: the industry is standardizing the first layer of cloud-to-cloud connectivity while the rest of multicloud networking gradually converges around managed services.

That is a meaningful shift.

A few years ago, multicloud networking largely meant assembling several cloud and carrier products yourself.

Increasingly, it means asking a cloud platform to provide the connection.

And that may eventually make the network between clouds feel much like the clouds themselves: programmable, managed and available on demand.