The Vanishing Cross-Connect: What AWS Interconnect Actually Automates
Getting AWS's own recommended resiliency model for Direct Connect has always meant ordering physical ports at two facilities and waiting up to 72 business hours per port. AWS Interconnect replaces that whole choreography with a token you redeem — and quietly makes the resiliency model AWS always recommended into the one you can no longer skip.
Order a Direct Connect connection today under the Resiliency Toolkit’s own Maximum Resiliency model — the one AWS recommends for anything you’d call critical — and here is what that actually involves: pick a first location, pick a second location, choose a provider and a sub-location at each, submit the request, and wait. AWS’s own setup guide is blunt about the timeline: “it can take up to 72 business hours for AWS to review your request and provision a port for your connection” — per port, so the maximum-resiliency model’s separate connections at separate locations each carry that clock separately. Then you configure virtual interfaces by hand: a VLAN tag, a BGP ASN, an MD5 authentication key, peer IP addresses, and — if you want the throughput — jumbo frames, which can knock the physical connection offline for up to 30 seconds while it updates. None of this is AWS being slow for its own sake. It’s the honest cost of a private circuit that has to terminate on real hardware in a real building.
On 29 July 2026, AWS extended a service that quietly deletes most of that choreography for the paths it covers, replacing an ordering process with something you redeem instead: an activation key. Oracle Cloud Infrastructure became the second cloud provider to reach general availability under AWS Interconnect, joining Google Cloud, which launched at GA in April alongside a sister offering for on-premises connectivity called Interconnect – last mile. Both are built on the same idea, and it’s worth being precise about what that idea actually is — because it isn’t “no physical layer.” It’s AWS deciding that the physical layer is its problem to solve once, not yours to reassemble every time.
The problem: private connectivity has always meant becoming your own integrator
Direct Connect has never pretended interconnection was simple; it hands you the primitives — connections, virtual interfaces, Direct Connect gateways — and trusts you to assemble them correctly. That’s appropriate when you’re connecting one data centre to one AWS account. It gets considerably less appropriate once “the other side” is a second cloud provider’s own VPC, because now there’s no colocation cage that’s naturally yours. Historically that has meant one of two things: a VPN tunnel over the public internet, carrying BGP inside an IPsec wrapper, throttled by internet path variance and per-tunnel throughput ceilings; or the DIY version of Direct Connect — procure a port from each cloud’s own interconnection product, find a facility where both providers have a presence, order a physical cross-connect between them, and hand-configure BGP on both ends yourself, twice.
Every part of that DIY path is a decision the customer has to get right: which facility has both providers, which resiliency model justifies the cost, which ASN, which authentication key, which MTU. None of it is optional busywork — the Resiliency Toolkit’s “Maximum Resiliency” model exists precisely because separate connections terminating on separate devices in more than one location protect against device, connectivity, and complete location failure in a way a single connection, however fast, cannot. The problem was never that the model was wrong. It’s that getting it right required a customer to correctly reproduce a fairly specialised piece of network design, port order, and BGP configuration, every single time they needed private connectivity somewhere new.
The challenge: you can’t API your way out of needing two real buildings
The tempting shortcut is to assume software can simply remove the physical constraint. It can’t. A private, low-latency path between two clouds still has to cross real fibre between real facilities, and surviving the loss of one facility still requires standing infrastructure in a second one. What AWS actually did wasn’t skip that requirement — it centralised it. Both Interconnect offerings pre-provision standing capacity across “redundant network devices spanning at least two physically distinct facilities with independent power and networking,” ahead of any specific customer’s request, at named region pairs where AWS and the partner have already done the facility selection, the port ordering, and the cross-connects. What used to be a customer project — pick two locations, order two ports, wait two clocks — becomes standing shared capacity that a customer draws from with an API call.
The harder problem was BGP, not fibre. Multicloud connectivity means two cloud providers, neither controlling the other’s network, need to establish and manage a routing session together on the customer’s behalf without either side trusting the other’s console. AWS’s answer is a genuinely symmetric handshake, published as an open OpenAPI 3.0 specification on GitHub under an Apache-2.0 licence rather than kept as an internal integration: any provider can implement the same “connection-coordinator” protocol AWS uses with Google Cloud and Oracle to plug into the identical create/accept flow. That’s a deliberate bet — that being the reference implementation of how clouds talk to each other matters more than owning a proprietary integration with each one individually, especially when the parties on the other end are competing clouds with every incentive to prefer an open protocol over a bespoke one.
The solution: an activation key instead of an order form
Creating a multicloud Interconnect collapses down to a handful of
choices:
your AWS Region, the paired region on the other provider, your required
bandwidth, the Direct Connect gateway that will anchor it, and your
identifier on the other side — a Google Cloud project ID, or an OCI tenancy
OCID in the form ocid1.tenancy.oc1..<unique_ID>. Submit that, and AWS
hands back an activation key: a token generated during creation that
both parties use to authorise the request before either side commits
resources. Redeem the key on the other cloud’s console, and provisioning
happens automatically on both sides — no separate BGP session to configure,
no ASN to choose, no MD5 key to generate. Routes propagate in both
directions the moment the interconnect comes up.
What the customer never sees is the infrastructure the key actually activates. Every Interconnect — multicloud or last mile — is provisioned as a four-connection model across at least two physical facilities, load balanced with Equal-Cost Multi-Path routing, so that a single device, cross-connect, or entire facility can fail without interrupting service. That is, feature for feature, the same Maximum Resiliency model the Direct Connect Resiliency Toolkit has always offered — except here it isn’t a model you opt into by picking the right wizard screen. It’s the only model Interconnect ships. Every physical link between AWS’s routers and the partner’s is also MACsec-encrypted (IEEE 802.1AE) by default, and the devices are configured to refuse customer traffic entirely until that encryption session is active — a default, not a checkbox, on both counts.
On the AWS side, an Interconnect always attaches to a Direct Connect gateway — the same globally distributed object that already anchors virtual private gateways, Transit Gateways, and Cloud WAN — which makes the reach model worth understanding before you pick one. A VGW or TGW can only reach an Interconnect that’s local to its own Region; Cloud WAN is the exception, because any Core Network Edge in a global Cloud WAN network can reach any Interconnect attached to the same Direct Connect gateway, anywhere in that network. Choose Cloud WAN if the workloads that need this connectivity aren’t all in one Region; choose a Transit Gateway if they are, and take the simpler architecture.
Coverage today is deliberately narrow. Google Cloud multicloud Interconnects are GA across eight region pairs — N. Virginia, N. California, Oregon, London, Frankfurt, Stockholm, Singapore, and Sydney, each paired with the geographically matching Google Cloud region. OCI is GA on exactly one: US East (N. Virginia) to OCI’s Ashburn region. Azure remains listed as coming later in 2026. Last mile is narrower still — Lumen only, reachable from New Jersey sites in us-east-1 or anywhere in the continental United States over Lumen’s own fabric, with AT&T and Megaport named as in-progress partners. Pricing drops the separate data-transfer line item Direct Connect has always carried: a single hourly rate set by bandwidth and a geographic “Tier” — from Tier 1 (local) to Tier 5 (maximum scope) — with no per-gigabyte charge on top, and one free local 500 Mbps Interconnect per Region per generally-available provider for anyone who wants to evaluate the path before committing real bandwidth to it.
The footprint
None of this makes the physical layer optional; it makes it AWS’s inventory problem instead of yours. That’s a genuine trade, and it cuts both ways. The velocity gain is real — an activation key instead of two port orders and 72 business hours apiece is not a marginal improvement, it’s a different category of procurement. But automatic BGP configuration means AWS is choosing your side’s ASN behaviour and session parameters for you, which is exactly the kind of manual control that lets an operator hand-tune peering with AS-path prepending or BGP communities when a link needs to behave in a specific way. If your multicloud path needs that level of control, Interconnect’s automation is a reason to keep the DIY DX architecture for that specific link, not a reason to abandon it everywhere.
The more durable point is what AWS chose to make non-optional. Maximum Resiliency was always the right answer for anything that mattered; it was just the answer most people didn’t reach for, because reaching for it meant two port orders instead of one and twice the wait. Interconnect doesn’t introduce a new resiliency model — it takes the one AWS has been recommending since the Resiliency Toolkit shipped and removes the option to skip it. For the region pairs it covers today, that’s a better default than most customers were choosing for themselves. For everywhere it doesn’t reach yet, the two-port, two-clock version is still exactly how you get there — and now you know precisely what standard the automated version is quietly holding you to.