Cloud Interconnect & VPN
Cloud Interconnect and Cloud VPN are the two ways to connect a GCP VPC to networks outside it — on-prem data centers, colocated infrastructure, other clouds. Both extend the VPC's reach without exposing traffic to the public internet, but they differ in capacity, latency, SLA, and cost by an order of magnitude.
The choice is straightforward once the bandwidth need is known. Cloud VPN runs over the public internet using IPsec, capped by VPN throughput limits and internet routing. Cloud Interconnect runs over a dedicated physical link into a Google peering location, with throughput that scales to 400 Gbps per port. This page closes the chapter by tying the VPC to the world outside it.
Cloud VPN: HA VPN vs Classic VPN
HA VPN establishes two IPsec tunnels from two interfaces on the Google side to your on-prem VPN gateway, providing the 99.99% SLA and automatic failover. Classic VPN uses a single tunnel and carries only a 99.9% SLA with no automatic failover; Google has deprecated it for new deployments with dynamic routing. For new VPN setups, always HA VPN. Throughput per tunnel is up to 3 Gbps depending on average packet size (capped at 250,000 packets per second); HA VPN with both tunnels active reaches up to roughly 6 Gbps in total. Anything beyond that is the realm of Cloud Interconnect.
Cloud Interconnect: Dedicated vs Partner
Dedicated Interconnect is a direct physical link between your equipment in a Google peering location and Google's network. Available in 10 Gbps, 100 Gbps, or 400 Gbps ports, with multiple ports for redundancy. You need physical presence at a Google PoP (own colo or via a network provider). Reserve it for sustained bandwidth in the multi-Gbps range where the dedicated cost is justified.
Partner Interconnect uses a service provider that has its own Dedicated Interconnect, reselling capacity to customers in 50 Mbps to 50 Gbps increments. Less commitment, more locations, slightly higher cost per Mbps. The right answer when bandwidth is moderate or your physical presence does not coincide with a Google PoP.
Cloud VPN (HA VPN) — IPsec over public internet. Up to a few Gbps. 99.99% SLA. Fast to set up, no physical infrastructure. The right choice for low-to-moderate bandwidth, dev/test connectivity, or where the latency variability of public internet routing is acceptable.
Cloud Interconnect (Dedicated or Partner) — dedicated private link to Google. From 50 Mbps on Partner up to 400 Gbps ports on Dedicated. Predictable low latency, no internet path. The right choice for sustained high bandwidth, latency-sensitive workloads, or data egress at scale where Interconnect pricing beats public-internet egress.
Cross-Cloud Interconnect
Cross-Cloud Interconnect is a Dedicated Interconnect that connects directly to another cloud provider's network at a shared peering facility. The use case: multi-cloud architectures that route significant traffic between GCP and AWS or Azure. The alternative — sending the same traffic over the public internet via VPN — costs more in egress and adds latency. For occasional cross-cloud calls, public-internet egress is fine; for sustained inter-cloud workloads, Cross-Cloud Interconnect pays for itself quickly.
BGP and Dynamic Routing
Cloud Router is the BGP daemon that exchanges routes between your VPC and the remote network across an Interconnect or VPN. Static routes work for the simplest setups; for anything multi-region or with failover, BGP is mandatory. The most common BGP misconfiguration is asymmetric routing — outbound takes one path, return traffic takes another — caused by MED (multi-exit discriminator) values that disagree across regions. Symmetric routing is essential for stateful services; verify it explicitly before declaring the link production-ready.
Network Connectivity Center
Network Connectivity Center (NCC) is a hub-and-spoke model for managing many hybrid links: VPNs, Interconnects, third-party SD-WAN spokes, even cross-cloud connections. The hub acts as a transit point for the spokes — site-A to site-B traffic transits the hub instead of needing direct spoke-to-spoke configuration. For a topology with more than five connections to maintain, NCC reduces the operational surface dramatically. Below that, the explicit per-link setup is usually clearer.
Bandwidth, SLA, and Cost Trade-offs
Interconnect is not just more bandwidth — latency predictability is what drives the choice for trading, streaming, and real-time sync.
Decision shortcut: under ~3 Gbps sustained, HA VPN is cheaper, faster to deploy, and gives a 99.99% SLA. 3 to 50 Gbps sustained, Partner Interconnect is the right answer unless you already have physical presence in a Google PoP. Above 50 Gbps or with strict latency requirements, Dedicated Interconnect. Reserve 30 to 40% capacity headroom — Interconnect ports are sold in fixed sizes, and running at 90% utilization leaves no room for traffic spikes or one-link failures.
- Deploying Classic VPN for new connectivity — deprecated, no SLA, no automatic failover.
- Choosing Dedicated Interconnect when sustained bandwidth does not justify it — Partner Interconnect would deliver the same connectivity at a fraction of the commitment.
- HA VPN with both tunnels connected to one on-prem VPN device — the on-prem device becomes the single point of failure even though Google's side is redundant.
- Asymmetric BGP routing from mismatched MED values — outbound and return traffic take different paths, breaking stateful services in subtle ways.
- Sustained multi-cloud traffic over public-internet egress instead of Cross-Cloud Interconnect — large recurring egress bills that would pay back the dedicated link in months.
- Running Interconnect at 90%+ utilization without headroom — the next traffic spike or single-link failure causes degraded service, with no margin to absorb it.
- Ad-hoc per-link configuration for a topology that has grown past 5 connections — Network Connectivity Center exists precisely for this case.
- HA VPN as the default for any new VPN setup. Treat Classic VPN as legacy and migrate when convenient.
- Pair HA VPN tunnels across two physically separate on-prem VPN devices so the on-prem side is also redundant.
- Partner Interconnect when bandwidth is moderate or you do not have physical presence at a Google PoP. Dedicated Interconnect when you do and bandwidth justifies it.
- Cross-Cloud Interconnect for sustained multi-cloud traffic. Public-internet egress is fine only for occasional cross-cloud calls.
- Use BGP via Cloud Router for any multi-region or failover-capable setup. Verify symmetric routing explicitly before going live.
- Network Connectivity Center for topologies with 5+ hybrid links. The hub-and-spoke model is the operational difference between manageable and unmanageable.
- Reserve 30 to 40% capacity headroom on Interconnect ports. Plan capacity reviews quarterly.
Knowledge Check
For a new GCP-to-on-prem VPN setup, which option should you choose?
- Classic VPN — simpler configuration with a single tunnel
- HA VPN — two tunnels with automatic failover and a 99.99% SLA; the only choice for production
- Either; they are functionally equivalent under normal operation
- Dedicated Interconnect — VPN tunnels are never appropriate for production traffic and must always be replaced by a private physical link
When does Partner Interconnect typically beat Dedicated Interconnect?
- When the workload needs latency under 10 ms, because routing through the partner's network gives Partner Interconnect measurably lower jitter than a direct Dedicated link
- When bandwidth needs are moderate or you do not have physical presence at a Google peering location — Partner gives smaller increments and uses an existing partner network
- When traffic encryption is mandatory, since Dedicated Interconnect carries no encryption at all while Partner Interconnect encrypts every circuit end to end by default in transit
- When you need IPv6 — Dedicated Interconnect is IPv4-only
A stateful service over an Interconnect starts misbehaving in subtle ways: some flows succeed, others time out unpredictably. What is a likely BGP-level cause?
- The Interconnect port is saturated and BGP sessions are flapping
- Asymmetric routing caused by mismatched MED values — outbound and return traffic take different paths, breaking stateful connection tracking
- DNSSEC validation on the corporate DNS resolver is intermittently failing, so some flows resolve the endpoint while others fall back to a stale cached address
- Cloud NAT is rotating IPs faster than BGP can propagate updates
When does Cross-Cloud Interconnect pay for itself relative to public-internet egress between clouds?
- For any cross-cloud traffic, no matter how small — Cross-Cloud Interconnect is always cheaper
- When inter-cloud traffic is sustained and large enough that egress charges on the public path become significant; for occasional calls, public egress is fine
- Only when both clouds sit in the same region and are physically colocated in the same carrier-neutral facility, since the direct link cannot span distant metros
- Only when one of the clouds is Azure, because AWS offers no equivalent and cannot terminate a direct cross-cloud link with Google's network
When is Network Connectivity Center the right tool?
- For any setup with at least one VPN tunnel, since NCC is a hard requirement for managing the Cloud Router BGP sessions and route exchange that every individual hybrid tunnel depends on
- For topologies that have grown past a handful of hybrid links (VPNs, Interconnects, SD-WAN spokes), where managing each link in isolation becomes operationally expensive
- Only for cross-cloud connectivity between providers; NCC plays no role in GCP-to-on-prem traffic, which is always handled by Cloud Router on its own
- Whenever you need IPv6 dual-stack support across hybrid links
You got correct