The received reading of Azure Multicloud Interconnect is that Microsoft just fixed multi-cloud networking. It didn’t. It fixed the one part of multi-cloud networking that was already the least likely to hurt you, and left the three parts that actually drain the budget and break the incident bridge exactly where they were.
Let me steelman the enthusiasm first, because it isn’t stupid. If you run workloads in both Azure and AWS today, your options have genuinely been bad. Path one: ExpressRoute out of Azure to a colo, cross-connect to a partner, Direct Connect into AWS. That’s two circuits, two carriers, at least one meet-me-room, and — the part that ruins your quarter during an outage — two SLAs owned by two vendors who will each point at the other. Path two: site-to-site VPN over the public internet, which is simpler to stand up and worse in every way that matters, since your inter-cloud traffic now shares fate with every BGP hijack and transit-provider brownout between the two regions. Against that backdrop, a Microsoft-managed private link that provisions from the Azure control plane, keeps traffic off the public internet, and lands on one bill is a real improvement. I’m not going to pretend otherwise.
But the improvement is narrow, and the announcement is doing a lot of work to make it feel broad.
What the thing actually is
Multicloud Interconnect is a managed private-connectivity service that stands up a routed path between an Azure VNet and an AWS VPC without traversing the public internet. It is not a VPN, and it is not ExpressRoute with a new logo. It’s a new Azure-to-cloud path — AWS being the first supported destination — provisioned and operated from the Azure side.
The pitch turns on where the traffic lives: the announcement positions inter-cloud traffic as staying on Microsoft’s backbone rather than riding the public internet. Here’s the thing the update page is coy about, though. It doesn’t say plainly whether Microsoft owns the physical middle mile end to end, or whether the AWS-side handoff rides partner infrastructure at some peering point. Those are genuinely different risk profiles — “one provider owns the wire” and “one provider owns the relationship and subcontracts the last leg” collapse a multi-vendor SLA in very different ways. Until Microsoft documents the topology, treat the ownership question as open. The operational win — one provider to call, one control plane to provision from — holds either way. The physical-path guarantee does not, until they say so.
Where I get off the bus is the numbers. The announcement is light on the three that decide whether this is a toy or a tool: the data-transfer rate, the latency and availability SLA, and the exact region pairs supported in preview. Let me take those one at a time, because “light” is doing a lot of work.
The billing model, as documented today, is: unstated. The update page doesn’t publish a rate card. No per-GB figure, no dedicated-circuit price, no statement of whether you pay a Microsoft data-processing charge on top of each cloud’s own egress. So I can’t tell you whether this meters like ExpressRoute (circuit plus data) or like a per-gigabyte transfer service, because the announcement doesn’t. Anyone quoting you a cost comparison against ExpressRoute-plus-Direct-Connect right now is comparing against a blank.
On the SLA: assume there isn’t one. That’s not a quote from this announcement — I want to be clear it isn’t — it’s the general pattern of Microsoft’s preview terms, which ship without a financially-backed SLA until GA. Read the specific preview terms when you evaluate, but don’t put a production trading feed or a synchronous database replication link across a preview interconnect and act surprised.
On regions: the announcement names AWS as the first supported cloud but, as published, does not enumerate the Azure-region / AWS-region pairs available in preview. So whether Azure West US talks to AWS eu-west-1 — and whether cross-geography pairs work at all, or you’re constrained to same-metro landings — is a question you answer by trying it, not by reading the page. For a service whose entire value proposition is where the packets go, that’s a conspicuous omission.
The first thing it doesn’t fix: the egress bill
This is the one that gets people. The expensive part of running in two clouds has never been the circuit. It’s the data-transfer charge on every byte that leaves a cloud. A private path changes where the packets go; it does not repeal AWS’s cross-region and internet egress pricing, and it does not repeal Azure’s. You are still going to pay to move data out of each cloud, and — since the announcement doesn’t rule it out — you may now be paying a Microsoft data-processing charge on top.
So before anyone gets excited, model the traffic. The architecture that wins in dual-cloud is the one that moves the least data across the boundary, and a smoother pipe quietly encourages you to move more. That’s the trap. A better wire that makes cross-cloud chattiness feel free is how you wake up to a six-figure transfer line item that a message queue and some caching would have erased.
If that number is small, the interconnect is a convenience. If it’s large, the interconnect is a cost multiplier wearing a convenience costume, and the real fix is architectural — keep the data next to the compute that chews on it.
The second thing it doesn’t fix: the split control plane
A private link moves packets. It does not federate identity, it does not merge your two policy engines, and it does not give you one place to answer “who can reach this and why.” After you provision the interconnect you still have Azure RBAC and AWS IAM as two separate authorization systems, two audit logs, two sets of network security constructs (NSGs and Azure Firewall on one side, security groups and NACLs on the other), and two blast radii.
The interconnect actually makes this harder to reason about, not easier, because it creates a low-friction, private, high-throughput path between two trust domains that were previously separated by the friction of the public internet. That friction was doing security work for you. Remove it and you’d better have deliberate segmentation on both ends, because a compromised workload in one cloud now has a fast, quiet route into the other. Turn on flow logs on both sides on day one and treat the interconnect as an internal-but-untrusted zone. A managed private path does nothing for the east-west authorization problem — that’s yours.
The third thing it doesn’t fix: preview means no promises
No documented SLA, no published bandwidth ceilings, and a supported-service matrix the update page waves at rather than pins down. Can you point AKS at EKS across it? Azure SQL at RDS? At preview, assume it’s a routed IP path and nothing more — your managed services have their own firewalling, private-endpoint, and authentication rules that don’t magically become cross-cloud aware because the packets found a private road. Anyone selling you “peer your databases across clouds” on the strength of a preview announcement is describing a demo, not an architecture.
Gate it in your landing zone until you’ve vetted it. If your platform team hasn’t decided this belongs in production, deny the resource type outright rather than discovering it in a subscription during an audit:
The one thing it genuinely does fix
It kills the multi-vendor SLA seam and gets your inter-cloud traffic off the public internet in one managed step. That is not nothing. If you’re already committed to dual-cloud and you’re currently running VPN over the internet because ExpressRoute-plus-Direct-Connect was too much ceremony to stand up, this is a straight upgrade to your security posture and your provisioning time. One provider, one control plane, one throat to choke. For that specific, common situation, pilot it.
Why now, and what it isn’t
Read this as a competitive move — that’s my framing, not a claim from Microsoft’s announcement, which offers no market context at all. For what it’s worth, external to this release: managed cloud-to-cloud connectivity has been a live category in the wider market for a while, and Azure keeping AWS-adjacent traffic on its own backbone and its own invoice is a perfectly rational business for the company that would like your multi-cloud traffic to be its business. I’m flagging that as outside context, not sourcing it to the update page.
None of which means you rip out ExpressRoute or Direct Connect. You still need ExpressRoute for the thing it’s actually for: private connectivity to your own on-prem data centres. You still need Direct Connect for your AWS-to-on-prem hybrid. And you need those paths for any cloud that isn’t AWS, because “first supported cloud” is the announcement telling you the matrix is one entry long. Multicloud Interconnect is an additional path for one specific leg of the journey, not a consolidation of your WAN.
Provision it when the traffic model says the boundary is small and the risk model says the internet is the wrong place for it. Everywhere else, the wire was never your problem — and a faster wire won’t fix the things that are.
