Cloud Interconnect gives you private, high capacity connectivity between your own network and Google Cloud.

The problem with the public internet

Most companies start their cloud journey by reaching the cloud over the public internet, often protected by an encrypted tunnel called a VPN. This works well for small needs. But as the amount of data grows, the internet shows its weaknesses. Speed can change from hour to hour because you share the road with everyone else. Delay, called latency, can jump around. A busy period elsewhere in the world can slow your traffic. And moving very large amounts of data, such as databases, backups or video archives, becomes slow and unpredictable.

What the service does about it

Cloud Interconnect extends your on-premises network into Google Cloud through a physical or provider-managed link that does not pass through the public internet. Traffic travels between your routers and Google’s network edge over a dedicated path. The result is higher bandwidth, more stable latency and a smoother experience for hybrid applications, where some parts run in your data center and some in the cloud.

Ten words that appear in nearly every Interconnect conversation.

You do not need to memorize these. The following chapters show how they fit together, like pieces of one puzzle.

Follow the path from your router to a virtual machine in Google Cloud.

A working Cloud Interconnect setup has a few layers. At the bottom is the physical or provider connection that reaches Google’s edge. On top of it you create one or more VLAN attachments. Each attachment is linked to a Cloud Router in a chosen region and a VPC network. The Cloud Router and your on-premises router open a BGP session and swap routes. Once routes are exchanged, your virtual machines can reach on-premises addresses and your on-premises systems can reach Google Cloud addresses using private IP addresses.

flowchart LR
ONP["On-premises Network and Router"] --> LINK["Interconnect Connection"]
LINK --> EDGE["Google Edge in a Metro"]
EDGE --> VA["VLAN Attachment"]
VA --> CR["Cloud Router (BGP)"]
CR --> VPC["VPC Network"]
VPC --> VM["Virtual Machines and Services"]
ONP |"BGP session"| CR
        

Two halves, two owners

The physical side, meaning the circuits and ports, belongs to the connection. The logical side, meaning the attachments, routers and routes, belongs to your Google Cloud project. Splitting the pipe into attachments lets one physical connection serve several VPC networks, several regions or several teams, each with its own capacity setting.

Different ways to reach the same private highway, depending on where you are and what you need.

flowchart TD
Q1{"Where is the other end?"} -->|"Another cloud"| CC["Cross-Cloud Interconnect"]
Q1 -->|"Your own sites to each other"| CS["Cross-Site Interconnect"]
Q1 -->|"Your data center"| Q2{"Can you reach a Google colocation facility?"}
Q2 -->|"Yes, and need 10 Gbps or more"| DI["Dedicated Interconnect"]
Q2 -->|"No, or need smaller capacity"| PI["Partner Interconnect"]
        

A direct cable between your equipment and Google’s, inside a shared colocation building.

With Dedicated Interconnect you place your own router in a colocation facility that Google also uses. A physical cable, called a cross-connect, links your router to Google’s equipment in the same building. Because you own the equipment and the connection ends there, you also need a way to carry traffic from the colocation facility back to your office or data center, either by having your data center in that building or by buying a network circuit to it.

Circuits and capacity

A connection is made of one or more circuits grouped together as a bundle. Circuits in one connection must all have the same speed, commonly 10 Gbps or 100 Gbps, and a connection can contain up to eight circuits. You can add circuits to grow capacity. On top of that connection you create VLAN attachments, each with its own capacity setting that can range from a small slice up to very large sizes.

What you need

Borrowing a service provider’s existing connection to Google.

Many companies cannot place equipment in a Google colocation facility, or they need less than a full dedicated port. Partner Interconnect solves this. A supported service provider already has connections into Google. You buy connectivity from that provider, and the provider links your network to Google. You still create VLAN attachments in Google Cloud, but they are paired with the provider.

The pairing key

When you create a partner VLAN attachment, Google gives you a pairing key, a long code that identifies the attachment. You hand the pairing key to your provider, who uses it to connect the right circuit to the right attachment. After the provider has configured it, you activate the attachment in Google Cloud. This exchange of a key is how two companies safely agree they mean the same connection.

Layer 2 and Layer 3 providers

Providers offer two styles. In a Layer 2 connection, the provider only carries the traffic, and you configure BGP between your router and Google’s Cloud Router yourself. In a Layer 3 connection, the provider handles the routing for you and exchanges routes with Google on your behalf, so you do less configuration. Layer 3 is simpler, Layer 2 gives you more control.

When your applications live in more than one cloud, they still need a good road between them.

Many organizations use several cloud providers. A database may be in one cloud and an analytics platform in another. Sending that traffic across the public internet is slow and unpredictable. Cross-Cloud Interconnect provides a private, high capacity connection between Google Cloud and supported other cloud providers, so workloads in different clouds can talk as if they were on one network.

flowchart LR
GC["Google Cloud VPC"] |"Private link"| OC["Other Cloud Network"]
GC --> ON["Your On-premises Network"]
OC --> ON
        

Different ownership models

In one model, Google orders and manages the physical connection to the other provider, and you receive the service as part of your Google Cloud setup. In a partner model, a provider and the other cloud cooperate to offer connections that are already built, so you can start in minutes by creating attachments and requesting matching circuits on the other side. Details such as supported clouds, locations and charges differ, so check the current documentation.

The logical layer where private traffic actually gets its addresses and its routes.

VLAN attachment

A VLAN attachment connects an Interconnect connection to a VPC network through a Cloud Router in a particular region. It has a capacity setting, which limits the traffic it can carry, and it has a pair of private addresses used for the BGP session between the two routers. You can let Google choose these addresses, or provide your own ranges. Attachments can also use different packet size settings, with larger packets helping some bulk transfers, as long as both ends agree.

Cloud Router and BGP

The Cloud Router is a managed service, not a physical box. It opens a BGP session with your on-premises router for each attachment. Over that session your router tells Google which on-premises address ranges exist, and the Cloud Router tells your router which VPC address ranges exist. Learned routes are added to your VPC network automatically, so there is no need to write routes by hand, and when a link fails, the routes adjust on their own.

sequenceDiagram
participant R as On-premises Router
participant C as Cloud Router
participant V as VPC Network
R->>C: Open BGP session over the attachment
C->>R: Advertise VPC address ranges
R->>C: Advertise on-premises address ranges
C->>V: Install learned routes
V-->>R: Traffic can now flow both ways
        

Regional or global routing

By default a Cloud Router shares routes only for the VPC subnets in its own region. With global dynamic routing enabled on the VPC network, it can share routes for all regions, so on-premises systems can reach resources in every region through one attachment. This is convenient, but it also makes failures and cost behavior more complex, so choose it deliberately.

The life of one packet, from your office to a Google Cloud virtual machine.

Local and remote connections

If the Interconnect location is in the same metro as the Google Cloud region where your workloads run, the connection is local, and traffic takes a short path. If the location is in a different metro, the connection is remote, and traffic must travel further across Google’s backbone, which adds delay. Choose locations near your target regions when delay matters.

Traffic balancing

When you have several attachments, Google Cloud balances traffic between them according to their configured capacity and the routes advertised. Route priorities decide which links are preferred and which are used only as backups. Good design sets these priorities on purpose so that failures behave as planned.

A single cable can break, so reliable designs always have a second path.

Every physical thing can fail: a cable can be cut, a port can die, a building can lose power, or a provider can have an outage. The answer is redundancy, meaning more than one independent path. Google defines prescriptive designs, and the availability promise applies only if you follow them. A single connection or a single attachment, on its own, has no uptime promise.

flowchart LR
subgraph M1["Metro 1"]
A1["Connection A in domain 1"]
A2["Connection B in domain 2"]
end
subgraph M2["Metro 2"]
B1["Connection C in domain 1"]
B2["Connection D in domain 2"]
end
ON["On-premises Network"] --> A1
ON --> A2
ON --> B1
ON --> B2
A1 --> GC["Google Cloud VPC"]
A2 --> GC
B1 --> GC
B2 --> GC
        

Rules of a good redundant design

Place redundant links in different edge availability domains so that maintenance or failure in one does not touch the other. Use at least two Cloud Router tasks, which Google Cloud assigns automatically across domains. Give each attachment a unique underlying connection. Where possible use separate physical routers on your side, and different physical paths to the building, so that one backhoe cannot cut both cables.

Enough capacity for failure

Redundancy that cannot carry the load is a trap. If two links share traffic equally and one fails, the other must carry everything. Size each path so that the surviving links can handle the full traffic, or accept slower performance during a failure, but make that a decision rather than a surprise.

How fast the highway is, and where the speed limits hide.

Bandwidth and latency

Bandwidth is how much data can move per second, like the width of a pipe. Latency is how long one piece of data takes to arrive, like the length of the pipe. Interconnect raises bandwidth and stabilizes latency, but it cannot beat the speed of light, so physical distance still matters.

Attachment capacity

Each attachment has a capacity setting. Dedicated Interconnect attachments can be set from small values up to very large sizes, while Partner Interconnect sizes depend on what your provider offers at your location. Capacity can be raised later when needs grow, so start with what you need now.

The single flow limit

An important detail is that one individual traffic flow, meaning one stream of data between two endpoints, is limited to a maximum speed that is lower than a very large attachment. A very large attachment helps many flows at once, but a single huge file transfer that uses just one connection may not use all the capacity. To fill a fat pipe, use tools that open several parallel streams.

Private is not the same as encrypted, so decide how much protection you need.

What private really means

Traffic over Cloud Interconnect does not cross the public internet, which removes many exposures. But it still crosses network equipment owned by Google, by providers and by facilities. By default it is not encrypted. For many organizations the private path is enough. For others, rules about sensitive data, such as financial or health records, require encryption in transit.

Other protections

Use VPC firewall rules and on-premises firewalls to limit which systems can talk across the link. Use identity and access management to control who can create, change or delete connections and attachments. Turn on audit logging so you can see who changed what. Keep BGP secure by filtering which routes you accept and advertise, so a mistake on one side cannot flood the other with wrong routes.

What organizations actually build on top of Cloud Interconnect.

flowchart TD
DC["Company Data Center"] --> IC["Cloud Interconnect"]
IC --> HUB["Hub VPC Network"]
HUB --> S1["Spoke VPC: Production"]
HUB --> S2["Spoke VPC: Analytics"]
HUB --> S3["Spoke VPC: Shared Services"]
        

Private access for on-premises hosts

On-premises systems can use private addresses to reach Google APIs and services through the Interconnect, rather than using public addresses. This keeps traffic on the private path and simplifies security rules, provided DNS and routing are set up for it.

A network link you cannot see is a link you cannot trust.

Cloud Interconnect reports its health and traffic through Google Cloud’s monitoring tools. Important signals include whether each connection and attachment is up, the state of each BGP session, the amount of traffic flowing in each direction compared with the capacity ordered, packet errors and drops, and optical light levels on physical circuits, which warn about failing optics before a link goes down.

A simple troubleshooting path

Interconnect projects are slower than cloud projects because cables are involved, so plan ahead.

You pay for the road, and a smaller toll for the cargo.

Cloud Interconnect pricing has several parts. You pay for the connection or the attachment capacity, usually by the hour, depending on the flavor and size. You pay for data that leaves Google Cloud toward your network, at rates that are generally lower than standard internet egress, which is one reason heavy data users choose Interconnect. Data coming into Google Cloud is typically not charged. Beyond Google’s charges you pay for colocation space, cross-connects, your own routers, last mile circuits and any partner fees. Rates change by region and over time, so always use the official pricing pages and calculator.

When it pays off

Interconnect tends to be cost effective when you move large and steady volumes of data, when you need consistent performance, or when internet egress charges would be high. For small, occasional traffic a VPN is usually cheaper and simpler.

Where private cloud connectivity pays for itself.

The following are common patterns rather than named customer stories, because specific designs and contracts change over time.

You gain stability and speed, and you take on cost, lead time and responsibility.

Habits that keep hybrid networks calm, and habits that wake people at night.

Patterns that work

Strong designs use the prescriptive redundant topologies from the start. They plan address space for all environments in one place. They use route priorities on purpose, so primary and backup paths are clear. They keep a VPN as a last resort backup path. They automate their network configuration with code, so it is repeatable and reviewed. They test failover regularly instead of trusting that it will work.

A checklist to keep your private highway fast, safe and affordable.

Mistakes beginners make most often

The first is underestimating lead time and starting too late. The second is assuming redundancy without checking physical diversity. The third is forgetting firewall rules and DNS. The fourth is overlooking the single flow limit during bulk transfers. The fifth is treating private as encrypted. The sixth is ignoring cost of egress and idle capacity until the first bill arrives.

Google offers several ways to connect, and each fits a different need.

flowchart TD
Q1{"Is the traffic large, steady or sensitive to delay?"} -->|No| VPN["Cloud VPN"]
Q1 -->|Yes| Q2{"Another cloud on the other end?"}
Q2 -->|Yes| CCI["Cross-Cloud Interconnect"]
Q2 -->|No| Q3{"Can you reach a Google colocation facility?"}
Q3 -->|Yes| DED["Dedicated Interconnect"]
Q3 -->|No| PAR["Partner Interconnect"]
        

VPN and Interconnect together

These are not rivals. Many organizations start with a VPN while waiting for the Interconnect, then keep the VPN as a backup path. HA VPN can also run inside Cloud Interconnect to add encryption. The best hybrid designs use each for what it does best.

It is a family of Google Cloud services that connects your on-premises network, a service provider or another cloud to Google Cloud over private, high capacity links that avoid the public internet.

Dedicated Interconnect is a direct physical connection that you build to Google at a colocation facility. Partner Interconnect uses a service provider’s existing connection to Google, which suits you when you cannot reach a Google facility or need smaller capacity.

Not by default. It is private, but encryption is an extra step. You can use MACsec on supported circuits, HA VPN over Cloud Interconnect, or encryption in your applications.

No. Uptime promises apply only to the recommended redundant topologies, such as two connections in one metro for 99.9 percent or four connections across two metros for 99.99 percent. Check the current service level terms for the exact conditions.

It is the logical channel that links an Interconnect connection to a VPC network through a Cloud Router. It has its own capacity setting and carries the BGP session for exchanging routes.

BGP lets your router and the Cloud Router automatically tell each other which address ranges they can reach, and adapt when a path fails. Without it you would manage routes by hand.

Partner connections can be quicker, and Dedicated connections usually take longer because physical cabling at a colocation facility is involved. Plan for weeks rather than minutes, and use a temporary VPN in the meantime.

Yes. You create separate VLAN attachments on the same connection, each linked to a different VPC network or region, and each with its own capacity setting.

Individual traffic flows have their own maximum speed. Use tools that transfer with several parallel streams to take advantage of the full capacity.

Often it is useful as a backup path, and you may run HA VPN over Interconnect for encryption. A VPN over the internet is also a sensible bridge while the Interconnect is being built.

Not for small traffic, since it has fixed costs for capacity and often extra costs for facilities and providers. It can be more cost effective for large, steady data volumes because egress rates are lower than standard internet egress.

Yes, with Cross-Cloud Interconnect or partner based multicloud options, depending on the cloud provider and location. Check the supported providers and regions in the current documentation.

Cloud Interconnect gives you private, high capacity and more predictable connectivity between your networks and Google Cloud, through Dedicated, Partner, Cross-Cloud and related options. Physical or provider links carry traffic to Google’s edge, VLAN attachments and Cloud Routers connect them to your VPC networks, and BGP keeps the routes current. Reliability comes from redundant designs in separate failure domains, security from encryption choices and strict filtering, and good economics from matching capacity to real needs. Plan early, build redundantly, test failure, monitor closely and keep a backup path ready.