AWS Interconnect connects Azure in preview, capped at 1 Gbps with no SLA
On August 31, 2026, AWS Interconnect multicloud opened to Azure in public preview: a VPC and a VNet linked over AWS’s private backbone, no third-party carrier, but capped at 1 Gbps with no availability commitment. Test it for shared AWS-Azure workloads, but keep your existing circuits until general availability.
August 31, 2026. AWS opened AWS Interconnect — multicloud to Microsoft Azure in public preview. April 14, 2026. The same product reached general availability with Google Cloud, at 100 Gbps and with an SLA. July 29, 2026. Oracle Cloud joined the loop. Why it matters: for the first time, a team can link an AWS VPC to an Azure VNet privately without negotiating with a carrier — but the preview ships with a 1 Gbps cap and no SLA, which makes it a test bed, not yet a production-circuit replacement.
What shipped
AWS Interconnect — multicloud connects an Amazon VPC to an Azure Virtual Network over AWS’s own backbone, never the public internet. The preview covers four region pairs: N. Virginia, N. California, Sydney, and Frankfurt, each mapped to a matching Azure region. That is narrower than the Google Cloud launch, which began with five region pairs across the US and Europe.
Microsoft published its own counterpart in parallel, Azure Multicloud Interconnect, built on ExpressRoute. The pitch is identical on both sides: a single logical resource, provisioned from each cloud’s console, replacing hand-built cross-connects, VPNs, and third-party circuits negotiated over months.
The product is not a marketing abstraction. AWS and the partner cloud jointly manage the physical links, and no customer configures BGP peering, IP addressing, or route advertisements. The interconnect appears as an attachment, much like a VPC peering or Transit Gateway attachment.
The 1 Gbps cap and the missing SLA
This is where the Azure preview diverges sharply from what AWS already shipped for Google Cloud and Oracle. The cap is 1 Gbps per interconnect — the smallest tier AWS offers. General availability is “expected” to reach 100 Gbps, as with Google Cloud, but AWS has announced no date, only “later in 2026”.
There is no service-level agreement during preview. AWS targets 99.99% availability at general availability, but that figure is a goal, not a contract. For comparison, the Google Cloud link received a formal SLA on April 16, 2026, two days after GA. A company evaluating the Azure link today is testing a product AWS has not yet committed to keep running at any particular uptime.
Pricing follows the same pattern. On the AWS side, the hourly rate is the same as for Google Cloud and Oracle: in North America and Europe, $3.50/hr for 1 Gbps, up to $146.60/hr for 100 Gbps. On the Azure side, Microsoft is charging no service fee or data-transfer charge yet — a gap that reads less like a generous free preview than a rate card not yet finalized.
MACsec and the security model
Every AWS Interconnect — multicloud link, whatever the partner, encrypts the physical layer with IEEE 802.1AE MACsec between AWS’s edge routers and the partner cloud’s routers. Encryption is applied before traffic ever reaches a customer virtual network, and AWS treats an active MACsec session as a precondition for flow: if the encrypted session drops, connectivity drops with it, with no fallback to cleartext transport.
The architecture also relies on redundant router pairs and multiple backbone paths per region, though AWS has not published exact failover timing. For the Azure preview, that redundancy exists without the compensation guarantees of an SLA — a distinction worth flagging to anyone planning to build a production dependency before GA.
Why Google got there first
The timeline measures the race. AWS announced the concept at re:Invent in late November 2025, with Google Cloud as the sole launch partner. Google reached general availability on April 14, 2026, at 100 Gbps. Oracle followed on July 29, 2026, initially on a single region pair. Azure arrived on August 31, 2026, with fewer regions and a lower cap than either predecessor at the same stage.
The gap has a simple explanation: AWS and Google started ten months earlier, and the Azure preview reflects a more cautious alignment — or a longer engineering effort. Whatever the cause, the operational consequence is the same: the AWS↔Google path is a finished product today, while the AWS↔Azure path remains a work in progress.
What to put in place
Three decisions, depending on your situation:
- If you run split workloads between AWS and Azure — databases on one side, application tiers on the other, or Azure AD backed by AWS compute — evaluate the preview now to measure real latency and simplicity, but on a test environment.
- Do not replace your Megaport, PacketFabric, or Equinix circuits yet. The 1 Gbps cap and the missing SLA rule out a production dependency; your current contract remains the continuity plan.
- Watch for general availability. Once AWS publishes an SLA and the higher tiers, the switch becomes a simple pricing equation against your carrier — the product bills hourly, with no port fee, and AWS charges no egress on the Google Cloud link, a strong signal about its multicloud strategy.
Verdict
If you are already multicloud on AWS and Azure and paying a third-party carrier to link the two, open the preview and price what the replacement would cost at general availability — but migrate nothing into production while the 1 Gbps cap and missing SLA hold. If you only run AWS↔Google Cloud or AWS↔Oracle, you already have a finished product at 100 Gbps with an SLA: no reason to wait for Azure. If you are just starting in multicloud, note the shift in leverage: multicloud, long assembled by hand, is becoming an hourly-billed feature sold by the hyperscalers themselves — and the exit cost from your current cloud has never been lower.