Cloud Interconnect is Google Cloud's private, high-bandwidth link between your own network and a VPC. It exists for the traffic that should not ride the public internet or a VPN tunnel: training datasets moving from an on-premises store, replication between a data centre and Cloud SQL or Bigtable, latency-sensitive calls from a factory or trading floor, or steady bulk flows where a fixed link costs less than internet egress.
The product is easy to misread as a single cable. It is three layers, each with its own limits and failure modes: physical connections in colocation facilities, VLAN attachments that tie those connections to a region and a Cloud Router, and BGP sessions that carry routes. Availability depends on how you arrange all three. This article explains each layer, the flavours on offer, the topologies behind the 99.9% and 99.99% SLAs, encryption options and capacity planning, with a worked example and a checklist.
What happens to the routes once they are inside Google Cloud, including hub-and-spoke designs and transit between sites, is covered in Network Connectivity Center. This page stays at the edge.
Three layers: connection, attachment, session
Connection. A Dedicated Interconnect connection is one or more physical circuits between your router and Google's edge in a colocation facility. Circuits come in 10, 100 and 400 Gbps, and a connection bundles up to eight of the same speed, so up to 80, 800 or 3,200 Gbps. Each connection is placed in a metro and in one of its edge availability domains, maintenance and failure boundaries inside the metro; a facility can host both domains. Google does not take both domains in a metro down for planned maintenance at the same time, which is why redundancy is expressed in domains, not just in second cables.
VLAN attachment. An attachment is a logical circuit, an 802.1Q VLAN on the connection, bound to one region, one VPC network and one Cloud Router. It has a capacity you choose and an MTU. Several attachments, even in different VPCs or projects, can share a connection. The attachment is where you pay for and limit bandwidth.
BGP session. Each attachment has a BGP session between your router and Cloud Router, over a pair of link-local addresses. Cloud Router advertises your VPC subnets (or custom ranges you specify) and learns your on-premises prefixes, which become dynamic routes in the VPC.
Dedicated, Partner and Cross-Cloud
Google offers several ways to get the physical layer, and the right one depends on where your equipment is and how much bandwidth you need.
| Flavour | Physical layer | Typical fit |
|---|---|---|
| Dedicated Interconnect | Your router in a supported colocation facility, cross-connected to Google | 10 Gbps and up, you already have presence in the facility |
| Partner Interconnect | A service provider carries traffic from your site to Google | Sub-10 Gbps needs, no colocation presence, faster setup |
| Cross-Cloud Interconnect | Google-provisioned circuits to another cloud provider | Private links between Google Cloud and another cloud |
Partner Interconnect attachments are sold in steps starting at 50 Mbps. Google's overview page gives 50 Gbps as the ceiling for a Partner attachment, while the quotas page lists higher figures for some attachment types, so check the quotas page for the current limit before you design around it. Dedicated attachments range from 50 Mbps up to the connection's capacity, as high as 400 Gbps for a single attachment.
With Partner Interconnect, you create the attachment first and receive a pairing key that you give the provider; the provider then provisions its side. Every Cloud Router used for Partner attachments must use ASN 16550. With Layer 3 partners the provider runs BGP with Cloud Router; with Layer 2 partners you run it yourself across the provider's VLAN.
Attachment limits that shape designs
Three attachment limits shape real designs.
- MTU. Attachments support 1,440, 1,460, 1,500 or 8,896 bytes. Match the VPC network's MTU and your on-premises path end to end. A mismatch shows up as connections that open but stall on large transfers, the classic path-MTU symptom.
- Per-flow limit. A single flow is limited to 10 Gbps, and an attachment to 1,000,000 packets per second. A 100 Gbps attachment does not make one TCP stream go at 100 Gbps; you need many flows, spread by equal-cost multipath hashing on the 5-tuple. Bulk copy tools that open parallel streams use the link well; a single large rsync does not.
- Capacity is per attachment. Traffic above the attachment's configured capacity is dropped. Two attachments in an active/active pair each need to carry the full load if you want to survive losing one.
Routing with Cloud Router and BFD
Cloud Router is a managed BGP speaker, not a box in the data path; packets go from the attachment straight into the VPC fabric. What Cloud Router controls is which prefixes each side learns.
Two settings cause most surprises. The VPC's dynamic routing mode decides how far learned routes travel: in regional mode, on-premises prefixes learned in us-east4 are usable only by resources in us-east4; in global mode they are usable from every region, with an inter-region cost added to the route priority. The second setting is path preference. When you have attachments in two regions, influence which one carries traffic with the base priority (MED) Cloud Router advertises on each session and with the AS path or local preference you set on your own routers. Without that, return traffic may take a different attachment from outbound traffic, which breaks stateful firewalls.
Failure detection is the other half of routing. BGP alone notices a dead session when its hold timer expires, about 60 seconds. Cloud Router supports Bidirectional Forwarding Detection on Interconnect attachments; with the defaults of a 1,000 ms interval and a multiplier of 5 it detects failure in about 5 seconds. Enable BFD on both sides for any attachment carrying production traffic, and keep the timers within the supported range rather than tuning them aggressively.
SLA topologies
Google's Interconnect SLAs are tied to topologies, and the topology is the whole design.
| Target | Connections | Placement | Attachments and routers |
|---|---|---|---|
| 99.9% | At least 2 | One metro, different edge availability domains | At least 2 attachments in one region, each on its own connection; one Cloud Router is enough |
| 99.99% (multi-region) | At least 4 | Two metros, two edge availability domains in each | At least 2 attachments in each of two regions, a Cloud Router in each region, global dynamic routing |
| 99.99% (single region) | At least 4 | One metro, distinct facility and domain pairs | At least 4 attachments in one region, at least one Cloud Router |
A single connection has no SLA, and neither does a pair that shares a domain. The SLA also covers only Google's side. If both of your routers sit in one rack on one power feed, the four-connection topology still fails as one. Mirror the redundancy on your side: separate routers, separate power, separate carrier paths into the facilities.
Encryption
Interconnect traffic is private but not encrypted by default. There are two options. MACsec encrypts at Layer 2 between your router and Google's edge routers, at line rate, and needs routers and optics that support it. HA VPN over Cloud Interconnect runs IPsec tunnels across the attachments, so traffic is encrypted end to end into the VPC; it is supported on Dedicated and Partner Interconnect, and each tunnel's throughput is much lower than an attachment's, so plan for many tunnels when bandwidth is large. Many teams also rely on application-level TLS and treat link encryption as defence in depth required by policy.
Worked example: staging training data
A research team keeps 4 PB of training data on premises and wants to stage a 200 TB slice per week into Cloud Storage for GPU training in us-central1, plus steady 5 Gbps of inference logs flowing back. They want to survive the loss of one connection without slowing the weekly copy past its 12-hour window. The script below checks a candidate design.
# interconnect_plan.py: does a design survive one failure and meet the copy window?
TB = 1e12 * 8 # bits per terabyte
design = { # attachment name -> Gbps capacity
"chi-zone1": 100, "chi-zone2": 100,
}
weekly_copy_tb, window_h = 200, 12
background_gbps = 5 # inference logs, always on
flow_cap_gbps = 10 # per-flow limit on an attachment
parallel_streams = 32 # transfer tool setting
efficiency = 0.8 # protocol and scheduling overhead
need_gbps = weekly_copy_tb * TB / (window_h * 3600) / 1e9 / efficiency
print(f"copy needs {need_gbps:.1f} Gbps for {window_h} h")
for failed in [None, *design]:
alive = {k: v for k, v in design.items() if k != failed}
cap = sum(alive.values()) - background_gbps
stream_cap = parallel_streams * flow_cap_gbps
usable = min(cap, stream_cap)
verdict = "OK" if usable >= need_gbps else "SHORT"
print(f"lost={failed or 'none':10} usable={usable:6.1f} Gbps -> {verdict}")The copy needs about 46 Gbps for 12 hours. Two 100 Gbps attachments on different edge availability domains in the Chicago metro leave 95 Gbps after losing either one, and 32 parallel streams stay under the 10 Gbps per-flow cap, so this 99.9% design meets the goal. The team adds BFD, sets the MTU to 8,896 on the attachments and the VPC because both ends support jumbo frames, and uses global dynamic routing so a later training region can reach the data path. If the training cluster later moves to a second region, they will add two connections in a second metro and move to the 99.99% topology.
Configuration as code
Keep attachments and routers in code. The Terraform below is a sketch of one side of the pair; resource and argument names follow the Google provider, but check them against the provider version you use.
resource "google_compute_router" "edge_usc1" {
name = "edge-usc1"
region = "us-central1"
network = google_compute_network.prod.id
bgp {
asn = 64514 # Partner Interconnect requires 16550 instead
}
}
resource "google_compute_interconnect_attachment" "chi_zone1" {
name = "chi-zone1"
region = "us-central1"
type = "DEDICATED"
interconnect = var.interconnect_zone1_self_link
router = google_compute_router.edge_usc1.id
bandwidth = "BPS_100G"
vlan_tag8021q = 1100
mtu = 8896
}Then add the router interface and BGP peer for the attachment, with BFD enabled, and the matching configuration on your router. Review route advertisements in the same change so nobody advertises a default route by accident.
Operating the link
Watch three groups of signals: link health (circuit operational status, light levels, BGP and BFD session state), traffic (attachment utilisation against capacity, drops, packets per second against the 1,000,000 limit) and routing (the count of learned prefixes per session and any change in the best path). Alert on a BGP session going down, on utilisation above 70% of a single attachment's capacity when you rely on N-1 redundancy, and on learned-prefix counts changing outside a change window. Google announces planned maintenance per edge availability domain; treat each notice as a free failover drill and confirm the traffic moved.
Failure modes
- Redundancy that is not. Two connections in the same edge availability domain, or two attachments on one connection, fail together.
- Regional routing surprise. In regional dynamic routing mode, workloads in other regions cannot reach on-premises prefixes. Choose the mode deliberately.
- Asymmetric paths. Outbound and return traffic take different attachments and stateful firewalls drop them. Set MED and local preference consistently.
- Slow failover. Without BFD, sessions take about a minute to fail.
- MTU mismatch. Small requests work and large transfers hang.
- Single-flow bottleneck. One stream tops out at 10 Gbps however large the attachment.
- Overlapping ranges. On-premises prefixes overlapping VPC subnets are not used for those destinations. Plan addressing with the VPC model and Shared VPC in mind.
Trade-offs
Dedicated Interconnect gives the most bandwidth and lowest cost per bit for steady heavy traffic, but needs colocation presence, cross-connects and weeks of lead time. Partner Interconnect trades some cost and control for reach and speed of setup. HA VPN over the internet is quicker and cheaper for small or bursty flows, with lower throughput per tunnel and less predictable latency. Hybrid name resolution is a separate piece of work; see Cloud DNS zone types and hybrid DNS.
What to do next
- Measure the bandwidth, flow counts and latency you actually need, including one-failure headroom.
- Pick Dedicated, Partner or Cross-Cloud from where your equipment is and how much bandwidth you need.
- Choose the SLA target and draw the full topology, including your own routers, power and carriers.
- Set MTU end to end, and enable BFD on every production session.
- Decide the dynamic routing mode and path preferences, and write them down.
- Choose MACsec, HA VPN over Interconnect or application TLS for encryption.
- Put attachments, routers and peers in code, add the alerts above, and confirm traffic moves during the next maintenance window.