Azure just became the third cloud provider plugged directly into Amazon’s backbone, and the fine print tells a more interesting story than the headline. AWS Interconnect – multicloud entered public preview with Microsoft Azure on August 31, 2026, letting engineering teams wire an Amazon VPC straight to an Azure VNet without touching a third-party carrier. But the preview caps throughput at 1 Gbps, ships with no service-level agreement, and covers just four AWS regions paired with four Azure regions. Compare that to the Google Cloud pairing, which reached general availability back in April 2026 with tiers up to 100 Gbps and a published SLA. Azure showed up late to a party AWS and Google started ten months ago, and it’s arriving with a smaller bag.
The story matters beyond networking trivia. Enterprises running split workloads (Oracle databases on one cloud, application tiers on another, or Azure AD tied to AWS compute) have spent years stitching together dedicated lines through carriers like Megaport, PacketFabric, or Equinix. AWS wants to make that stitching unnecessary by turning cross-cloud connectivity into a managed, hourly-billed feature of its own network. Whether Microsoft’s rollout cadence undercuts that pitch, or simply reflects a cautious first step, is the question worth digging into. It’s the latest move in the broader AWS-Azure-Google Cloud rivalry that’s been playing out across pricing, performance, and now networking itself.
What Just Shipped: AWS Interconnect – Multicloud Adds Azure
AWS confirmed the Azure preview in a networking blog post published August 31, 2026, describing it as a jointly engineered service that connects Amazon VPCs to Azure Virtual Networks over AWS’s own backbone rather than the public internet. The preview covers four AWS regions: US East (N. Virginia), US West (N. California), Asia Pacific (Sydney), and Europe (Frankfurt), each mapped to a corresponding Azure region. That’s a narrower footprint than the Google Cloud pairing, which launched with five region pairs spanning the US and Europe.
Microsoft published a parallel announcement on its Azure Networking Blog the same week, branding its side of the service Azure Multicloud Interconnect. The framing on both sides is identical: a single logical resource that replaces manually provisioned cross-connects, VPNs, or third-party circuits with something customers can spin up from their own cloud console. For teams that have spent months negotiating carrier contracts just to get AWS and Azure workloads talking to each other over a private line, that pitch alone explains why this launch generated attention the moment it went live.
How AWS Interconnect – Multicloud Actually Works
The mechanics matter because they explain what customers are and aren’t giving up in exchange for simplicity. AWS and the partner cloud jointly manage the physical links between their routers, and neither side asks customers to configure BGP peering, negotiate IP addressing, or manage route advertisements manually. Instead, the interconnect shows up as an attachment a customer provisions through their existing cloud console, similar to how a VPC peering connection or Transit Gateway attachment works today.
That abstraction is the core sales pitch. Constellation Research, covering the original Google Cloud preview in December 2025, noted that the joint effort would “abstract physical connectivity, network addressing and routing policies” — turning what used to be a carrier procurement exercise into something closer to clicking a button in a console. AWS is applying the identical model to Azure, just with a much smaller initial capacity ceiling.
Traffic Never Touches the Public Internet
Both companies are explicit that traffic between the two clouds moves over private backbone links rather than the public internet, which is the primary security and reliability argument behind the service. For regulated industries — banking, healthcare, insurance — that distinction can be the difference between a compliant multicloud architecture and one that requires additional encryption layers and audit overhead just to satisfy a data-residency requirement.
The Fine Print: 1 Gbps Cap, Four Regions, No SLA
Here’s where the Azure rollout diverges sharply from what AWS already shipped for Google Cloud and Oracle. The Azure preview is capped at 1 Gbps per interconnect — the smallest tier AWS offers. General availability is expected to support up to 100 Gbps eventually, matching the ceiling already available to Google Cloud customers, but AWS has not published a GA date. The public documentation says only “later in 2026.”
There’s also no formal service-level agreement during preview. AWS is targeting 99.99% availability at general availability, but that figure is described as a goal rather than a contractual commitment while the service remains in preview. Compare that to the Google Cloud pairing, where AWS published a formal SLA document on April 16, 2026, two days after GA. Enterprises evaluating the Azure link today are effectively testing a product AWS hasn’t yet promised to keep running at any particular uptime.
Pricing tells a similar story. AWS’s side of the connection uses the same hourly rate card that applies to Google Cloud and Oracle traffic. But on the Azure side, Microsoft isn’t charging a separate service fee or data-transfer charge yet — a gap that’s less “generous free preview” and more “we haven’t finished pricing this.”
MACsec Encryption and the Security Model
Every AWS Interconnect – multicloud link, regardless of partner, runs IEEE 802.1AE MACsec encryption on the physical connection between AWS’s edge routers and the partner cloud’s routers. That’s link-layer encryption applied before traffic ever reaches a customer’s virtual network, and AWS treats an active MACsec session as a precondition for traffic flow at all — if the encrypted session drops, so does connectivity, rather than falling back to unencrypted transport.
The architecture also relies on redundant router pairs and multiple backbone paths per region, though AWS hasn’t published exact failover timing or the number of physical paths per region pair. For the Azure preview specifically, that redundancy exists but isn’t backed by the compensation guarantees that come with a published SLA — a distinction worth flagging to anyone building production dependencies on the link before GA.
What AWS Charges: Interconnect Pricing by Region and Bandwidth
AWS Interconnect – multicloud bills a flat hourly rate based on bandwidth tier and geography, prorated by the hour, with no separate port fee or per-circuit charge layered on top. The rate card below reflects the published pricing that applies to the Google Cloud and Oracle pairings today; AWS has not yet published Azure-specific figures for when the preview transitions to GA.
| Region family | 1 Gbps | 5 Gbps | 10 Gbps | 100 Gbps |
|---|---|---|---|---|
| North America / Europe | $3.50/hr | $17.30/hr | $19.00/hr | $146.60/hr |
| Asia Pacific | $5.00/hr | $24.90/hr | $26.40/hr | $196.10/hr |
| South America | $7.60/hr | $38.00/hr | $46.90/hr | $299.60/hr |
Since May 2026, AWS has also offered one free 500 Mbps local interconnect per region for testing purposes, though that free tier applies to short-haul, same-region connectivity rather than the long-haul links most multicloud architectures actually need. On the Google Cloud pairing specifically, AWS charges no egress fee for data crossing the interconnect, which webhosting.today flagged as a meaningful departure from AWS’s usual data-transfer pricing and a direct shot at the egress costs that have long locked customers into a single cloud.
The Timeline: From a Single Partner to Three in Ten Months
AWS first announced the multicloud interconnect concept at re:Invent in late November 2025, with Google Cloud as the sole launch partner in preview. Google’s side of the pairing shipped under the name Cross-Cloud Interconnect for AWS. From there, the rollout followed a steady but deliberate cadence rather than a simultaneous multi-partner launch.
| Partner | Status | Key date | Max bandwidth | SLA |
|---|---|---|---|---|
| Google Cloud | General availability | April 14, 2026 | 100 Gbps | Published April 16, 2026 |
| Oracle Cloud Infrastructure | General availability | July 29, 2026 | Standard tiers (us-east-1 only) | Standard GA SLA |
| Microsoft Azure | Public preview | August 31, 2026 | 1 Gbps (preview cap) | None yet; 99.99% targeted at GA |
Google Cloud’s five-month head start from preview to GA gives AWS a working template, and Oracle’s launch three months later followed a nearly identical script, just scoped to a single region pair at first. Azure’s preview, by contrast, launched with fewer regions and a lower bandwidth cap than either predecessor did at the equivalent stage, suggesting Microsoft and AWS are moving more cautiously on this particular pairing, or that the joint engineering work simply took longer to align.
Why Google Cloud Got There First
Google Cloud’s status as launch partner wasn’t an accident of scheduling. AWS and Google jointly branded and engineered the connection well ahead of re:Invent 2025, and Google had its own product, Cross-Cloud Interconnect, already positioned as a complement rather than a competitor to AWS’s offering. That alignment let both companies ship a full five-region, four-tier GA product within five months of preview.
It’s also a signal about where enterprise demand actually sits. Workloads split between AWS and Google Cloud tend to cluster around data analytics and AI training pipelines, where BigQuery or Vertex AI on the Google side needs low-latency access to compute or storage sitting on AWS. That’s a use case big enough to justify AWS prioritizing the full bandwidth range and a formal SLA from day one of GA.
Oracle’s Quiet Second Slot
Oracle’s July 29, 2026 GA launched in a single region pair, US East (N. Virginia) paired with the corresponding OCI region, rather than the five-region spread Google got. The logic there is narrower and more specific: enterprises running Oracle databases (Exadata, Autonomous Database) on OCI while keeping application and compute tiers on AWS need low-latency, private connectivity between exactly those two environments, and a single well-trafficked region pair covers most of that demand. Oracle’s positioning leans on database-centric multicloud architectures rather than the broader AI and analytics workloads driving Google Cloud traffic.
Where This Leaves Azure Customers Today
For teams that specifically need AWS-to-Azure connectivity right now, the preview is usable for testing and low-throughput production traffic, but not much beyond that. A 1 Gbps ceiling is workable for control-plane traffic, identity synchronization between Azure AD and AWS IAM, or moderate database replication. It’s not enough for large-scale data pipeline traffic, media workloads, or anything that would have previously justified a 10 Gbps or 100 Gbps dedicated circuit through a carrier.
That gap matters because Azure-AWS is arguably the most commercially significant pairing of the three. Microsoft and Amazon are the two largest cloud providers by revenue, and a large share of Fortune 500 companies run meaningful workloads on both — often orchestrated through managed Kubernetes clusters split across EKS and AKS that would benefit most from a faster, cheaper private link. A capped, SLA-free preview is a reasonable first step, but it also means the enterprises most likely to benefit from this service are the ones currently least able to rely on it for anything mission-critical.
How Independent Interconnect Providers Compare
Before AWS built this directly into its own backbone, multicloud connectivity ran almost entirely through neutral interconnect fabrics. Megaport, PacketFabric, Equinix Fabric, and Console Connect all still offer cross-cloud connectivity today, and each uses a materially different pricing and management model than AWS’s new offering.
| Provider | Pricing model | Typical cost | Customer manages BGP? |
|---|---|---|---|
| AWS Interconnect – multicloud | Hourly, per Gbps, region-based | $3.50–$299.60/hr by tier | No, fully abstracted |
| Megaport | Monthly port fee + hourly Cloud Router | ~$250–$300/mo per 1 Gbps port | Partial, via Cloud Router |
| PacketFabric | Monthly port + per-circuit | ~$2,000–$3,000/mo per 10 Gbps port | Yes, customer-configured |
| Equinix Fabric | Hourly virtual connection + distance | Tens of dollars/mo for 1 Gbps | Yes, via Network Edge |
The structural difference is what matters most. Independent fabrics charge per physical or virtual port and require customers to configure their own BGP sessions and IP addressing, which gives more control but demands networking expertise most application teams don’t have in-house. AWS’s model trades that control for simplicity: pay per Gbps, per hour, and let AWS and the partner cloud handle routing entirely. For a mid-sized team without a dedicated network engineering function, that trade-off alone could shift real volume away from neutral fabrics over the next year, at least for AWS-anchored architectures.
Market Impact: What This Means for Enterprise Cloud Spend
The immediate financial impact falls into three buckets: reduced carrier spend, altered egress economics, and a new procurement line item that didn’t exist a year ago. Enterprises that previously paid for dedicated circuits through a neutral fabric provider now have a first-party alternative billed directly through their AWS account, which simplifies vendor management even where it doesn’t necessarily lower the total bill. That kind of predictable, usage-based pricing is exactly what FinOps teams have been pushing cloud vendors toward as multicloud budgets get harder to track.
The egress-fee waiver on the Google Cloud pairing is the more disruptive piece. AWS has spent close to two decades charging for data leaving its network, and egress fees have been one of the most durable forms of cloud vendor lock-in in the industry. Waiving that fee for one specific cross-cloud path, even conditionally, is a meaningful crack in that model. Whether AWS extends the same waiver to Azure once it reaches GA is one of the more consequential open questions in this rollout, since it would directly affect how enterprises weigh AWS-Azure workload splits against staying single-cloud.
Expert Perspectives on the Rollout
Robert Kennedy, VP of Network Services at AWS, framed the Azure launch as customer-driven and technically ambitious. “Customers told us they wanted a better way to connect workloads spanning AWS and Azure, and the old ways of doing it were clunky. With AWS Interconnect-multicloud and Azure Multicloud Interconnect, we’re proving what’s possible when both sides commit to a high bar: MACsec security out of the box, four-nines availability, and scalability at the click of a button,” Kennedy said in AWS’s networking blog post announcing the preview.
Microsoft’s Azure Networking Blog described the joint effort in similar terms: “Today, Microsoft and AWS are together introducing Azure Multicloud Interconnect, a jointly engineered, fully managed service that delivers private, high-throughput connectivity between Azure and AWS through a single logical resource,” according to a post on Microsoft’s Tech Community networking blog.
Azure’s own product blog leaned into the routing abstraction as the core value proposition: “With Microsoft and AWS collaborating using the standardized Open API specification, customers can establish dedicated private connectivity through a simplified experience that abstracts the underlying complexity of multicloud networking,” Microsoft wrote on the Azure blog announcing the interconnect.
AWS used nearly identical language when it originally shipped GA for the Google Cloud pairing back in April: “Today, we’re announcing the general availability of AWS Interconnect – multicloud, a managed private connectivity service that connects your Amazon Virtual Private Cloud (Amazon VPC) directly to VPCs on other cloud providers,” the company said in its official AWS blog post on the GA milestone. AWS’s product documentation now describes the feature’s full partner scope directly: “AWS Interconnect – multicloud is a new capability that simplifies multicloud connectivity between AWS and other cloud service providers, including Microsoft Azure (Preview), Google Cloud, and Oracle Cloud Infrastructure,” per the AWS Interconnect product page.
Historical Context: The End of the Dedicated Line Era
Cross-cloud connectivity has historically meant one of two things: routing traffic over the public internet with encryption layered on top, or paying a carrier to provision a dedicated circuit through a colocation facility. AWS’s own Direct Connect and Azure’s ExpressRoute solved the on-premises-to-cloud half of that problem years ago, but cloud-to-cloud connectivity remained something customers had to assemble themselves, usually through a neutral fabric provider acting as the middleman between two clouds that had no direct commercial or technical reason to cooperate. That same pressure to keep infrastructure costs predictable is visible in how AWS, Azure, and GCP have started billing separately for extended Kubernetes support once a version reaches end of life.
What changed in the past year is that the two largest hyperscalers decided cooperating directly serves their own interests better than leaving that traffic to third parties. Constellation Research’s coverage of the original AWS-Google preview called the move a way to “engineer interconnect between their clouds,” language that captures the shift from adversarial competition to selective infrastructure cooperation on paths where both sides can bill for it. Ten months later, that same logic has pulled in Oracle and now Azure, turning what was a single experimental pairing into the beginning of an industry-standard cloud-to-cloud fabric.
Predictions: What Happens Next
Five things worth watching as this rollout matures through the rest of 2026 and into 2027:
- Azure GA lands with expanded regions. Given the five-month Google Cloud timeline and three-month Oracle timeline, an Azure GA announcement is plausible before the end of 2026, though AWS has committed to nothing more specific than “later in 2026.”
- Bandwidth catches up to 100 Gbps. AWS has already proven it can support that ceiling for Google Cloud, so the Azure preview’s 1 Gbps cap is almost certainly a rollout-pace decision rather than a technical limitation.
- Egress-fee waivers extend to Azure. If AWS wants Azure adoption to match Google Cloud’s, matching the no-egress-fee terms is the most direct lever available, though it would cut into a revenue stream AWS has protected for years.
- Independent fabrics reposition around AI and multi-region traffic. Megaport, PacketFabric, and Equinix aren’t going away, but they’ll likely lean harder into use cases AWS’s model doesn’t cover well: connections to clouds outside the big three, or granular BGP control that sophisticated network teams still want.
- A fourth partner joins the list. IBM Cloud or Alibaba Cloud are the most logical next additions given their own enterprise footprints, though neither AWS nor either company has signaled a timeline publicly.
What Engineering Teams Should Do Now
Teams actively running or planning AWS-Azure split architectures have a narrow but real window to test the preview against real traffic patterns before committing budget elsewhere. The 1 Gbps cap rules out large-scale data movement, but it’s more than sufficient for validating routing behavior, testing MACsec failover, and confirming latency numbers against whatever a current carrier-based circuit delivers. Given the absence of a formal SLA, nothing in the preview should anchor a production cutover plan yet — but the architecture decisions made now, particularly around how VPC and VNet address spaces are laid out, will carry forward once GA removes the bandwidth ceiling.
This is the kind of incremental infrastructure shift worth tracking alongside the rest of this year’s cloud computing news. For teams currently paying a neutral fabric provider for AWS-Azure connectivity, the near-term move is comparison shopping rather than migration. Existing contracts with Megaport or PacketFabric likely run through renewal cycles that will outlast this preview period, giving time to benchmark AWS’s pricing and reliability against what’s already in place before making a switch.
Frequently Asked Questions
What is AWS Interconnect – multicloud?
It’s a managed AWS service that provides private, backbone-level connectivity between an Amazon VPC and a virtual network on another cloud provider, without requiring customers to provision their own dedicated circuits or configure BGP routing manually.
When did the Azure preview launch?
AWS and Microsoft announced public preview of the Azure pairing on August 31, 2026, covering four AWS regions mapped to four corresponding Azure regions.
How fast is the AWS-Azure connection right now?
The preview is capped at 1 Gbps per interconnect. AWS has said it plans to support up to 100 Gbps at general availability, matching what’s already available for the Google Cloud pairing, but hasn’t published a GA date.
Is there a service-level agreement for the Azure preview?
No. The preview ships without a formal SLA. AWS is targeting 99.99% availability once the service reaches general availability, but that figure isn’t contractually guaranteed during preview.
How much does AWS Interconnect – multicloud cost?
Pricing is hourly and based on bandwidth tier and region family, ranging from $3.50 an hour for 1 Gbps in North America or Europe up to $299.60 an hour for 100 Gbps in South America. Azure-specific GA pricing hasn’t been published yet, and Microsoft isn’t charging a separate service fee during preview.
Which other cloud providers already support this service?
Google Cloud reached general availability on April 14, 2026, and Oracle Cloud Infrastructure followed on July 29, 2026. Azure is the third partner and is currently in preview.
Is traffic between AWS and Azure encrypted?
Yes. All AWS Interconnect – multicloud links use IEEE 802.1AE MACsec encryption on the physical connection between AWS and the partner cloud’s routers, and traffic only flows while the encrypted session is active.
Should my company switch from Megaport or PacketFabric to AWS Interconnect now?
For AWS-to-Google-Cloud or AWS-to-Oracle traffic, it’s worth evaluating now given the full bandwidth range and published SLA. For AWS-to-Azure traffic, the 1 Gbps cap and lack of an SLA make the preview suitable for testing only, not for replacing a production circuit until general availability ships.
