Before looking at the types and settings, let us understand what problem this service solves.

The problem of connecting two worlds

Most companies do not move everything to the cloud overnight. They keep some systems in their own data centers and run others in Google Cloud. Those two worlds must exchange data constantly: databases synchronize, files are copied, applications call each other, and employees reach cloud tools. If that traffic travels over the public internet, it is affected by congestion, unpredictable delays and a larger exposure to attack.

The solution: a private, dedicated link

Cloud Interconnect provides a direct, private connection between your on-premises network and your Virtual Private Cloud (VPC) network in Google Cloud. Your traffic travels over a physical link that does not cross the public internet. Because the path is private and not shared with random internet traffic, you typically get higher bandwidth, more consistent latency and lower data transfer rates for large volumes than with an ordinary internet-based connection.

The three flavors in one glance

Interconnect is not always the right answer. Understanding the alternatives shows when it truly earns its cost.

Cloud VPN: encrypted but internet-dependent

Cloud VPN builds an encrypted tunnel across the public internet. It is quick to set up and inexpensive, and its high availability version offers a strong uptime commitment when properly configured. However, each tunnel has a bandwidth ceiling, and the performance depends on the internet path between your site and Google, which can vary from hour to hour.

Peering: for public services and special cases

Google also offers direct and carrier peering, which connect your network to Google’s edge so that you can reach Google’s public services, such as Workspace, over a better path. These are separate from Cloud Interconnect and do not give you private access to your VPC network using internal addresses, so they are used for different goals.

When Interconnect makes sense

A handful of terms appear in every Interconnect design. Learn them once and the documentation becomes much easier to read.

The two layers: physical and logical

It helps to keep two layers separate in your mind. The physical layer is the cables, ports and light signals, and it is what you buy or lease. The logical layer is the set of VLAN attachments, BGP sessions and routes that decide how traffic actually flows. One physical connection can carry several VLAN attachments, each leading to a different VPC network or region, which is why careful logical design matters as much as the hardware.

flowchart LR
  OP[On-Premises Network] --> R[Your Router in Colocation Facility]
  R -->|Physical Link| G[Google Edge]
  G --> VA[VLAN Attachment]
  VA --> CR[Cloud Router]
  CR --> V[VPC Network]
        

Dedicated Interconnect is the most direct option, giving you your own physical link to Google.

How it works

With Dedicated Interconnect, you place a router in a colocation facility that is also home to a Google Interconnect location. A cable inside the facility joins your router to Google’s equipment. This single act creates a private, high-capacity connection to Google’s network. You then add VLAN attachments on top of the connection to reach your VPC networks, and set up BGP with a Cloud Router so routes are exchanged.

Capacity

Dedicated connections are offered in standard circuit sizes of 10 gigabits per second and 100 gigabits per second. You can bundle several circuits together into one connection for more capacity, up to a published limit per connection, and you can run multiple connections. Capacity is bought in coarse steps, so Dedicated Interconnect suits organizations whose traffic is already substantial.

If you are not in a Google colocation facility, or you only need modest bandwidth, a service provider can bridge the gap.

How it works

With Partner Interconnect, a supported service provider already has a connection to Google. You connect your network to the provider using whatever method the provider offers, and the provider carries your traffic the rest of the way to Google. You order VLAN attachments in Google Cloud, share a pairing key with your provider, and the provider completes the link. You never have to be physically present in a Google facility.

Capacity and flexibility

Partner Interconnect offers VLAN attachments in a wide range of sizes, from small capacities such as tens of megabits per second up to tens of gigabits per second, depending on the provider and the options available. This lets you start small and grow, which is helpful for projects that do not yet need a full dedicated circuit.

Layer 2 and Layer 3 partners

Providers deliver the service in one of two styles. In a Layer 2 arrangement, the provider gives you a link that behaves like an Ethernet connection, and you set up BGP directly with the Cloud Router yourself. In a Layer 3 arrangement, the provider runs the routing for you, setting up BGP with Google on its side and exchanging routes with your network in whatever way it supports. Layer 2 gives you more control; Layer 3 gives you less work.

Many organizations use more than one cloud. Cross-Cloud Interconnect makes the link between clouds direct and private.

What it is

Cross-Cloud Interconnect gives you a private, high-bandwidth connection between Google Cloud and another supported cloud provider. Google arranges the physical connection between its network and the other provider’s network, so you do not have to place and manage equipment in a colocation facility. Standard capacities such as 10 and 100 gigabits per second are available, and several major cloud providers are supported. Check current documentation for the exact list.

flowchart LR
  A[Google Cloud VPC] |Cross-Cloud Interconnect| B[Other Cloud Provider Network]
  A --> C[Your Workloads in Google Cloud]
  B --> D[Your Workloads in the Other Cloud]
        

Why use it

With three options on the table, a clear comparison makes the choice much easier.

flowchart TD
  Q1{Connecting to another cloud provider?} -->|Yes| A1[Cross-Cloud Interconnect]
  Q1 -->|No| Q2{Present in a Google colocation facility or willing to be?}
  Q2 -->|Yes| Q3{Need high steady bandwidth?}
  Q3 -->|Yes| A2[Dedicated Interconnect]
  Q3 -->|No| A3[Partner Interconnect]
  Q2 -->|No| A3
        

The physical link is only half the story. The logical layer decides what traffic flows and where.

VLAN attachments

A VLAN attachment, sometimes called an interconnect attachment, is the logical connection between an Interconnect link and a VPC network. It is tied to a single Cloud Router and a single region. Each attachment has a capacity, uses a numbered virtual LAN tag on the physical link, and carries one BGP session. You usually create several attachments for redundancy, and you may create more for different VPC networks or regions.

Cloud Router and BGP

Cloud Router is a managed, distributed service. It uses BGP to learn the address ranges of your on-premises network and to advertise the subnets of your VPC network to your router. As networks change, the routes update automatically without manual editing. This dynamic behavior is a major benefit, because adding a subnet in the cloud or a new office on-premises does not require a ticket to change static routes.

sequenceDiagram
  participant OR as On-Premises Router
  participant CR as Cloud Router
  participant V as VPC Network
  OR->>CR: Advertise on-premises address ranges
  CR->>V: Install learned routes
  V->>CR: Provide subnet ranges
  CR->>OR: Advertise VPC subnet ranges
        

Key BGP concepts in plain words

Regional versus global dynamic routing

Each VPC network has a dynamic routing mode. In regional mode, routes learned by a Cloud Router are usable only by subnets in the same region as that router. In global mode, the learned routes are available to subnets in every region, and Google Cloud automatically adds a small cost penalty to routes used across regions so nearby paths are preferred. Global mode is often chosen when you want a single connection to serve the whole network, or for the highest availability designs.

A single link will fail someday, from a cut cable, a faulty device or planned maintenance. Interconnect is designed so you can build around this.

Why a single connection is not enough

A lone connection has a lone point of failure. Google’s Interconnect service level commitments apply only when you follow published redundancy patterns. In other words, uptime is a result of how you design the connections, not a property of one cable.

The two standard patterns

flowchart TD
  OP[On-Premises Network] --> M1A[Metro 1 - Domain A]
  OP --> M1B[Metro 1 - Domain B]
  OP --> M2A[Metro 2 - Domain A]
  OP --> M2B[Metro 2 - Domain B]
  M1A --> R1[Cloud Router Region 1]
  M1B --> R1
  M2A --> R2[Cloud Router Region 2]
  M2B --> R2
  R1 --> V[VPC Network with Global Routing]
  R2 --> V
        

Active-active or active-passive

Once you have several attachments, you decide how traffic uses them. In an active-active design, all attachments carry traffic at once, usually by giving them equal priority so that traffic is spread across them. This uses all the capacity you pay for but requires that every path can handle the full load if the others fail. In an active-passive design, one path is preferred and the others sit as standbys, which is simpler to reason about but leaves capacity idle.

A private path is not the same as an encrypted path. Understanding the difference helps you meet your security needs.

What is and is not protected by default

Traffic over Cloud Interconnect travels on a private connection and does not traverse the public internet, which already reduces exposure. However, the traffic is not encrypted by Interconnect itself. If your policies require encryption in transit, you need to add it yourself.

Options for adding encryption

Other protections

Let us follow a request from an on-premises server to a virtual machine in Google Cloud.

sequenceDiagram
  participant S as On-Prem Server
  participant R as On-Prem Router
  participant E as Google Edge
  participant V as VPC Network
  participant M as Cloud VM
  S->>R: Packet to cloud address
  R->>E: Forward over Interconnect with VLAN tag
  E->>V: Deliver via VLAN attachment
  V->>M: Route and apply firewall rules
  M-->>S: Reply returns on the learned path
        

Packet size and MTU

The maximum transmission unit is the largest packet that can travel in one piece. Interconnect attachments support specific sizes, and VPC networks have their own setting. If the two ends disagree, large packets may be dropped or split, causing slow transfers or hanging connections even though small requests work. Check that your on-premises equipment, the attachment and the VPC network agree on a compatible size.

Large organizations rarely have one project. Interconnect fits into multi-project designs in a few common ways.

Sharing one connection across projects

Interconnect connections can be created in a central project and used by VLAN attachments that belong to other projects, depending on how you set up the arrangement. A very common design places the VLAN attachments, Cloud Routers and the VPC network in a Shared VPC host project. Service projects then place their virtual machines in the shared subnets and automatically gain access to on-premises through the single set of connections managed by the central network team.

flowchart TD
  OP[On-Premises Network] --> IC[Interconnect Connections]
  IC --> HP[Host Project: VLAN Attachments, Cloud Routers, Shared VPC]
  HP --> SP1[Service Project A]
  HP --> SP2[Service Project B]
  HP --> SP3[Service Project C]
        

Connecting several VPC networks

If you have several separate VPC networks that all need to reach on-premises, you can create attachments for each, or use a hub approach. Network Connectivity Center lets you treat your Interconnect attachments and other connections as spokes attached to a central hub, so on-premises sites and VPC networks can exchange routes in a more organized way. It can also help sites that are each connected to Google reach one another across Google’s backbone, though you should confirm current feature support and costs before relying on this.

Interconnect is not only for reaching your own virtual machines. It can also carry on-premises traffic to Google APIs.

Private Google Access for on-premises hosts

Systems in your data center can use Google services such as Cloud Storage or BigQuery over the private Interconnect path instead of the public internet. This is done with Private Google Access for on-premises hosts, using special address ranges that Google publishes for this purpose. Your DNS must send requests for Google API names to those ranges, and Cloud Router must advertise the ranges so your network knows to send that traffic through Interconnect.

Private Service Connect for Google APIs

Private Service Connect offers another way. You create an internal endpoint with an address in your own VPC range that represents Google APIs, then reach it from on-premises through the connection. Because the address belongs to your address plan, it can be easier to control and to allow in firewalls.

Good planning prevents most Interconnect delays and surprises.

Step one: understand your traffic

Measure what you actually move today and what you expect in the next few years: peak bandwidth, daily volume, latency sensitivity and which systems need to talk. This guides both the type you choose and the capacity you buy, and helps avoid paying for far more than you will use.

Step two: plan addresses and routing

Choose non-overlapping address ranges between on-premises and every VPC network that will connect. Decide which ranges each side should advertise, which routing mode to use, and how you will prefer one path over another. These decisions are painful to change after systems depend on them.

Step three: pick locations and design redundancy

Select metropolitan areas close to both your data center and your main Google Cloud regions, and plan redundancy to match your availability goals. Decide early whether you need the 99.9 or 99.99 percent topology, because it affects the number of connections, locations and routers.

Step four: plan lead times and people

Dedicated connections involve ordering, cross-connects at the facility and testing, which can take weeks. Partner connections can be faster but still depend on the provider. Involve network engineers, security teams, the colocation facility and the provider early, and agree on who does what.

A connection that nobody watches is a risk. Google Cloud provides several tools to see the health of your Interconnect.

What to alert on

A simple troubleshooting routine

Interconnect has fixed and variable costs. Knowing both lets you judge whether it saves or costs you money.

Finding the break-even point

Because fixed costs are higher but per-gigabyte costs are lower, Interconnect usually becomes cheaper than internet-based options once traffic is large and steady. For small or spiky traffic, a VPN or ordinary internet transfer can be more economical. Compare total monthly cost at your expected volume, including the redundancy you need, not just the price of a single connection.

Patterns capture what experienced teams repeatedly find works; anti-patterns capture what repeatedly goes wrong.

Helpful patterns

Anti-patterns to avoid

An honest summary of what Cloud Interconnect gives you and what it asks from you in return.

When to choose it

Choose Cloud Interconnect when you have large, steady or latency-sensitive traffic between sites and Google Cloud, when private addressing and predictable performance matter, or when you are building a long-term hybrid or multicloud architecture.

When not to choose it

Avoid it when traffic is small or occasional, when you need a quick solution within hours, or when budget and skills do not allow proper redundancy. In those cases, Cloud VPN is often the better fit, and you can move to Interconnect later when needs grow.

Seeing how organizations use Interconnect makes the concepts easier to remember.

A short checklist to carry into every Interconnect project.

No. Cloud VPN creates encrypted tunnels over the public internet. Cloud Interconnect provides a private physical connection that does not use the public internet, with higher bandwidth and steadier performance, but it is not encrypted by default.

Not by default. You can add encryption using MACsec on supported connections, HA VPN over Interconnect, or application-level encryption.

For Dedicated Interconnect, yes, you need equipment in a facility where Google has an Interconnect location. For Partner Interconnect, you connect through a service provider and do not need to be in a Google facility.

It is the logical connection between an Interconnect link and a VPC network, associated with a Cloud Router and a region. It carries a BGP session and has a set capacity.

Cloud Router uses BGP to exchange routes between your VPC and your network dynamically, so new subnets and sites are learned automatically without manual route changes.

Follow Google’s published topology for that level: four connections across two metropolitan areas, in different edge availability domains, with Cloud Routers in two regions and global dynamic routing. Check current documentation for exact requirements.

Dedicated Interconnect usually takes weeks because of ordering, cross-connects and testing. Partner Interconnect can be faster, depending on the provider. Cloud VPN can be ready within hours and is often used as a stopgap.

Yes. A single physical connection can carry several VLAN attachments, each linked to a Cloud Router for a VPC network, so you can serve multiple networks or regions on one link.

Yes, using Private Google Access for on-premises hosts or Private Service Connect endpoints, along with the right route advertisements and DNS settings.

It has higher fixed costs but lower per-gigabyte transfer rates, so it tends to be cheaper for large, steady volumes and less economical for small or occasional traffic.

Google sends advance notifications. With redundant connections in different edge availability domains, traffic shifts to the unaffected paths while one domain is maintained.

Yes. Cross-Cloud Interconnect provides a direct, private link between Google Cloud and supported other cloud providers, so you do not need to route traffic through your own data center.

Cloud Interconnect gives you a private, high-bandwidth, predictable path between your own network, or another cloud, and Google Cloud. Dedicated Interconnect offers the most direct control, Partner Interconnect offers flexibility and ease when you cannot reach Google directly, and Cross-Cloud Interconnect links clouds together. On top of the physical layer, VLAN attachments, Cloud Router and BGP decide how traffic flows, while redundant topologies in separate failure domains deliver the availability your business needs. Interconnect is private but not encrypted by default, and it has real fixed costs and lead times, so planning, address design, security decisions and monitoring matter just as much as the connection itself.