Microsoft and AWS announced a joint service this week that neither company would have shipped five years ago: a managed private connection between the two clouds, provisioned from both portals, operated by both providers. Azure Multicloud Interconnect is in public preview now, with AWS as the first supported partner, and it replaces what has historically been one of the most tedious projects in enterprise networking.
I have sat on the customer side of this exercise. It goes something like this: order an ExpressRoute circuit, order a Direct Connect circuit, find a colocation facility or connectivity provider that touches both, rack or rent routers, negotiate BGP sessions across three organizations, bolt on MACsec or an IPsec overlay, and then accept that when the link degrades you get to play coordinator between two cloud support desks and a telco. The vendors have spent a decade insisting multicloud was rare. Their customers kept quietly building all of this anyway.
What actually shipped
Azure Multicloud Interconnect is a single logical resource that represents the private path between your Azure environment and your AWS environment. Under the hood it still rides on ExpressRoute and AWS Direct Connect, which is the sensible part of the design: Microsoft and AWS are not inventing a new transport, they are wrapping the two backbones enterprises already trust in a jointly managed lifecycle. Circuits, routing, and encryption get coordinated by the platforms instead of by your network team.
The engineering details from the Azure networking blog post are worth reading closely. The data path is quad redundant by design: four Azure Microsoft Enterprise Edge routers and four AWS routers spread across diverse sites, with a LAG-based design in the 400G class. MACsec link-layer encryption is on by default, no extra configuration. Microsoft targets a 99.99% availability SLA, and the service is IPv6 ready and supports APIPA addressing. At general availability, customers can deploy connectivity at up to 100 Gbps from day one, with elastic scaling after that.
Robert Kennedy, VP of Network Services at AWS, put the joint pitch plainly in Microsoft’s announcement: MACsec out of the box, four-nines availability, and capacity you can turn up with a click. That quote is marketing, but the claims behind it map to real architecture decisions, and the fact that both companies signed their names to the same specification is the actual news here.
The open specification angle
The interoperability layer is an Open API specification that AWS first published at re:Invent 2025. AWS has since used it to connect to Oracle Cloud Infrastructure and Google Cloud, both generally available on the AWS side. Azure joining makes this the first AWS-to-Azure managed link built on a shared standard rather than a bespoke pairing. Microsoft says Google Cloud support for the managed interconnect model is coming next.
This matters more than the bandwidth numbers. If the specification holds, the long-term picture is boring in the best way: cloud-to-cloud, cloud-to-carrier, and cloud-to-metro connectivity provisioned through standardized APIs instead of paperwork. Microsoft’s Narayan Annamalai framed it as a step toward hyperscalers and network service providers sharing one interoperability framework, including last-mile carrier connectivity. Skepticism is fair, since both companies profit from egress fees and switching costs, but the specification is public and any provider can adopt it.
Why now
AI workloads are the honest reason. Training and inference pipelines increasingly pull data from one cloud into compute in another, and nobody wants petabytes crossing the public internet or a VPN. The service extends to Azure Private Link, giving an end-to-end private path between clouds, which also matters for data residency and regulated workloads. Microsoft’s use-case list includes cross-cloud disaster recovery, dataset replication, and workload migration, all of which used to mean senior engineers babysitting intercloud links.
What to check before you care
Three things. First, this is a preview: feature set, performance targets, and timelines can move before general availability, and Microsoft says so explicitly. Second, pricing is not published yet, and cross-cloud data transfer economics are exactly where these deals hide their costs. Third, availability: AWS’s side of the preview covers US East (N. Virginia), US West (N. California), Sydney, and Frankfurt, so if your estates sit elsewhere you are waiting anyway. Access is through your Microsoft or AWS account team for now.
The Register’s take was that Microsoft and AWS built a bridge for a problem they used to claim barely existed, and there is some truth in that. But multi-week provisioning cycles for a BGP handoff were always a bit absurd, and a jointly managed replacement is what customers actually asked for. Igor Sakhnov, CVP of Azure Networking, said the goal was to take the burden of connecting clouds away from customers. For once, the announcement matches the complaint.
How I would evaluate it
If your organization runs real estates on both clouds, this is worth a preview evaluation even with the caveats. The test I would run is not a bandwidth benchmark, it is an operational one: stand up the preview connection in a non-production pairing, then deliberately break things. Fail a router site, throttle a circuit, and watch how the two portals report the same incident. Historically, the hardest part of cross-cloud networking was not building the path, it was the blame game during an outage. A managed service only wins if it collapses that diagnosis from a four-party email thread into one support surface. The architecture says Microsoft and AWS coordinated failover paths up front, which is exactly what removes the mismatched BGP and asymmetric failover failures that plague DIY designs.
The other thing to watch is what happens to ExpressRoute Direct and Direct Connect pricing once customers no longer buy the two halves separately. Managed convenience historically prices at a premium to DIY. If the day-one 100 Gbps option lands near the cost of two standalone circuits plus a carrier cross-connect, this becomes the default answer for any serious Azure-AWS footprint. If it lands meaningfully above, the DIY stack survives in cost-sensitive shops, and both vendors will have shipped a bridge nobody crosses because the toll is too high.