Azure Multicloud Interconnect, how Azure and AWS now connect without a middleman

A private connection between an Azure VNet and an AWS VPC has traditionally required assembling Azure ExpressRoute, AWS Direct Connect, a connectivity provider or colocation footprint, customer-managed routers, BGP sessions, and link-layer encryption, then owning the resiliency design and day-to-day operations across all of it. The result was typically slow to deliver, difficult to troubleshoot, and inconsistent in performance.

On August 31, 2026, Microsoft and AWS jointly announced Azure Multicloud Interconnect, a co-engineered managed service that replaces that assembly with a single interconnect resource, turning the private path between clouds into something you provision rather than something you build.

For the official overview and creation guide: What is Azure Multicloud Interconnect?

What the service actually is

Azure Multicloud Interconnect isn't a rebranding of ExpressRoute with a different interface but rather a new resource type that sits on top of ExpressRoute's infrastructure and abstracts everything on both sides of the connection. Under the covers, Microsoft and AWS coordinate the circuits, routing, and encryption on your behalf using the open API specification for network interoperability that AWS introduced at re:Invent 2025 and brought to general availability in April 2026. Microsoft adopted that specification for Azure.

The physical design is quad-redundant with a 400G-class backbone and MACsec encryption at the hardware layer, which means the encryption happens at the link level without consuming host CPU resources on either end. Without any of that configuration on your part, you create an interconnect resource, exchange an activation key with the AWS side, and the managed path between your Azure Virtual Network and your AWS VPC is ready.

The distinction from ExpressRoute comes down to what you're managing: with a traditional ExpressRoute circuit connected to AWS through a carrier, you're the systems integrator for the full stack, while with Azure Multicloud Interconnect, Microsoft and AWS own the underlying complexity and you consume the outcome.

For a detailed look at how the service fits into the existing connectivity landscape: Azure Multicloud Interconnect FAQ

How provisioning works

The setup process moves through four stages. The first is creating an ExpressRoute circuit and selecting the Azure Multicloud Interconnect port type rather than a carrier-based port. The second is creating the Interconnect resource itself, which generates the activation key that coordinates the connection between providers. The third is provider setup on the AWS side, where you redeem the activation key and select the Direct Connect Gateway that the connection terminates on. The fourth is connecting your Azure Virtual Networks through an ExpressRoute gateway so that workloads in your Azure VNet and workloads in your AWS VPC can communicate over the managed path.

Both sides must use separate, non-overlapping IP address spaces, which is a standard requirement for any BGP-routed private connection.

On the AWS side, the experience mirrors what AWS already provides for Google Cloud and Oracle Cloud Infrastructure through AWS Interconnect, so teams that have already connected AWS to another cloud provider using that service will find the workflow familiar.

What the preview limits mean in practice

The Azure preview launched with constraints worth understanding before building production plans on top of it.

Throughput during preview is capped at 1 Gbps, while the Google Cloud pairing, which reached general availability in April 2026, already supports up to 100 Gbps. AWS confirmed that general availability for the Azure connection is expected to reach the same ceiling eventually, but the timeline isn't published. For workloads that move large volumes of data between clouds, whether for AI training pipelines, database replication, or large-scale analytics, 1 Gbps is a meaningful constraint. For control-plane traffic, API calls between microservices split across providers, or proof-of-concept deployments, it's sufficient.

There's no SLA during preview, which is standard for preview services but matters for teams evaluating the service for anything that needs an uptime commitment from the provider.

Regional availability in preview covers four Azure regions: Australia East, East US, Germany West Central, and West US, each paired with a corresponding AWS region: Asia Pacific (Sydney), US East (N. Virginia), Europe (Frankfurt), and US West (N. California). Cross-region connectivity isn't supported during preview, meaning an Azure VNet in East US connects to the AWS US East (N. Virginia) pair and can't route through a different region pair.

The official source for current supported regions, bandwidth tiers, and SLA status: Azure Multicloud Interconnect product page

How it differs from ExpressRoute

The FAQ for the service makes the distinction explicit: choose Azure Multicloud Interconnect for managed connectivity between Azure and a supported cloud service provider, and choose ExpressRoute for on-premises, colocation, carrier-based connectivity, or Microsoft peering scenarios. The two aren't alternatives for the same use case because they're designed for different connectivity targets that happen to share the same underlying technology.

An important implication is that existing ExpressRoute circuits don't automatically become Multicloud Interconnect resources, so if you're already connecting Azure and AWS through an ExpressRoute circuit over a carrier, the new service requires provisioning a new resource with the Azure Multicloud Interconnect port type, which is a separate circuit from what you may already be paying for.

The broader context

Azure Multicloud Interconnect launched as part of a pattern AWS established with the open interoperability specification it published at re:Invent 2025. Google Cloud was the first provider to adopt the specification and reached general availability with AWS in April 2026. Oracle Cloud Infrastructure entered preview in May and reached general availability in July, and Azure followed into preview in August.

That sequence matters for teams comparing the maturity of each pairing. The Google Cloud and OCI connections through AWS Interconnect have already moved through preview and into production-grade service with published SLAs and higher bandwidth tiers. The Azure pairing is earlier in that lifecycle, but the underlying specification is the same and the GA trajectory follows the same path the other pairings already completed.

For the full technical announcement from the Azure Networking team: Simpler, private connectivity between Azure and AWS with Azure Multicloud Interconnect

References

Information based on official Microsoft and AWS documentation as of September 2026. Azure Multicloud Interconnect is in public preview and service capabilities including supported regions, bandwidth tiers, and SLA status are subject to change. Always verify current status at Microsoft Learn before building production architectures on preview features.