Cloud Interconnect in GCP: Dedicated vs Partner Interconnect Explained

What Cloud Interconnect is, in plain English

When a workload in GCP needs to communicate with something still running in your data centre, such as a database, an internal service, or a legacy system, that traffic needs a path between the two environments. The simplest path is the internet, which is exactly what Cloud VPN uses: encrypted tunnels over the public internet.

Cloud Interconnect takes a different approach. Instead of routing traffic through the internet, it creates a private path that connects your on-premises network directly into Google’s network. From there, your traffic reaches your VPC without ever touching public internet infrastructure.

Within Cloud Interconnect there are two options. Dedicated Interconnect means you physically co-locate your router next to Google’s edge equipment in a data centre. Partner Interconnect means you connect through a service provider who already has that physical connection in place.

What Cloud Interconnect is used for

Cloud Interconnect is the right tool when the public internet does not meet your requirements:

• High-volume hybrid traffic. Workloads that move large amounts of data between on-premises and GCP regularly find that Interconnect’s lower egress rate reduces costs significantly compared to internet egress. See Network Egress Costs for how egress pricing works across GCP services.
• Latency-sensitive applications. Financial transaction processing, real-time analytics, and synchronised databases all benefit from a private path with no shared congestion and predictable round-trip times.
• Compliance and data residency. Some regulations require that data never transit public infrastructure. Interconnect keeps traffic entirely on private network paths, satisfying requirements that Cloud VPN cannot.
• Consistent high-bandwidth connectivity. If you need sustained multi-gigabit throughput between environments, Interconnect offers far more headroom than VPN tunnels, which top out at around 3 Gbps each.
• Hybrid applications spanning environments. Teams running compute in GCP while keeping storage or sensitive processing on-premises use Interconnect to create a reliable, performant bridge between both environments.
• Large-scale data migration. Initial transfer of large datasets from on-premises to GCP is more predictable and often faster over a dedicated private circuit.

If none of these apply, if your data volume is modest and internet-based encryption is acceptable, Cloud VPN is simpler to set up and costs significantly less to run.

How Cloud Interconnect works

Here is what happens end-to-end, from your data centre to a workload running in GCP:

1. Your on-premises router. This is the starting point. Your router connects to the Interconnect circuit, either directly via a cross-connect at a colocation facility (Dedicated) or through your service provider’s network (Partner).
2. The physical circuit or provider path. For Dedicated Interconnect, this is a fibre cross-connect between your equipment and Google’s edge routers at a colocation facility where Google has a point of presence (PoP). For Partner Interconnect, your traffic travels through your provider’s private network, which already has its own connection to Google.
3. VLAN attachments. A physical circuit is divided into logical segments called VLAN attachments. Each attachment has a VLAN ID and connects to a specific Cloud Router in a region. You can have multiple VLAN attachments on a single circuit: one for production, one for development, or one per VPC.
4. Cloud Router. Each VLAN attachment terminates at a Cloud Router. The Cloud Router runs BGP with your on-premises router over this attachment, advertising your VPC’s subnets and learning your on-premises prefixes in return. See Routes in GCP for how these routes propagate through your VPC once learned.
5. BGP route exchange. Once the BGP session is established, routes flow in both directions automatically. Your on-premises router learns which IP ranges exist in your VPC; your VPC learns which ranges exist on-premises. No static routes needed.
6. Traffic into your VPC. Traffic destined for on-premises IP ranges from your VPC uses the Interconnect path automatically, and traffic from on-premises destined for VPC ranges arrives through the same path.

Dedicated Interconnect

Dedicated Interconnect is a direct physical fibre connection between your on-premises network and Google’s edge at a colocation facility. Google has points of presence (PoPs) at major data centres worldwide. You, or your colocation provider, provision a cross-connect from your equipment to Google’s equipment in the same facility.

Circuit sizes are 10 Gbps or 100 Gbps. You can provision multiple circuits and aggregate them for higher bandwidth and redundancy. Google maintains the circuit on its side; you are responsible for the cross-connect and your on-premises router configuration.

When Dedicated Interconnect fits best

• You already have equipment at a facility where Google has a PoP, or you are willing to co-locate
• You need more than a few Gbps of consistent throughput
• Your workload has strict latency or jitter requirements
• Compliance or policy requirements prohibit data passing through the public internet
• You transfer large volumes of data from GCP to on-premises and the lower egress rate will offset the circuit cost

Partner Interconnect

Partner Interconnect uses a supported service provider that has already established a physical connection to Google’s network. You connect to the provider through your existing relationship or a new one, and the provider routes your traffic to GCP through their private connection. You never need to be physically present at a Google colocation facility.

Bandwidth tiers range from 50 Mbps to 50 Gbps, depending on the provider. This makes Partner Interconnect more accessible for teams that need less than 10 Gbps or whose data centre is not near a Google PoP.

When Partner Interconnect fits best

• Your data centre is not near a Google colocation facility
• You do not have or want equipment at a colocation facility
• You need less than 10 Gbps of capacity
• You want flexibility to scale bandwidth without changing physical infrastructure
• You already have a relationship with a supported network provider

Dedicated Interconnect vs Partner Interconnect

For a broader comparison that also includes Cloud VPN, see Hybrid Connectivity Overview.

Cloud Interconnect vs Cloud VPN

Both options connect your on-premises network to a GCP VPC, but they work very differently. This is the most common decision teams face when planning hybrid connectivity.

When Cloud VPN is the better choice

• You need connectivity quickly without weeks of physical provisioning
• Your bandwidth requirements are a few Gbps or less
• Internet-based encryption is acceptable for your compliance needs
• You are in an early phase of cloud adoption and have not yet validated long-term bandwidth requirements
• You want a temporary bridge while Dedicated Interconnect is being provisioned

When Cloud Interconnect is worth it

• You need consistent multi-Gbps throughput beyond what VPN tunnels can provide
• Latency predictability matters to your workload
• Data cannot traverse public internet due to compliance or policy
• Ongoing egress volumes are large enough that the lower interconnect egress rate offsets the circuit cost

Key components

Before going deeper into configuration, it helps to understand what each component does and how they fit together:

• Physical circuit or provider connection. The physical path into Google’s network. For Dedicated Interconnect, this is a fibre cross-connect at a colocation facility. For Partner, the provider manages this side.
• VLAN attachments (interconnect attachments). Logical partitions of a circuit. Each attachment has a VLAN ID, a bandwidth allocation, and connects to a Cloud Router in a specific region. One circuit can serve multiple attachments pointing at different VPCs or regions.
• Cloud Router. The BGP speaker on GCP’s side. It exchanges routes with your on-premises router over each VLAN attachment. One Cloud Router can serve multiple attachments in the same region. Routes learned via BGP propagate through your VPC. See Routes in GCP for how this works.
• BGP peers. Each Cloud Router has a BGP peer configured for the on-premises router. Routes are advertised and learned over link-local addresses in the 169.254.x.x range, configured per attachment.
• Redundant paths. For production deployments, redundancy requires multiple circuits distributed across separate physical failure domains. A single circuit is a single point of failure regardless of how many VLAN attachments you create on it.

VLAN attachments

A physical Interconnect circuit carries traffic as tagged VLANs. Each VLAN attachment is a logical slice of that circuit. It has its own VLAN ID, its own bandwidth allocation, and connects to a specific Cloud Router in a region. This lets you segment a single physical circuit across multiple VPCs, teams, or regions without provisioning separate circuits for each.

For example, you could create a production attachment routing to your production VPC and a separate development attachment routing to your dev VPC. Both share the same physical circuit, but each has independent BGP sessions and route tables.

# Create a VLAN attachment for a Dedicated Interconnect circuit
# (The circuit must be provisioned and have a pairing key)
gcloud compute interconnects attachments dedicated create prod-attachment \
  --interconnect=my-interconnect-circuit \
  --router=my-interconnect-router \
  --region=europe-west1 \
  --bandwidth=BPS_1G \
  --vlan=100 \
  --description="Production VLAN attachment"

# Create a VLAN attachment for Partner Interconnect
# (Uses a pairing key from your provider's portal)
gcloud compute interconnects attachments partner create dev-attachment \
  --router=my-interconnect-router \
  --region=europe-west1 \
  --bandwidth=BPS_500M \
  --pairing-key=PAIRING_KEY_FROM_PROVIDER

# Check attachment status
gcloud compute interconnects attachments describe prod-attachment \
  --region=europe-west1

BGP and Cloud Router

BGP (Border Gateway Protocol) is the routing protocol that handles route exchange between your on-premises router and GCP. On GCP’s side, Cloud Router is the BGP speaker. Each VLAN attachment needs a BGP interface on the Cloud Router and a configured BGP peer pointing to your on-premises router.

When the BGP session comes up, Cloud Router advertises your VPC’s subnet ranges to your on-premises network and learns your on-premises prefixes in return. From that point, your workloads can reach each other without any static route configuration. BGP handles redistribution automatically.

The Cloud Router and on-premises router use link-local IP addresses (169.254.x.x) as the BGP session endpoints on each VLAN attachment. These addresses are not routable on the internet; they exist only within the point-to-point session on the attachment.

# Create a Cloud Router for Interconnect BGP
gcloud compute routers create my-interconnect-router \
  --network=my-vpc \
  --region=europe-west1 \
  --asn=65001

# Add a BGP interface for the VLAN attachment
gcloud compute routers add-interface my-interconnect-router \
  --interface-name=interconnect-bgp-if \
  --interconnect-attachment=prod-attachment \
  --ip-address=169.254.0.1 \
  --mask-length=29 \
  --region=europe-west1

# Add the BGP peer (on-premises router)
gcloud compute routers add-bgp-peer my-interconnect-router \
  --peer-name=on-prem-bgp-peer \
  --interface=interconnect-bgp-if \
  --peer-ip-address=169.254.0.2 \
  --peer-asn=65002 \
  --region=europe-west1

# Verify BGP sessions are established
gcloud compute routers get-status my-interconnect-router \
  --region=europe-west1

Designing for high availability

A single VLAN attachment or circuit achieves a 99.9% SLA, which is three nines, or roughly 8.7 hours of allowed downtime per year. To reach 99.99%, which is four nines and around 52 minutes per year, you need redundancy across two independent physical failure domains. The difference matters for production workloads.

What redundancy looks like by type

• Dedicated Interconnect (99.99%): Four VLAN attachments minimum, distributed across two circuits, each circuit in a different colocation facility or different edge availability domains within the same facility.
• Partner Interconnect (99.99%): VLAN attachments in two different Metro areas, or attachments via two different providers in the same Metro area with separate edge availability domains.

For broader thinking on high availability design, see Designing Highly Available Systems.

When to use Cloud Interconnect

Use this as a decision guide, not a checklist. Real environments involve trade-offs.

Interconnect is a strong fit when

• Your sustained bandwidth needs exceed 3 to 5 Gbps consistently
• You move large volumes of data from GCP to on-premises regularly, and the lower interconnect egress rate will offset the circuit cost
• Regulatory or contractual requirements prohibit data transiting public internet infrastructure
• Latency-sensitive workloads need consistent round-trip times without shared congestion
• You already have presence at a Google PoP (Dedicated) or a relationship with a supported provider (Partner)

Cloud VPN is probably enough when

• Your bandwidth needs are a few Gbps or less
• You need connectivity in days, not months
• Encryption over the internet is acceptable for your compliance situation
• You are in an early phase of cloud adoption and have not yet validated long-term bandwidth requirements

Dedicated vs Partner

• Choose Dedicated if you need more than 10 Gbps, or if you already have equipment at a Google PoP facility
• Choose Partner if your data centre is not near a Google PoP, if you need less than 10 Gbps, or if faster provisioning is important to your timeline

Monitoring Interconnect connections

GCP provides Cloud Monitoring metrics for both physical circuits and individual VLAN attachments. Key metrics to track in production:

• interconnect/network/attachment/received_bytes_count — inbound traffic on each attachment
• interconnect/network/attachment/sent_bytes_count — outbound traffic on each attachment
• interconnect/network/link/operational — whether the physical link is up (1) or down (0)

Create an alerting policy on link/operational for each circuit. A link going down means one redundant path is gone. You need to know immediately, before a second failure removes the remaining path entirely.

For attachment-level traffic, monitor utilisation against your provisioned bandwidth. Sustained throughput close to the attachment limit can indicate that you need more capacity or that traffic is not balanced across attachments as expected.

If you encounter connectivity issues after a circuit event, see Troubleshooting Network Issues for diagnostic approaches. Reviewing Network Security Best Practices is also worthwhile before a production Interconnect deployment goes live.

# List metrics available for Interconnect
gcloud monitoring metric-descriptors list \
  --filter='metric.type=starts_with("interconnect/")'

Pricing and cost considerations

Cloud Interconnect costs more than Cloud VPN, but can pay off when data volumes are high. The cost model has a few components:

• Circuit or provider cost. For Dedicated Interconnect, you pay a monthly port fee to Google. For Partner Interconnect, cost depends on your service provider agreement.
• VLAN attachment cost. Each interconnect attachment carries its own charge based on provisioned capacity.
• Egress pricing. Traffic flowing from GCP to your on-premises network via Interconnect is charged at the interconnect egress rate, which is lower than the standard internet egress rate. For workloads that move large amounts of data out of GCP regularly, this difference can be substantial. See Network Egress Costs for a full breakdown.

The economics generally improve as data volume increases. At low volumes, the fixed circuit cost dominates and VPN is cheaper overall. At high volumes, the egress savings and the value of predictable performance start to justify the higher baseline cost. Run the numbers against your actual traffic patterns before committing to a circuit.