Key terms

This page provides important terms that apply to Cloud Interconnect. Review these terms to better understand how Cloud Interconnect works.

For more information, see the Cloud Interconnect overview.

Cloud Interconnect terms

The following key terminology describes the concepts on which Cloud Interconnect is built. These terms might apply to Dedicated Interconnect, Partner Interconnect, or both.

Colocation facility (also known as an Interconnect location)

For Dedicated Interconnect, a colocation facility is where Google has a point of presence, allowing you to connect your on-premises network with Google's network. In the colocation facility, work with the facility provider to provision your routing equipment before using Dedicated Interconnect. For a list of facilities and their supported regions, see Choosing colocation facility locations.

For Partner Interconnect, supported service providers are connected to Google in at least one of these facilities.

edge availability domain

Each metropolitan area has at least two zones called edge availability domains. These domains provide isolation during scheduled maintenance, meaning that two domains in the same metro won't be down for maintenance at the same time. This isolation is important when you're building for redundancy.

Edge availability domains span a single metro, not across metros. To maintain availability and an SLA, you must build duplicate Interconnect connections in different domains in the same metro. For example, building connections in dfw-zone1-4 and dfw-zone2-4 provides redundancy across different edge availability domains, whereas dfw-zone1-4 and dfw-zone1-505 do not because they are in the same edge availability domain.

Maintenance windows are not coordinated across metros. For example, the edge availability domains dfw-zone1-4 and ord-zone1-7 could experience overlapping maintenance events. When connecting to multiple metros for redundancy, it is important to connect to different edge availability domains in each of those metros, as described in the production topology.


A Letter of Authorization and Connecting Facility Assignment (LOA-CFA) identifies the connection ports that Google has assigned for your connection, and grants permission for a vendor in a colocation facility to connect to them. LOA-CFA documents are required when you order Dedicated Interconnect connections in a colocation facility.

When you order Dedicated Interconnect connections, Google allocates resources for your connections and then generates an LOA-CFA document for each one. The LOA-CFA lists the demarcation points that Google allocated for your connections. Submit this form to the facility vendor to provision cross-connects between Google's equipment and your own. After the status of a connection changes to PROVISIONED, the LOA-CFA is no longer valid, necessary, or available in the Google Cloud Console.

For more information about the provisioning flow, see the Dedicated Interconnect Provisioning overview.

metropolitan area (metro)

A metropolitan area (metro) is the city where a colocation facility is located. When you create an Interconnect connection, you select the colocation facility and metro where the connection lives.

The metro that you choose depends on the location of your on-premises network and the location of your Compute Engine VM instances (their Google Cloud region). Typically, you might want to pick a metro that's geographically close to your on-premises network to reduce latency. For redundancy, you might choose a metro that is further away.

In regards to the Google Cloud region, each metro supports a subset of regions. You can create interconnect attachments (VLANs) in these supported regions only. For example, if you pick a facility in Ashburn, you can only create interconnect attachments in the North American regions. Assuming that your VM instances are also in these regions, you can create interconnect attachments in the same regions to reduce latency and egress costs. Otherwise, traffic would have to travel between regions to reach your VM instances or on-premises network.

For more information, see Choosing colocation facility locations.

metropolitan availability zone
See edge availability domain.
pairing key

Pairing keys are used only for Partner Interconnect. It's a unique identifier that allows service providers to identify particular interconnect attachments without anyone sharing potentially sensitive information about their VPC network or Google Cloud project. Treat the pairing key as sensitive information until your interconnect attachment is configured. If it's discovered, it's possible for other parties to use it to connect to your network. The key is for one-time use and can't be modified. If you need a new pairing key, delete your interconnect attachment and then create a new one.

Pairing keys use the following format:
<random>/<vlan-attachment-region>/<edge-availability-domain>. For example, 7e51371e-72a3-40b5-b844-2e3efefaee59/us-central1/2 is a pairing key for an interconnect attachment (VLAN) in the us-central1 region and edge availability domain 2.

service provider
A network service provider. To use Partner Interconnect, you must connect to a supported service provider. The service provider provides connectivity between your on-premises network and your VPC network.

Border Gateway Protocol (BGP) terms

The following terminology applies to the Border Gateway Protocol (BGP), which Cloud VPN and Cloud Interconnect use for dynamic routing.

Border Gateway Protocol (BGP)
An exterior gateway routing protocol standardized by the Internet Engineering Task Force (IETF) in RFC 1722. BGP automatically exchanges routing and reachability information among autonomous systems on the internet. Your device is BGP-capable if it can perform BGP routing. This means that you can enable the BGP protocol on it and assign it a BGP IP address and an autonomous system number. To determine if your device supports BGP, see the vendor information for your device or contact your device's vendor.
autonomous system (AS)
A collection of connected IP routing prefixes under the control of a single administrative entity or domain that presents a common routing policy to the internet (such as an internet service provider (ISP), a large company, or a university).
autonomous system number (ASN)
A unique identifier allocated to each autonomous system that uses BGP routing. For more information, see RFC 1930.

Google Cloud terms

The following terminology applies to Google Cloud and its features.

Google Cloud
Google Cloud is a suite of public cloud computing services offered by Google. For more information, see Google Cloud products.
project ID
The ID of your Google Cloud project. A project contains networking resources such as networks, subnets, and Cloud VPN gateways as described in the VPC network overview. For a description of the difference between project name, project ID, and project number, see Identifying projects. You can view the project ID in the Google Cloud Console.