Key details

  1. AWS–Azure managed multicloud connectivity entered public preview on August 31, 2026.
  2. The pairing uses AWS Interconnect – multicloud and Azure Multicloud Interconnect.
  3. AWS says customers can provision the preview through its console, CLI or API.
  4. AWS preview regions include US East (N. Virginia), US West (N. California), Asia Pacific (Sydney) and Europe (Frankfurt).
  5. Azure says its preview uses private networking connected through ExpressRoute rather than the public Internet.
  6. Preview connectivity is region-constrained; Azure says cross-region connections are not supported during preview.
  7. AWS Interconnect – multicloud also supports Google Cloud and OCI, with those pairings further along in availability.

What builders should take away

  1. Check exact supported region pairs before designing around the service; preview coverage is not global.
  2. Model egress, routing and failure behavior separately from link provisioning—the managed interconnect does not make AWS and Azure one network or one billing domain.
  3. Use the preview first for workloads where removing carrier/router complexity has clear operational value, not simply because a multicloud link is now easier to create.
  4. Keep a fallback connectivity plan until the AWS–Azure pairing reaches GA and its operational limits, support model and pricing are stable.
  5. Treat identity and application authorization as separate layers; a private network path does not itself create cross-cloud trust.

What changed

On August 31, AWS and Microsoft opened managed AWS–Azure private connectivity in public preview. AWS customers can create an AWS Interconnect – multicloud connection to Microsoft Azure, while Azure exposes the corresponding Azure Multicloud Interconnect path over its private networking infrastructure. The products are intended to remove much of the do-it-yourself work previously required to combine physical connectivity, routing appliances, carrier provisioning and cross-cloud BGP. AWS says the Azure preview is available from selected AWS regions including Northern Virginia, Northern California, Sydney and Frankfurt, and can be provisioned through its console, CLI or API.

Why it matters

Multicloud architectures often become networking projects before they become application projects. A first-party managed AWS–Azure path reduces the amount of custom carrier and routing infrastructure teams need to own, which can simplify disaster recovery, data movement and applications split across the two ecosystems. It does not erase cloud boundaries: identity, routing policy, egress economics, service limits and regional availability still need to be designed, and the Azure pairing remains a preview rather than a generally available production commitment.

The clouds now manage the physical interconnect boundary

AWS describes prebuilt capacity pools and a managed connection between its networking services and the partner cloud. Azure similarly exposes private connectivity through its multicloud interconnect product. Instead of procuring and operating every intermediate networking layer, customers request bandwidth and endpoints through cloud-native controls.

The design is private rather than an Internet VPN overlay

The connection runs over provider-managed private networking rather than routing application traffic over the public Internet. AWS says physical links between provider routers are encrypted and can be provisioned with resilient connection patterns; Azure describes dedicated private paths based on its ExpressRoute infrastructure.

Preview availability is geographically constrained

AWS lists Azure preview availability in a subset of regions, while Azure notes that preview connections are limited to local supported regions and do not yet support arbitrary cross-region connectivity. Architecture reviews therefore need to start with the actual region pair, not assume universal cloud-to-cloud reach.

AWS is standardizing the same interconnect model across providers

Azure joins Google Cloud and Oracle Cloud in AWS Interconnect – multicloud’s provider model. Google Cloud and OCI support have already progressed further than the new Azure pairing, making the August launch part of a broader move toward cloud-provider-managed interconnects rather than one-off AWS–Azure plumbing.

What to watch next

  • General availability timing for the AWS–Azure pairing.
  • Final pricing and bandwidth options across supported region pairs.
  • Expansion beyond the initial regional footprint and removal of preview cross-region restrictions.
  • Operational evidence around failover time, provisioning changes and multi-provider support ownership.
  • Whether other cloud providers adopt the same open interconnect specification and reduce bespoke multicloud networking further.

Still unclear

  • The AWS–Azure pairing is still in preview, so region coverage, limits and operating semantics can change.
  • The providers describe simplified operations, but customer-specific routing, security and cost design still depends on the attached services and traffic pattern.
  • Public documentation does not yet provide enough broad production evidence to compare reliability or total cost with every carrier-based alternative.

Sources

Direct reading behind this dossier.

3 sources
Azure Multicloud Interconnect
Microsoft Azure primary_documentation

Primary Azure product description for private connectivity, ExpressRoute integration and preview region constraints.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment