GCP Hybrid Connectivity Explained: Cloud VPN vs Interconnect

What hybrid connectivity means in GCP

Hybrid connectivity is the term GCP uses for any network connection between a GCP Virtual Private Cloud (VPC) and a network that lives outside Google Cloud, typically an on-premises data centre, a branch office, or another private environment.

Without a hybrid connection, your on-premises systems and your GCP workloads are isolated. Any communication between them would have to go through the public internet with no controls. Hybrid connectivity solves this by creating a defined, manageable path between the two environments where you control the routing, the security boundaries, and the performance profile.

GCP offers three services for this: Cloud VPN, Dedicated Interconnect, and Partner Interconnect. They differ significantly in how traffic travels, what speeds they support, how long they take to set up, and what they cost. Choosing between them is one of the first and most consequential decisions in any hybrid architecture.

A plain-English explanation

Think of your GCP VPC as a private office network hosted inside Google’s infrastructure. Your on-premises environment is your own building: servers, databases, and systems that you manage directly.

Hybrid connectivity is the link between these two places. It lets a database query from a GCP workload reach an on-premises server. It lets a backup job send data from your premises into Cloud Storage. It lets a team migrate services gradually, running some components in GCP and some on-premises, without rebuilding everything at once.

The three options describe how that link is created: through encrypted tunnels on the public internet (Cloud VPN), through a private physical cable directly into Google’s network (Dedicated Interconnect), or through a provider who already has private access to Google’s network on your behalf (Partner Interconnect).

Why organisations use hybrid connectivity

The need for hybrid connectivity comes up in almost every serious GCP deployment. Common reasons include:

• Gradual cloud migration. Teams move one service at a time to GCP while the rest of the system stays on-premises. The migrated parts need to communicate with what remains.
• Keeping legacy systems on-premises. Some systems (older ERP platforms, mainframes, or specialised hardware) cannot move to the cloud. GCP workloads still need to reach them.
• Accessing on-premises databases and internal services. Applications running in GCP might depend on databases, authentication systems, or internal APIs that live on-premises.
• Burst capacity. Organisations run baseline workloads on-premises but extend into GCP for additional capacity during peak periods.
• Disaster recovery. GCP acts as a recovery environment for on-premises systems, requiring reliable, tested connectivity between the two. See disaster recovery strategies in GCP for how this fits into a broader DR design.
• Compliance and data sovereignty. Regulated organisations may need to keep certain data on-premises while using GCP for processing or analytics, requiring controlled, auditable connectivity between environments.
• Shared services architectures. Centralised infrastructure teams provide shared services like monitoring, identity, and logging from on-premises, and GCP workloads consume them over a hybrid connection.

Your three main options

Cloud VPN

Cloud VPN establishes IPsec-encrypted tunnels between your on-premises VPN gateway and a Cloud VPN gateway in GCP. Traffic is encrypted before it leaves your network and decrypted at the other end. It travels across the public internet, but the contents are protected.

• How traffic flows: your premises → public internet (encrypted) → Cloud VPN gateway → VPC
• Setup time: minutes to hours, with no physical provisioning required
• Bandwidth: up to approximately 3 Gbps per tunnel; multiple tunnels can be configured for higher aggregate throughput
• Reliability: High Availability VPN offers a 99.99% availability SLA when configured with BGP and two gateway interfaces; Classic VPN has no HA SLA and should not be used for new deployments
• Cost: low; you pay per tunnel-hour plus standard egress fees, with no circuit fees
• Best for: low to moderate bandwidth needs, development and test environments, fast startup, or budget-constrained scenarios
• Biggest limitation: public internet transit means variable latency and bandwidth; each tunnel is capped at approximately 3 Gbps

Dedicated Interconnect

Dedicated Interconnect is a direct physical connection between your on-premises network and Google’s network at a supported colocation facility. You provision one or more private circuits, and traffic never leaves Google’s infrastructure or touches the public internet.

• How traffic flows: your premises → colocation cross-connect → Google’s network → VPC
• Setup time: weeks to months, requiring physical work at a colocation facility
• Bandwidth: 10 Gbps or 100 Gbps per circuit; multiple circuits can be bundled for higher capacity
• Reliability: up to 99.99% SLA with four or more circuits across two Metro locations
• Cost: higher circuit fees, but no standard internet egress charges for traffic over the connection, which is a meaningful saving for large data volumes
• Best for: large or sustained data transfers, latency-sensitive workloads, predictable performance, and compliance requirements that prohibit internet transit
• Biggest limitation: requires physical presence at a Google-supported colocation facility, with long provisioning lead times and a higher baseline cost

Partner Interconnect

Partner Interconnect uses a supported network service provider to connect your on-premises environment to GCP. The provider has its own physical connection into Google’s network. You connect to the provider, who routes your traffic into Google’s network on your behalf. Traffic does not traverse the public internet.

• How traffic flows: your premises → provider network → Google’s network → VPC
• Setup time: days to weeks, depending on your provider’s process
• Bandwidth: 50 Mbps to 50 Gbps, depending on the provider and tier
• Reliability: up to 99.99% SLA with redundant connections via two Metro areas or two providers
• Cost: varies by provider; typically lower than Dedicated Interconnect for lower bandwidth tiers, though provider fees apply
• Best for: organisations not physically located near a Google colocation facility, those needing sub-10 Gbps private connectivity, or those who prefer to manage the connection through an existing provider relationship
• Biggest limitation: you depend on your provider for provisioning, SLA, and support; bandwidth is capped below Dedicated Interconnect maximums

Comparison at a glance

How hybrid connectivity works

The conceptual model is straightforward, even if the implementation details differ between options.

Your GCP VPC is a private network inside Google’s infrastructure. Your on-premises environment is a network outside it. By default, these two networks cannot communicate. They have no shared path.

Hybrid connectivity creates that path. Here is how it works step by step:

1. A connection is established. Either through encrypted tunnels (Cloud VPN), a physical cross-connect at a colocation facility (Dedicated Interconnect), or through a provider who connects you to Google (Partner Interconnect).
2. VLAN attachments or tunnel interfaces are created. These are the logical endpoints inside GCP that the connection terminates on. They provide an interface through which traffic enters and exits your VPC.
3. Cloud Router establishes BGP sessions. Cloud Router peers with your on-premises router over the connection. Each side advertises the routes it knows about: VPC subnets from the GCP side, on-premises prefixes from your side.
4. Routes are distributed. Once BGP sessions are established, traffic between the two environments can be routed correctly. A VM in your VPC can reach an on-premises server by its private IP address, and vice versa.
5. Traffic flows over the connection. Packets travel through the path you configured: encrypted tunnels, private circuits, or the provider network, depending on which option you chose.

The role of Cloud Router and BGP

Cloud Router is the GCP service that handles route exchange for hybrid connectivity. Understanding what it does, and what it does not do, prevents a common category of configuration mistakes.

Cloud Router is a control plane service, not a data plane device. Traffic does not flow through Cloud Router. Traffic flows through your VPN tunnels or Interconnect circuits. What Cloud Router does is manage routing information: which networks are reachable, and how to get there.

Cloud Router uses BGP (Border Gateway Protocol) to exchange route information with your on-premises router. In practice this means:

• Cloud Router advertises your GCP VPC subnet ranges to your on-premises router
• Your on-premises router advertises your on-premises network prefixes to Cloud Router
• Both sides store these learned routes and use them to forward traffic correctly
• If a subnet changes, BGP automatically propagates the update with no manual reconfiguration needed

This is why static routing is generally the wrong default for production hybrid networking. With static routes, every subnet change requires a manual update in both GCP and your on-premises router. That is easy to miss, and a missed update means connectivity breaks when subnets change.

High Availability VPN requires Cloud Router with BGP and does not support static routing at all. Dedicated Interconnect and Partner Interconnect also require BGP via Cloud Router. If you are setting up any production hybrid connection in GCP, you will be using Cloud Router.

# Create a Cloud Router for use with hybrid connectivity
gcloud compute routers create on-prem-router \
  --network=my-vpc \
  --region=europe-west1 \
  --asn=65000

# Check Cloud Router status and BGP session state
gcloud compute routers get-status on-prem-router \
  --region=europe-west1

When to use each option

Use Cloud VPN when:

• You need connectivity quickly, in hours rather than weeks
• Your bandwidth needs are below a few gigabits per second
• You are connecting a development or test environment
• Budget is a constraint and Interconnect costs are not justified at your scale
• You need a temporary solution while Dedicated Interconnect is being provisioned
• Your compliance requirements allow internet transit, provided traffic is encrypted

Use Dedicated Interconnect when:

• You need sustained high-bandwidth connectivity (10 Gbps or more)
• Your workloads are latency-sensitive and cannot tolerate internet variability
• Your compliance or regulatory requirements prohibit internet transit
• You transfer large data volumes consistently, and reduced egress pricing justifies the circuit cost
• You or your colocation provider already has equipment at a Google-supported colo facility
• You need the highest reliability tier and can provision four or more circuits across two Metro locations

Use Partner Interconnect when:

• Your data centre is not located near a Google-supported colocation facility
• You need private connectivity (no internet transit) at less than 10 Gbps
• You have an existing relationship with a Google-supported network provider
• The operational overhead of managing a colocation cross-connect is not worth it at your scale
• Your provider can meet your SLA requirements through their own redundancy

Dedicated Interconnect vs Partner Interconnect

Both options provide private connectivity and traffic does not traverse the public internet. But they differ significantly in how the physical connection is established and who manages it.

Dedicated Interconnect is a direct physical circuit between your equipment and Google’s equipment at a colocation facility. You (or your colo provider on your behalf) establish a cross-connect. The circuit terminates directly on Google’s edge hardware, giving you full control over the physical and logical configuration.

This means Dedicated Interconnect is only available where Google has a supported colocation presence. If your data centre is not in one of those cities, you would need to haul traffic to a colo location first, adding cost and complexity.

Partner Interconnect removes that geographic constraint. Your network provider already has a physical connection into Google’s network at a colo. You connect to the provider, anywhere they have coverage, and the provider routes your traffic into Google’s network. You get private connectivity without needing your own colo presence.

The practical trade-offs:

• Bandwidth ceiling: Dedicated Interconnect reaches 100 Gbps per circuit; Partner Interconnect tops out at 50 Gbps and many providers offer lower tiers
• Provisioning: Dedicated Interconnect involves physical work at the colo, which takes longer; Partner Interconnect depends on your provider’s process, which can be faster
• Control: Dedicated Interconnect gives you direct ownership of the circuit; Partner Interconnect introduces a dependency on your provider for support and changes
• Geographic reach: Partner Interconnect covers more locations because providers extend Google’s reach; Dedicated Interconnect is limited to Google’s colo presence
• Cost structure: Dedicated Interconnect has predictable circuit fees from Google directly; Partner Interconnect involves provider pricing, which varies

Designing for redundancy

A single tunnel or circuit is always a single point of failure. For production hybrid connectivity, redundancy is not optional. It is how you achieve the availability SLAs that GCP offers. See designing highly available systems in GCP for the broader principles behind availability architecture.

Here is what good redundancy looks like for each option:

• Cloud VPN (HA VPN): two VPN gateways, each with two interfaces, providing four tunnels in total. BGP sessions should run over all four tunnels. This configuration qualifies for the 99.99% availability SLA.
• Dedicated Interconnect (99.99%): at least four VLAN attachments across two circuits in two different Metro locations. Each Metro location should use circuits connected to different edge availability domains within that Metro. With two circuits per Metro and two Metros, no single failure takes down all paths.
• Partner Interconnect (99.99%): VLAN attachments across two different Metro areas, using either two different providers or two different edge availability domains of the same provider.

The 99.9% SLA tier (two paths within one Metro) is achievable with less infrastructure, but it does not protect against a Metro-level failure. For genuinely critical connectivity, the 99.99% topology across two Metro areas is the right target.

Example decision scenarios

Real decisions are rarely abstract. Here are a few realistic examples that show how the choice plays out in practice:

A small team connecting an office to GCP quickly

A startup team needs to connect their office network to a GCP project so developers can access private GCP resources. They need connectivity today, not in six weeks. Budget is limited. Cloud VPN is the obvious choice. They can be up and running in under an hour, and a few gigabits per second of bandwidth is more than enough.

A company replicating multi-terabyte data volumes nightly

An analytics team runs a nightly job that transfers several terabytes from on-premises databases to BigQuery. The transfers are predictable, high-volume, and the team is already paying significant internet egress charges through Cloud VPN. At this scale, Dedicated Interconnect pays for itself through reduced egress costs and delivers more reliable transfer speeds. The provisioning lead time is manageable given the project timeline.

A business not located near a Google colocation site

A mid-sized company has a data centre in a city without a Google-supported colo presence. They need private connectivity, as internet transit is not acceptable for their compliance requirements. Partner Interconnect through a regional network provider that already has access to Google’s network is the practical path. They avoid renting colo space in another city just to terminate a circuit.

A regulated workload where internet transit is not acceptable

A financial services firm is migrating a core system to GCP. Their security team prohibits any transit over the public internet, even encrypted. Cloud VPN is out entirely. The decision becomes whether they are near a Google colo (Dedicated Interconnect) or whether a partner provider can reach them (Partner Interconnect). Both qualify from a compliance standpoint. The final choice comes down to bandwidth, cost, and existing provider relationships.

A temporary bridge during an Interconnect provisioning period

A team has approved budget for Dedicated Interconnect but has a project milestone before the circuit is ready. They stand up HA VPN to unblock development immediately, then migrate traffic to Interconnect once it is provisioned. This is a common and sensible pattern: Cloud VPN as a bridge, Interconnect as the long-term solution.

Related architecture considerations

Hybrid connectivity does not exist in isolation. Once your on-premises network and GCP VPC are connected, several adjacent concerns come up:

• DNS resolution across environments. Systems in GCP need to resolve on-premises hostnames, and on-premises systems may need to resolve GCP private DNS names. This requires DNS forwarding zones on both sides. See DNS in GCP and private DNS zones for how to configure this.
• Firewall rules. Connecting networks does not automatically allow traffic. You still need firewall rules that permit the specific traffic flows you intend. Overly permissive rules between environments are a common security gap in hybrid designs.
• Overlapping IP ranges. If your on-premises network and GCP VPC use overlapping IP address ranges, routing breaks. Plan IP ranges before establishing connectivity. VPC subnets and on-premises prefixes must be non-overlapping for routes to work correctly.
• Shared VPC. If your organisation uses Shared VPC, hybrid connectivity terminates in the host project’s VPC and is accessible to service projects through the shared network. The design of your Shared VPC structure affects how on-premises connectivity flows to individual projects.
• Security controls. Hybrid connectivity expands the network surface between your on-premises and cloud environments. Review your security posture with the GCP network security best practices guide, paying particular attention to east-west traffic between environments.
• Monitoring and troubleshooting. Use Cloud Monitoring to track VPN tunnel states, BGP session health, and Interconnect circuit status. When things go wrong, the network troubleshooting guide covers the diagnostic steps for hybrid connectivity issues specifically.