A cloud interconnect is a dedicated private network connection between a customer network, such as a data center or office, and a cloud provider’s backbone that bypasses the public internet. In cloud networking, it is the high-capacity, predictable alternative to an internet-based VPN gateway for hybrid architectures.
Each major provider sells its own version: Dedicated Interconnect at Google Cloud, AWS Direct Connect at Amazon Web Services and Azure ExpressRoute at Microsoft. The names differ, but all three deliver the same idea: a physical or partner-provided circuit at a colocation facility, with BGP routing carrying private traffic into virtual networks such as a VPC.
How a cloud interconnect is built
A cloud interconnect starts with a physical cross-connect in a colocation facility where the provider has an edge router. The customer either places its own router in that facility or buys a circuit from a carrier that extends the connection to its data center. The cross-connect is a fiber cable between the customer port and the provider port, typically using single-mode optics at 10 Gbps or 100 Gbps.
On top of the physical link, the customer creates one or more logical attachments, which are 802.1Q VLANs that each carry a separate BGP session. AWS calls these virtual interfaces, Google Cloud calls them VLAN attachments, and Azure uses private and Microsoft peering on an ExpressRoute circuit. Through BGP, the customer advertises on-premises prefixes to the cloud and learns the cloud network prefixes in return.
| Layer | Component | What it does |
|---|---|---|
| Physical | Fiber cross-connect and optics | Carries bits between customer and provider routers |
| Data link | 802.1Q VLAN tagging | Separates logical attachments on one port |
| Routing | eBGP session per attachment | Exchanges prefixes and controls path preference |
| Cloud attachment | Virtual gateway or cloud router | Connects the circuit to one or more VPCs |
| Optional encryption | MACsec or IPsec over the link | Adds confidentiality on the private path |
Dedicated and partner connection models
Providers offer two connection models. A dedicated connection gives the customer an entire physical port, while a partner or hosted connection is provisioned through a service provider that already has capacity into the cloud and sells a slice of it. The choice depends mostly on required bandwidth and whether the customer has equipment in a supported facility.
| Property | Dedicated connection | Partner or hosted connection |
|---|---|---|
| Capacity | Full ports, commonly 10 or 100 Gbps | Sub-rate options, often 50 Mbps to 10 Gbps |
| Location requirement | Router in a provider colocation facility | Any site the partner can reach |
| Provisioning time | Weeks, including cross-connect ordering | Days to weeks, depending on the partner |
| Operational control | Customer manages router and optics | Partner manages part of the path |
| Typical user | Large enterprises and heavy data movers | Mid-sized organizations and branch sites |
Some offerings add features such as link aggregation to bundle several ports, MACsec encryption at layer 2 on supported ports, and global routing options that let one circuit reach cloud regions in other geographies. These features vary by provider and port speed, so they must be checked for each design.
Cloud interconnect compared with other connectivity options
A cloud interconnect is one of several ways to reach cloud resources, and it is often combined with them. The key differences lie in the path, the performance consistency and the data transfer pricing.
| Option | Path | Performance | Typical use |
|---|---|---|---|
| Cloud interconnect | Private circuit to provider edge | Consistent latency, up to 100 Gbps per port | Production hybrid workloads |
| Site-to-site VPN | IPsec tunnels over the internet | Variable, about 1 to 3 Gbps per tunnel | Backup path or small sites |
| VPC peering | Inside the provider network | Provider backbone speed | Connecting two cloud networks |
| Transit gateway | Hub inside the provider network | Provider backbone speed | Routing among many VPCs and circuits |
| Private endpoint | Private IP for a managed service | Provider backbone speed | Reaching one service without public exposure |
In practice, a circuit terminates on a transit gateway or cloud router so that one connection can serve many VPCs, and a VPN over the internet is kept as a cheaper backup path. Outbound data over an interconnect is usually billed at a lower per-gigabyte rate than internet egress, which is a significant factor for organizations that move large datasets.
Designing for resilience and performance
A single cloud interconnect is a single point of failure: one fiber cut, router failure or facility maintenance window can isolate the cloud environment. Providers therefore publish resiliency models and tie their availability commitments to them.
| Topology | Design | Tolerates |
|---|---|---|
| Single connection | One port in one facility | Nothing beyond the provider side |
| Dual connection, one facility | Two ports on separate devices | Device or port failure |
| Dual facility | Connections in two colocation sites | Loss of an entire facility |
| Maximum resilience | Two ports in each of two facilities | Facility loss plus a device failure |
| Interconnect plus VPN | Circuit primary, IPsec tunnel as backup | Total circuit loss at reduced capacity |
Routing policy controls how the redundant paths are used. Engineers tune BGP attributes such as local preference, AS path prepending and MED to choose active-active or active-passive behavior, and enable Bidirectional Forwarding Detection so failover takes seconds instead of the default BGP hold time of around 90 seconds. Jumbo frames, commonly up to about 8,500 to 9,000 bytes of MTU depending on provider, can improve throughput for bulk transfers, but only if every hop supports them.
Limitations and common mistakes
- Assuming the link is encrypted: private does not mean encrypted, so sensitive traffic needs MACsec, IPsec or TLS on top.
- Overlapping IP ranges between on-premises and cloud networks block routing and force painful renumbering.
- Exceeding route limits: providers cap the number of prefixes per BGP session, and exceeding the cap can drop the session.
- Ignoring lead time: cross-connect orders and carrier circuits can take several weeks, which delays migration plans.
- Asymmetric routing when on-premises and cloud prefer different paths, which breaks stateful firewalls.
Cost is another limitation: port fees are charged hourly whether the link is used or not, and colocation space, cross-connects and carrier circuits add recurring charges. For small or intermittent workloads, a well-designed VPN is often the more economical choice.
Understanding it simply
Reaching the cloud over the internet is like driving on public roads. It usually works, but traffic jams happen. A cloud interconnect is like a private road built straight to the cloud provider’s door.
Only the company’s traffic uses that road. Travel time stays steady and predictable, and large loads move quickly. Each load also costs less. The trade-off is a monthly bill for the road itself. A careful company builds two roads in case one is closed.
Applied in practice
A hospital group runs its electronic health records system in its own data center but moves imaging analytics and backups to a public cloud. Each night it transfers about 15 TB of medical images, which over a VPN often took longer than the overnight window and suffered from unpredictable latency.
The network team orders two 10 Gbps dedicated connections in two different colocation facilities, attaches them to a transit gateway that serves six VPCs and keeps an IPsec VPN as a last-resort backup. BGP local preference makes one facility primary, and Bidirectional Forwarding Detection triggers failover within seconds. The nightly transfer now finishes in under five hours, data transfer charges drop compared with internet egress, and a planned maintenance at one facility passes without any interruption to clinical systems.