On August 31, 2026, Microsoft and Amazon Web Services (AWS) released a public preview of a service that connects Azure and AWS through a private line managed jointly by both companies. Combining Azure Multicloud Interconnect with AWS Interconnect – multicloud, the service handles everything from physical line provisioning to router configuration, BGP, and encryption through coordinated setup between the two clouds. While the announcement highlights headline figures like up to 100Gbps and 99.99% availability, the bandwidth actually available today is capped at 1Gbps, coverage is limited to four regions, and there is no formal service level agreement (SLA) yet. What has moved first is the operating model—turning cross-cloud connectivity from a procurement project into a cloud resource.
From Line Construction to Cloud Resource
When starting from the Azure side, a customer creates an ExpressRoute circuit, selects the connection point and region, and specifies the bandwidth along with the AWS account ID. This generates an activation key—an authentication key that matches connection requests across both clouds—which is then redeemed on the AWS side. Both companies verify the carrier and region, confirm that the bandwidth and customer account match, and allocate capacity from pre-built infrastructure. The reverse flow, where AWS issues the activation key and Azure accepts it, is also supported.
The activation key is not an encryption key for the traffic itself. It is a mechanism to confirm that the connection request on the other cloud refers to the same customer and configuration, triggering the provisioning process on both sides. The publicly available Connection Coordinator API Specification—an open specification that coordinates the creation and state synchronization of cross-cloud connections—defines APIs covering everything from connection creation to status notifications, maintenance schedules, encryption key rotation, and fault tickets. Even though the two clouds have separate management consoles, the underlying lifecycle can be synchronized using a shared vocabulary.
Customer-side work does not disappear entirely. On Azure, the connection reaches a VNet through an ExpressRoute virtual network gateway; on AWS, a Direct Connect Gateway serves as the connection point, linking to a Virtual Private Gateway, Transit Gateway, or AWS Cloud WAN. Customers still need to prepare non-overlapping IP address spaces across both clouds and decide which prefixes to advertise over the interconnect. What gets eliminated is the need to arrange third-party circuits and colocation facilities, or to provision customer-managed routers. VLAN configuration, point-to-point addressing, and BGP session setup are handled by both providers.
The Current Preview Is 1Gbps With No SLA
The joint announcement and product documentation mix together specifications available today with the vision planned for general availability. Based on the preview limitations documented in Microsoft Learn, the differences break down as follows.
| Item | Current Public Preview | Vision for General Availability |
|---|---|---|
| Bandwidth | 1Gbps | Up to 100Gbps |
| Supported Regions | Combinations of 4 Azure regions and 4 AWS regions | Expansion planned, but region list not yet disclosed |
| Availability | No SLA for Azure Multicloud Interconnect | Target of 99.99%, formal SLA not yet disclosed |
| Azure-side Pricing | No service fee or Azure-side data egress fee | Not yet disclosed |
| Availability Timeline | Preview starting August 31, 2026 | Not yet disclosed |
The bandwidth ceiling in the current preview is 1Gbps—one hundredth of the 100Gbps maximum touted for general availability. The preview has no SLA, and the 99.99% figure is a target rather than a formal guarantee. This gap reflects a difference in the connection capacity customers can select today, not a claim that actual throughput or application performance will improve by a factor of 100.
The North American region pairings are AWS US East (N. Virginia) with Azure East US, and AWS US West (N. California) with Azure West US. Sydney paired with Australia East, and Frankfurt paired with Germany West Central, are also supported. Azure is waiving both the service fee and Azure-side data egress fee during the preview period. AWS, meanwhile, applies its standard pricing model of hourly charges based on bandwidth and distance, treating billing on the partner cloud's side as a separate contract. Because the joint announcement does not mention any AWS-side fee waiver specific to the Azure integration preview, the entire cross-cloud path cannot be described as free.
The Scope of Link-Layer Encryption and Quadruple Redundancy
Beneath a single logical Interconnect sit at least four logical paths distributed across a minimum of two physical facilities. Traffic is load-balanced using Equal-Cost Multi-Path (ECMP), and AWS states that if one facility is lost, communication continues through the remaining facilities. Although customers see what appears to be a single connection resource, the underlying infrastructure and paths are quadruple-redundant.
Encryption relies on MACsec (IEEE 802.1AE link-layer encryption). The scope guaranteed by AWS documentation covers the physical link connecting the AWS edge router to the adjacent router on the partner cloud, and customer traffic only flows while the encryption session is active. Combined with a dedicated path that bypasses the public internet, this protects the boundary between clouds—but it is not a mechanism that wraps an entire application-to-application session in a single encrypted tunnel. Customers must design upper-layer protections such as TLS, along with access controls within each cloud, separately.
Monitoring also has boundaries. Each Interconnect comes with a CloudWatch Network Synthetic Monitor at no additional charge, which measures round-trip latency and packet loss and allows threshold alarms to be configured. However, current AWS documentation states that the Network Health Indicator—which signals whether a fault may originate within the AWS network itself—is not yet supported for Interconnect. It would be premature to read the joint announcement's description of "identifying which side a problem originates from" as meaning automated fault isolation has already been fully implemented.
The Gap Between "Possible" and "Convenient" Revealed by 2024 Statements
This product launch appears to reflect a shift in how both companies view multicloud. In July 2024, AWS told the UK's Competition and Markets Authority (CMA) that customers could already operate multicloud environments and switch cloud providers whenever they wished. AWS also pushed back against the view that technical barriers were harming competition.
Microsoft, in the same inquiry, stated that outside of specialized use cases, customer interest in integrated multicloud setups was limited, and that such setups were neither easy nor convenient. This time, AWS has acknowledged that connecting to Azure was previously "cumbersome," and Microsoft has stated that provisioning circuits and configuration could take weeks to months. Rather than fully reversing their 2024 positions, both companies appear to be treating the cost and effort gap between "technically possible" and "practical to operate continuously" as a product opportunity.
AWS began building this framework with its connection to Google Cloud at re:Invent 2025, and has now brought the three major clouds—Google Cloud, Oracle Cloud Infrastructure, and Azure—under the same operating model. What the public APIs standardize is the network layer: creating and synchronizing the state of managed Layer 3 connections, along with maintenance and encryption key rotation. This does not extend to application API or identity compatibility. Data formats, databases, and licensing remain handled separately by each cloud.
Connecting the Wire Doesn't Automatically Move Workloads
A direct link between Azure and AWS benefits companies holding disparate cloud assets from acquisitions, software vendors deploying across multiple clouds, and organizations whose data and AI compute resources sit in different environments. Network teams can step away from procuring and maintaining physical infrastructure and instead treat connectivity as a cloud resource. Scaling bandwidth up or down remains a future vision; the current preview, limited to 1Gbps, offers no such flexibility. The lines of responsibility during outages can also be narrowed compared to traditional setups, which cycle through the customer, carrier, colocation facility, and two separate clouds in sequence.
Even so, applications deeply embedded in cloud-specific services cannot be migrated over a single wire. Organizations still need to estimate the time and cost of moving large volumes of data, and design addressing, routing, name resolution, and identity federation. Database replication and licensing terms also need to be worked out separately. A private path does not automatically guarantee data residency or regulatory compliance.
Whether this connectivity truly expands competition between clouds will become clearer once general availability arrives and regions offering the full 100Gbps become known. It will also be worth confirming the formal SLA, combined pricing across both clouds, and growth in actual customer adoption. Once those conditions are met, multicloud will move from being a network that experts assemble individually—starting from today's 1Gbps, SLA-free preview—toward becoming a standard option that can be provisioned for exactly as long as it's needed.