What actually shipped on August 31
AWS and Microsoft announced mirror-image products on the same day. AWS calls its version AWS Interconnect, multicloud for Azure. Microsoft calls its version Azure Multicloud Interconnect. Both do the same job: they let a customer provision a private, encrypted connection between the two clouds from a console, CLI, or API call, rather than stitching together a site-to-site VPN or leasing capacity from a third-party network provider. The preview spans four regions, US East in Northern Virginia, US West in Northern California, Asia Pacific in Sydney, and Europe in Frankfurt. Connections attach directly to existing AWS Direct Connect gateways or Microsoft ExpressRoute circuits, so customers who already have those in place do not need to re-architect their edge.
Microsoft's side runs on a quad-redundant design, four Azure MSEE routers paired with four AWS routers over 400G-class infrastructure, with MACsec link-layer encryption turned on by default and a target availability SLA of 99.99 percent once the product matures out of preview. Igor Sakhnov, corporate vice president of Azure Networking, put the intent plainly: 'We are multi-cloud enterprise by design. With this announcement we are taking a burden on connecting clouds away from the customers.' AWS's own announcement describes the effort as resting on an open interoperability specification published on GitHub, the same approach it used when it brought Oracle Cloud Infrastructure and Google Cloud onto AWS Interconnect earlier this year.
The regulatory reversal nobody is saying out loud
This launch lands awkwardly next to both companies' own public record. AWS has told UK competition regulators that customers already multicloud freely and switch providers when they want to. Microsoft told the same regulators that multicloud demand outside a handful of specialized situations was minimal. Neither statement aged well against a product built specifically to make AWS and Azure easier to run together at data-plane speed. The honest reading is that enterprise customers, many of them assembled through years of acquisitions, regional data residency rules, or simple vendor hedging, have been running AWS and Azure side by side all along, and both vendors are now building the plumbing to keep that traffic on infrastructure they control end to end.
The competitive logic matters as much as the compliance angle. AWS Interconnect already connects AWS to Oracle Cloud Infrastructure and Google Cloud on a generally available basis, and Azure is the newest and largest name added to that list. That makes AWS the switchboard sitting in the middle of three of its own rivals' traffic, a position that is commercially valuable regardless of what either side says about multicloud demand in a regulatory filing. Microsoft gets the mirror benefit on the Azure side. Neither company is ceding customers to the other so much as making sure that when customers split workloads across both, the money and the packets still flow through infrastructure each vendor bills for.
Why this lands now, not two years ago
The timing tracks three pressures converging at once. AI workloads have pushed enterprises toward genuinely multi-vendor stacks, training on one cloud's GPU allocation while running inference or data platforms on another because capacity, not preference, dictates placement. Regulators in the EU have spent the last year probing whether AWS and Azure function as de facto gatekeepers under the Digital Markets Act, and interoperability is exactly the kind of commitment that blunts that argument before it hardens into a mandated remedy. M&A activity keeps forcing mismatched cloud estates together faster than migration teams can consolidate them, and every quarter that gap stays open is a quarter of shadow IT and duplicate spend that shows up in someone's board deck.
None of that required either vendor to build a joint product. It required them to stop pretending the problem was rare enough to ignore. The fact that AWS and Microsoft coordinated a same-day announcement, on a shared open specification, after years of separately telling regulators the opposite, is itself the signal. When two direct competitors ship compatible infrastructure on the same day, it usually means the market forced their hand faster than either wanted to move alone.
What this is actually good for right now
In preview, treat this as useful for exactly three things: disaster recovery replication between clouds, phased migrations where a workload needs to talk to both environments during cutover, and compliance-driven segregation where regulated data has to stay logically separate from a compute layer that lives on the other cloud. None of those need production-grade bandwidth guarantees on day one, and none of them are workloads you want to bet a Black Friday traffic spike on before AWS and Microsoft confirm general availability, final bandwidth tiers, and pricing. Neither company has published pricing yet, which for infrastructure billed by the gigabit is not a detail to skip past.
The bigger mistake would be to read this as license to defer a real multicloud strategy decision. If your organization is already running meaningful workloads on both AWS and Azure, whether by design or by acquisition, this preview is worth a proof of concept now so your network team understands the failure modes before finance asks why the interconnect bill doubled. If you are single-cloud by choice, this changes nothing about your roadmap except removing one more excuse a future acquirer's IT team might have had for staying fragmented.
The toll booth irony
There is a real tension worth naming here. A product that makes it easier to run two clouds together also makes it easier for each vendor to keep billing you regardless of which cloud actually does the work. AWS and Microsoft are not eliminating the switching cost of multicloud, they are monetizing the seam between two clouds that customers were already paying to connect themselves through third parties. That is a legitimate business to be in, and it genuinely saves engineering time versus the do-it-yourself circuits it replaces. It is not, however, a step toward cloud independence. It is a step toward both vendors owning more of the connective tissue between their own competing platforms.
For a CTO evaluating this, the practical question is not whether multicloud got easier, it did, but whether the easier path locks you further into paying both vendors for the privilege of using both vendors. Model the interconnect cost against what you currently spend on third-party circuits or VPN infrastructure before assuming this is a straightforward win. In many cases it will be. In some, the managed convenience will cost more than the DIY approach it replaces, and that math is worth doing before general availability, not after.
The roadmap call
Put this on the radar for your next infrastructure planning cycle, not your current sprint. Ask your network and platform teams to spin up the preview against a non-critical workload this quarter so you have real latency and reliability numbers before AWS and Microsoft finalize pricing. If you are negotiating cloud commitments with either vendor in the next two quarters, raise this explicitly, since a multicloud-capable interconnect changes the leverage calculus around minimum spend commitments and egress fees that have historically been used to discourage exactly this kind of cross-cloud architecture.
The deeper takeaway for the CIO audience is that multicloud is no longer a strategy you have to justify against vendor resistance. It is now a product both of your largest vendors are actively selling you. That shift is worth internalizing before your next contract renewal conversation, because the vendor sitting across the table just quietly admitted the leverage they have held for a decade, that switching clouds was expensive and painful, is eroding, and they built the tool that erodes it themselves.
