A few years ago, if you wanted a private link between an AWS VPC and a workload sitting in another cloud, the honest answer was: go find a colo. You’d order a cross-connect, provision a router on each side, stand up a VPN or a pair of Direct Connect circuits, and then hand-configure BGP sessions and hope the failover behaved the way the runbook said it would. It worked, but it was a project, not a feature — weeks of lead time, and yours to operate for as long as the link existed.

That’s the backdrop for why AWS Interconnect – multicloud matters, and why the last twelve months of announcements are worth actually reading instead of skimming. In September, AWS put Microsoft Azure into public preview as the third cloud to adopt the interconnect specification, a month after Oracle Cloud Infrastructure crossed into general availability. Between those two announcements sits a genuinely different way of thinking about cross-cloud networking, and also a few gaps that I’d want a client to understand before they bet a production DR path on it.

What you’re actually provisioning

Strip away the marketing language and Interconnect is a managed Layer 3 private connection between your AWS environment and a partner cloud, with the physical and routing complexity abstracted into a single object. On the AWS side, the attach point is always a Direct Connect Gateway — that’s the one thing you touch. On the partner side it’s a CSP router, and AWS and the partner negotiate an Activation Key between them: one party creates the request, the other accepts it, and provisioning happens automatically on both sides. You never see a BGP session config or a VLAN tag.

Underneath that single logical object, AWS builds four physical connections across at least two separate buildings with independent power and networking, load-balanced with ECMP so that a device or facility failure doesn’t take the link down — only one of the four paths needs to survive. Every physical hop between an AWS router and a partner router runs IEEE 802.1AE MACsec, and it’s not optional: if the encrypted session drops, traffic stops, full stop, rather than falling back to anything unencrypted. That’s a reasonable default for anyone crossing a cloud boundary, though it does mean an encryption negotiation failure is now also a connectivity failure, which is worth knowing before your first 3am page.

The diagram above hides a detail that’s easy to miss in the docs: a Virtual Private Gateway or Transit Gateway can only reach an Interconnect that’s local to its own Region. If you want any Core Network Edge in your Cloud WAN global network to reach any Interconnect anywhere, attached to the same Direct Connect Gateway, you need Cloud WAN in the picture. For a single-region pilot that distinction doesn’t matter. For a multi-region architecture it’s the difference between one interconnect per region pair and one global fabric, and it changes how you’d design the topology from day one.

The three-provider board, as of this month

Here’s where things actually stand, because “multicloud” has meant three different maturity levels depending on which partner you’re asking about:

• Google Cloud — generally available since April 2026, the longest-running and most mature pairing. It spans five region pairs (US East N. Virginia, US West N. California, US West Oregon, Europe London, Europe Frankfurt), scales to 100 Gbps, and carries a published SLA on the AWS side.
• Oracle Cloud Infrastructure — reached GA in July 2026 after a preview that started in May, but only in a single region pair: us-east-1. If your OCI footprint isn’t in N. Virginia, this doesn’t help you yet.
• Microsoft Azure — entered preview at the end of August 2026, covering four regions (US East N. Virginia, US West N. California, Asia Pacific Sydney, Europe Frankfurt). Preview means no SLA and, as far as I can tell from the announcement, no finalized pricing on the Azure side either.

Laid out on a timeline like that, the pattern is obvious: AWS is running the same playbook with every partner — preview in a handful of regions, then GA once the physical build-out and pricing catch up. If you’re planning around Azure connectivity, treat it the way you’d treat any preview service touching production traffic: fine for a proof of concept, not something I’d put in a DR failover path yet.

Why this is an open spec and not just an AWS product

The mechanism behind all three partnerships is the same open specification for network interoperability, published under Apache 2.0 back when Google Cloud joined at re:Invent 2025. Any cloud provider can implement it and become an Interconnect partner without a bespoke bilateral integration each time — which is exactly what happened with OCI and now Azure, both adopting the same spec rather than AWS building three separate point-to-point products.

Forrester’s Lee Sustar has been fairly blunt about the strategic reading: this lets AWS use its market position to push the industry toward its interconnect model as the de facto standard, rather than a neutral committee-driven one. I don’t think that reading is wrong, exactly, but I’d add a second layer to it. Once three of the largest providers are running the same API surface, walking it back gets expensive for everyone involved — including AWS. Azure’s own networking leadership described wanting to extend this model past a single cloud-to-cloud relationship, which suggests they’re not treating this purely as playing along with an AWS-authored spec. Whether that turns into genuine multilateral governance or stays “AWS writes the spec, everyone else implements it” is worth watching over the next year, not something settled by this announcement.

What changes for the team actually running the network

If you’ve built cross-cloud connectivity the old way, the operational shift is real. You’re not configuring BGP timers or ordering physical cross-connects — you pick a Region, a partner, and a bandwidth tier, and the object shows up. Bandwidth is elastic after the fact too: you can scale it up or down from the console without a re-provisioning cycle, which matters if your cross-cloud traffic has a seasonal or campaign-driven shape.

Monitoring comes bundled rather than bolted on. Every Interconnect includes a CloudWatch Network Synthetic Monitor for round-trip latency and packet loss at no extra charge, plus a bandwidth utilization metric you can alarm on before you hit a ceiling. The one gap: AWS’s own docs note that the Network Health Indicator feature isn’t supported on Interconnects yet, so you’re relying on the synthetic probe and utilization metric rather than a single composite health signal. Worth knowing if your ops team is used to that indicator elsewhere in the Direct Connect family.

Pricing, and where the savings are real

The pricing model itself is refreshingly simple: a flat hourly rate based on bandwidth tier and how “local” the region pairing is, with zero per-gigabyte data transfer charges. A 10 Gbps Interconnect between us-east-1 and Google Cloud’s paired N. Virginia region runs about $12.33 an hour — call it $9,000 a month if you leave it running continuously, though you’d size and schedule it to your actual traffic pattern rather than leaving a static circuit up around the clock. Since May 2026, every account also gets one free local 500 Mbps interconnect per Region, which is a genuinely useful way to validate connectivity before you commit real budget.

The no-egress-fee structure is where this actually pays for itself. If you’re moving tens of terabytes a month between clouds — database replication, backup pipelines, analytics pulling from a partner cloud’s data lake — standard internet egress adds up fast, and a fixed hourly bandwidth charge starts looking cheap by comparison well before you hit the circuit’s ceiling. If your cross-cloud traffic is bursty and small, the math is much less compelling, and you’re probably fine on a VPN.

Where I’d actually reach for this, and where I wouldn’t

I’d use Interconnect – multicloud today for exactly the kind of workload it was clearly built for: steady, high-volume data movement between AWS and Google Cloud where the region pairing lines up, or between AWS and OCI if your Oracle footprint genuinely lives in us-east-1. Cross-cloud DR replication, bulk ETL, anything where the alternative was going to be a Direct Connect circuit into a colo anyway — this removes real operational weeks from that project.

I’d be more cautious treating it as a wholesale replacement for a broader multicloud networking fabric. It’s a managed point-to-point bridge between specific region pairs on specific partner clouds, not a global mesh, and OCI’s single-region availability is a real constraint if your estate is more spread out than that. The Azure leg is a preview product without a finalized SLA, so I wouldn’t route anything customer-facing over it until GA lands — and given the Google and OCI timelines, that’s probably a late-2026 or 2027 conversation, not a Q4 one.

The specification being open is the part I’d keep an eye on longer term. If a fourth or fifth provider adopts it, or if governance shifts away from “AWS publishes, others implement,” this stops being an AWS product with two guest stars and starts looking like an actual industry convention for how clouds talk to each other. That’s the more interesting story, and it isn’t finished yet.