Cloud Interconnect: Dedicated Private Connections Between On-Prem and GCP

At some point in a company’s cloud journey, Cloud VPN’s limitations stop being theoretical. A VPN tunnel runs over the public internet, encrypted but still subject to internet routing variability, and its throughput ceiling (roughly 3 Gbps per tunnel) becomes a real constraint for a company moving serious data volume between an on-prem data center and GCP — nightly database replication, large-scale backup jobs, or latency-sensitive hybrid application traffic. Cloud Interconnect exists for exactly this point: a dedicated, private physical or logical connection between your infrastructure and Google’s network, bypassing the public internet entirely.

The decision between VPN and Interconnect, and between the two Interconnect flavors, comes down to three factors that are worth being explicit about before any procurement conversation starts: required bandwidth, tolerance for public-internet routing variability, and whether you have (or can get) a physical presence in a facility where Google’s network is directly reachable.

Dedicated vs Partner Interconnect

┌─────────────────────┬──────────────────────────────────────────┐
│ Type                   │ How it works                                │
├─────────────────────┼──────────────────────────────────────────┤
│ Dedicated Interconnect  │ A direct physical fiber connection between  │
│                        │ your equipment and Google's, in a Google    │
│                        │ colocation facility — you need presence      │
│                        │ in that facility (or use a colocation        │
│                        │ provider that does)                          │
│ Partner Interconnect    │ A connection through a supported service    │
│                        │ provider who already has infrastructure       │
│                        │ connected to Google — no need for your own    │
│                        │ presence in a Google facility                 │
└─────────────────────┴──────────────────────────────────────────┘

Dedicated Interconnect requires a real physical presence — your network equipment in the same colocation facility as a Google Cloud edge point of presence, connected via a direct fiber cross-connect. This gets you the highest bandwidth tiers (10 Gbps or 100 Gbps circuits) and the lowest possible latency, but it’s a genuine infrastructure commitment: physical cross-connects, facility access, and typically a multi-month provisioning timeline.

Partner Interconnect routes through a telecom or network service provider that already maintains connectivity to Google — you order a circuit from the partner rather than provisioning your own physical connection to a Google facility. This is the more accessible option for most companies, offering lower bandwidth tiers (starting well below the Dedicated minimums) and dramatically faster provisioning, at the cost of an additional party in the connectivity chain.

Why Redundancy Isn’t Optional

A single Interconnect connection is a single point of failure by definition — a fiber cut, a hardware failure at the colocation facility, or a maintenance event on that one link takes down all hybrid connectivity through it. Google’s SLA-backed availability guarantees explicitly require redundant connections in diverse locations, not just multiple links.

┌──────────────────────────────────────────────────────────┐
│              99.99% Availability SLA Requirement            │
├──────────────────────────────────────────────────────────┤
│  Two Dedicated Interconnect connections                     │
│  in two DIFFERENT metro locations                            │
│  (not two connections in the same building)                  │
│                                                              │
│  On-prem router A ──── Connection 1 ──── Google Edge (Metro 1)│
│  On-prem router B ──── Connection 2 ──── Google Edge (Metro 2)│
└──────────────────────────────────────────────────────────┘

“Two connections in the same facility” doesn’t satisfy the redundancy requirement Google’s higher availability SLA tiers demand — a facility-level event (power outage, fiber cut affecting the whole building) would still take down both connections simultaneously. Genuine redundancy means diverse metro locations, which is a real architectural and cost commitment, not a checkbox — but it’s the difference between “resilient hybrid connectivity” and “hybrid connectivity that works until the one thing that takes down a data center happens.”

Setting Up a VLAN Attachment

Once the physical (Dedicated) or provider (Partner) circuit exists, a VLAN attachment is the logical configuration that actually carries traffic for a specific VPC:

gcloud compute interconnects attachments dedicated create my-vlan-attachment \
  --router=my-cloud-router \
  --interconnect=my-dedicated-interconnect \
  --region=us-central1 \
  --vlan=100 \
  --bandwidth=BPS_10G

A single physical Interconnect connection can carry multiple VLAN attachments, each mapped to a different VPC or region — this is how one physical circuit efficiently serves multiple logical network needs (production VPC, staging VPC, a Shared VPC host project) without requiring a separate physical connection per use case.

Cloud Router and BGP: How Routes Actually Propagate

Interconnect doesn’t just move packets — it needs a routing protocol to tell each side what’s reachable through the connection, and that’s Cloud Router speaking BGP:

gcloud compute routers create my-cloud-router \
  --network=my-vpc \
  --region=us-central1 \
  --asn=65001

gcloud compute routers add-bgp-peer my-cloud-router \
  --peer-name=on-prem-peer \
  --interface=my-vlan-attachment-interface \
  --peer-asn=65002 \
  --peer-ip-address=169.254.0.2

Cloud Router dynamically advertises your VPC’s subnet ranges to your on-prem router over BGP, and learns your on-prem ranges in return — routes update automatically as your VPC’s subnets change, without manual static route updates on either side. This is a meaningful operational advantage over static routing: a new subnet added to your VPC becomes reachable from on-prem automatically, the moment Cloud Router advertises it, rather than requiring a coordinated manual change on both ends of the connection.

Route advertisement scope deserves the same deliberate attention as firewall rule scope — Cloud Router can be configured to advertise all VPC subnets automatically, or only a specific, explicitly listed set. For hybrid environments where on-prem systems shouldn’t have visibility into every internal subnet (a staging environment’s address space, say), custom advertisement scoped to only the ranges that genuinely need cross-boundary reachability is the more disciplined default than accepting broad automatic advertisement out of convenience.

Failover Behavior: What Actually Happens When a Link Dies

Redundancy only matters if failover actually works the way you expect under a real failure — worth walking through explicitly rather than assuming.

The failover speed depends heavily on BGP timer configuration (keepalive and hold-down timers) — tuned aggressively, failover can happen in single-digit seconds; left at conservative defaults, it can take considerably longer. This is a genuine design decision worth making deliberately rather than accepting whatever default Cloud Router ships with, especially for latency-sensitive hybrid applications where even a 30-60 second outage during failover is a real, customer-visible problem.

Real-World Use Case: Gradual Data Center Migration

A company migrating workloads from an on-prem data center to GCP over an extended period — often a year or more for anything nontrivial — is the classic Interconnect use case. During the migration, some services run on-prem and some run on GCP, with real dependencies between them (an on-prem application calling a newly-migrated GCP-hosted API, or a GCP workload needing to query an on-prem database that hasn’t moved yet). Interconnect provides the private, high-bandwidth, low-latency path this hybrid state depends on — VPN alone would likely be a bandwidth and latency bottleneck for the volume of cross-environment traffic a genuine mid-migration hybrid architecture generates over many months.

Real-World Use Case: Regulatory Requirement for Private Connectivity

Some regulatory frameworks, particularly in finance and healthcare, require that certain categories of sensitive data never traverse the public internet, even encrypted. A VPN tunnel, despite being encrypted, still technically routes over the public internet’s infrastructure — Interconnect’s dedicated private path satisfies a stricter “never touches the public internet” requirement that some compliance frameworks specifically call for, which is a real, non-negotiable driver for choosing Interconnect over VPN regardless of bandwidth needs.

Best Practices

• Always provision redundant connections in genuinely diverse metro locations for anything production-critical — a single Interconnect connection, however fast, is still a single point of failure.
• Use Partner Interconnect unless you have a specific reason requiring Dedicated’s higher bandwidth tiers or lowest possible latency — the faster provisioning and lower operational commitment usually outweighs Dedicated’s advantages for all but the highest-volume use cases.
• Design BGP route advertisement deliberately, not just accepting all routes by default — advertising or accepting more routes than necessary expands the blast radius of a misconfiguration on either side.
• Monitor Interconnect link utilization proactively. A connection nearing capacity degrades gracefully at first and then badly — catching the trend before it becomes an incident is far better than discovering it during a traffic spike.

Common Mistakes

Provisioning “redundant” connections that share a single point of failure. Two connections through the same colocation facility, the same regional power grid, or the same physical conduit don’t provide the resilience the redundancy requirement is actually meant to deliver.

Underestimating Dedicated Interconnect’s provisioning timeline. Physical cross-connects in a colocation facility take real time — weeks to months depending on facility and circumstances — and treating this like a same-week cloud resource provisioning task leads to painful project timeline surprises.

Advertising overly broad route ranges over BGP. Advertising an entire private address space rather than the specific ranges that actually need connectivity unnecessarily widens what’s reachable across the hybrid boundary, which is both a security and a troubleshooting-complexity concern.

Frequently Asked Questions

Is Cloud Interconnect encrypted? Dedicated Interconnect traffic is not encrypted by default at the network layer (it relies on the physical private connection’s inherent isolation from the public internet) — for workloads requiring encryption in transit even over a private connection, application-layer TLS or an additional VPN-over-Interconnect layer (HA VPN) can be added.

What’s the minimum bandwidth commitment for Partner Interconnect? Partner Interconnect typically starts at much lower bandwidth tiers than Dedicated (often as low as 50 Mbps, scaling up), making it accessible to organizations that don’t need Dedicated’s 10 Gbps+ starting point.

Can I combine Interconnect and Cloud VPN for the same hybrid environment? Yes — a common pattern uses Interconnect for the primary high-bandwidth path and VPN as a backup route that activates automatically via BGP route priority if the Interconnect connection fails, giving genuine failover without requiring a second physical circuit.

How is pricing structured for Interconnect? Pricing includes a port/circuit cost (for Dedicated) or a partner-billed circuit cost (for Partner), plus egress data transfer charges — egress over Interconnect is typically priced lower than standard internet egress, which is itself a meaningful cost incentive for high-volume hybrid traffic beyond the performance benefits.

How quickly does failover actually happen if one connection goes down? With properly tuned BGP timers, failover typically completes in single-digit to low tens of seconds — the exact figure depends on keepalive and hold-down timer configuration, which is worth tuning deliberately rather than leaving at defaults for latency-sensitive workloads.

Do I need Cloud Router if I only have one Interconnect connection? Yes — Cloud Router and BGP are required for any Interconnect connection to actually exchange routes, regardless of whether redundancy is in place. Redundancy is a separate architectural decision layered on top of the basic BGP requirement.

Summary

Cloud Interconnect exists for the point where VPN’s bandwidth ceiling, public-internet routing variability, or a compliance requirement for private-only connectivity becomes a real constraint rather than a theoretical one. Partner Interconnect covers the large majority of practical use cases without the physical infrastructure commitment Dedicated requires, and either way, genuine redundancy across diverse metro locations — not just multiple connections in one facility — is what separates a resilient hybrid architecture from one that works fine right up until the specific failure nobody planned for actually happens.