Choosing a Network Connectivity product

Google's external connectivity solutions enable you to connect your non-Google Cloud networks to Google in the following ways:

• To Google Cloud, which lets you access your Virtual Private Cloud (VPC) networks and Compute Engine virtual machine (VM) instances from your on-premises networks or from another cloud provider.

• To connect your sites together through a Network Connectivity Center hub located in Google Cloud.

• To Google Workspace and supported Google APIs, which lets you access only these products and services.

• To CDN providers, which lets you choose supported content delivery providers that establish Direct Peering links with Google's edge network. Choosing a provider lets you send traffic from your VPC networks to that provider.

Connecting to Google Cloud

When connecting to Google Cloud, you can choose among the following Google Cloud networking products.

If you need to access only Google Workspace or supported Google APIs, see Connecting to Google Workspace and Google APIs.

For pricing, quotas, service level agreement (SLA), and release note information for all Network Connectivity products, see the Network Connectivity resources page.

For high-level architectural guides and tutorials that describe networking scenarios for Google Cloud, see the Technical guides for networking.

Cloud VPN

Google Cloud offers two types of Cloud VPN gateways: HA VPN and Classic VPN.

For information about moving to HA VPN, see Moving to HA VPN from Classic VPN.

HA VPN

HA VPN is a high-availability (HA) Cloud VPN solution that lets you securely connect your on-premises network to your VPC network through an IPsec VPN connection. Based on the topology and configuration, HA VPN can provide an SLA of 99.99% or 99.9% service availability.

When you create an HA VPN gateway, Google Cloud automatically chooses two external IP addresses, one for each of its interfaces. Each IP address is automatically chosen from a unique address pool to support high availability. Each of the HA VPN gateway interfaces supports multiple tunnels. You can also create multiple HA VPN gateways. When you delete the HA VPN gateway, Google Cloud releases the IP addresses for reuse. You can configure an HA VPN gateway with only one active interface and one external IP address; however, this configuration does not provide an availability SLA.

One option for using HA VPN is to use HA VPN over Cloud Interconnect. With HA VPN over Cloud Interconnect, you get the security of IPsec encryption from Cloud VPN alongside the increased capacity of Cloud Interconnect. In addition, because you are using Cloud Interconnect, your network traffic never traverses the public internet. If you use Partner Interconnect, you must add IPsec encryption to your Cloud Interconnect traffic to meet data security and compliance requirements when connecting to third-party providers. HA VPN uses an external VPN gateway resource in Google Cloud to provide information to Google Cloud about your peer VPN gateway or gateways.

In the API documentation and in gcloud commands, HA VPN gateways are referred to as VPN gateways rather than target VPN gateways. You don't need to create any forwarding rules for HA VPN gateways.

For more information, see the following resources:

• For requirements, see HA VPN requirements.

• For Cloud VPN specifications, see Specifications.

• For sample topologies, see Cloud VPN topologies.

• For information about high-availability, high-throughput scenarios, or multiple subnet scenarios, see Advanced configurations.

• For routing scenarios, see Active/active and active/passive routing options for HA VPN.

• For more information about Classic VPN and HA VPN, see the Cloud VPN overview.

Cloud Interconnect

Cloud Interconnect offers three options for connecting to Google Cloud: Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect.

Dedicated Interconnect and Partner Interconnect

Network Connectivity provides two options for extending your on-premises network to your VPC networks in Google Cloud. You can create a dedicated connection (Dedicated Interconnect) or use a service provider (Partner Interconnect) to connect to VPC networks.

When choosing between Dedicated Interconnect and Partner Interconnect, consider your connection requirements, such as the connection location and capacity.

• If you have high bandwidth needs, Dedicated Interconnect can be a cost-effective solution.
• If you require a lower bandwidth solution, Dedicated Interconnect and Partner Interconnect provide capacity options starting at 50 Mbps.
• Cloud Interconnect provides access to all Google Cloud products and services from your on-premises network except Google Workspace.
• Cloud Interconnect also allows access to supported APIs and services by using Private Google Access from on-premises hosts.

Compare Dedicated Interconnect and Partner Interconnect

The following table highlights the key differences between Dedicated Interconnect and Partner Interconnect.

For more information, see the following resources:

• Cloud Interconnect overview
• Dedicated Interconnect overview
• Partner Interconnect overview
• Topology for production-level applications overview
• Topology for non-critical applications overview

Cross-Cloud Interconnect

If you need to connect your Google Cloud VPC network to your network that's hosted by another cloud service provider, use Cross-Cloud Interconnect. When you buy Cross-Cloud Interconnect, Google provisions a dedicated physical connection between Google Cloud and your other cloud service provider. To satisfy the Cloud Interconnect SLA, you purchase two connections—a primary connection and a redundant connection—to reach another cloud.

For example, you can use a pair of Cross-Cloud Interconnect connections to reach any of the following providers:

• Amazon Web Services
• Microsoft Azure
• Oracle Cloud Infrastructure
• Alibaba Cloud

If you want to connect to more than one cloud provider, use a different pair of Cross-Cloud Interconnect connections for each provider.

For more information, see the Cross-Cloud Interconnect overview.

Cloud Router

Cloud Router is a distributed and fully managed offering that provides Border Gateway Protocol (BGP) speaker and responder functionality and management of Cloud NAT gateways. Cloud Router works with Cloud Interconnect, Cloud VPN, and Router appliances to create dynamic routes in VPC networks based on BGP-received and custom-learned routes.

For more information, see the Cloud Router overview.

Connecting your sites by using Google Cloud

Use Google Cloud to connect your sites to each other through a Network Connectivity Center hub.

Network Connectivity Center

Network Connectivity Center supports connecting different enterprise sites outside of Google Cloud by using Google's network as a wide area network (WAN). On-premises networks can consist of on-premises data centers and branch or remote offices.

Network Connectivity Center is a hub-and-spoke model for network connectivity management in Google Cloud. The hub resource reduces operational complexity through a simple, centralized connectivity management model. The hub is paired with Google's network to deliver reliable connectivity on demand.

For definitions of hub and spoke, see Hubs and spokes.

On-premises networks connect to a Network Connectivity Center hub by using spokes that have supported Google Cloud resources attached to them.

The following diagram shows a Network Connectivity Center hub and its spokes. For example, a spoke can contain a VLAN attachment to an on-premises branch office in region us-east1. Another spoke can contain an attachment that connects to a Google Cloud region near another branch office in Europe. After the two branch offices are configured, they can send traffic over the hub to each other. Traffic between the offices enters and exits Google's network close to each office. This traffic uses a private connection through Cloud VPN or Cloud Interconnect.

• For a list of supported Google Cloud resources that you can attach to spokes, see Spoke resource types.
• For general information about Network Connectivity Center, see the Network Connectivity Center overview.

Router appliance

Router appliance is an alternative way of enabling connectivity between sites outside of Google Cloud through a Network Connectivity Center hub. You peer your Router appliance with Cloud Router to provide this connectivity.

You can install an image from your vendor of choice onto one or more VMs that act as Router appliance instances, or you can choose a supported vendor from Google Cloud Marketplace.

You associate your Router appliance instance with a Network Connectivity Center Router appliance spoke, which you attach to a Network Connectivity Center hub.

Cloud Router uses interfaces configured with private IP addresses to establish BGP peering with Router appliance instances. In that way, you establish routes among all locations.

For more information, see the Router appliance overview.

Connecting to Google Workspace and Google APIs

If you need access to only Google Workspace or supported Google APIs, you have the following options:

• You can use Direct Peering to directly connect (peer) with Google Cloud at a Google edge location.
• You can use Carrier Peering to peer with Google by connecting through a support provider, which in turn peers with Google.

Verified Peering Provider

Verified Peering Provider lets you reach all publicly available Google Cloud resources through an internet service provider, without the need to directly peer with Google. Verified Peering Provider is a simple alternative to Direct Peering. Verified Peering Providers manage all aspects of the Direct Peering arrangements with Google.

The Verified Peering Provider program identifies a group of internet service providers (ISPs) that have demonstrated diverse and reliable connectivity to Google. ISPs in the Verified Peering Provider program are awarded a Verified Peering Provider badge in one of two tiers, silver or gold, based solely on technical criteria related to their connectivity depth with Google.

Verified Peering Providers must adhere to guidelines that minimize latency changes to our customers during network outages, such as redundant and physically diverse connectivity to Google's network.

Providers must also have up-to-date operational contacts to help ensure quick troubleshooting when network issues arise. Google periodically validates enrolled providers against the program requirements to help ensure our customers continue to have a high-quality experience.

Google recommends connecting through a Verified Peering Provider to reach publicly available Google Cloud resources.

Verified Peering Providers offer a variety of internet services designed for enterprises, ranging from business-class internet access to high-bandwidth IP address transit. Google customers can choose a provider that best suits their needs. When viewing the list of Verified Peering Providers, you can see where each Verified Peering Provider connects to Google, and understand in what markets they offer services.

When you use a Verified Peering Provider, you don't need to meet Google's Direct Peering requirements and can work directly with a provider to obtain internet services.

Verified Peering Providers offer the following features:

• Simplified connectivity
  • No need to meet Google's peering requirements
  • Leave the complexities of peering arrangements to the Verified Peering Providers
  • Spend less time deploying and managing the technical complexities of the Direct Peering arrangement
  • Acquire IP address transit or dedicated internet access from a Verified Peering Provider and let the Verified Peering Provider handle the peering with Google
• High availability
  • Google badge verifies redundant connectivity to Google
  • Gold badge indicates metro redundancy; silver indicates points of presence (PoPs) redundancy
  • For redundant connectivity details, see Google Edge Network
• Enterprise grade connectivity
  • Connect to Google through internet products designed for enterprises
  • Access Google with or without the need for border gateway protocol (BGP) or an autonomous system number (ASN)
  • Work directly with internet service provider (ISP) customer services teams and operational escalations
• Dedicated private Google connectivity
  • All Google connectivity is through private dedicated fiber optics
  • Leverage the same Google fibers that carry all Google services
• Access all Google services
  • Access to Google Cloud services includes Google Workspace, Cloud APIss, Cloud VPN, public IP addresses, Network Service Tiers, and more
  • Any Google service that is reachable over the internet can be used with a Verified Peering Provider

Compare Verified Peering Provider and Cloud Interconnect

The following table describes the differences between Verified Peering Provider and Cloud Interconnect.

Verified Peering Provider	Cloud Interconnect
Does not require Google Cloud.	Requires Google Cloud.
No need to meet Google's Direct Peering requirements.	Does not provide access to Google Workspace, but provides access to all other Google Cloud products and services from your on-premises network. Also allows access to supported APIs and services by using Private Google Access from on-premises hosts.
Connects to Google's edge network through a Verified Peering Provider.	Provides direct access to VPC network resources that have only internal IP addresses.
Has no setup or maintenance costs.	Has maintenance costs; see pricing.
Verified Peering Providers are required to have diverse and redundant connectivity to Google.	Connects to Google's edge network.
Verified Peering Providers are required to have updated outage contacts on file, and dual IPv4 or IPv6 connectivity.	Uses Google Cloud resources, such as Cloud Interconnect connections, VLAN attachments, and Cloud Routers.
View where each Verified Peering Provider has connectivity to Google.	To change the destination IP address ranges for your on-premises network, adjust the routes that your routers share with Cloud Routers in your project.
Verified Peering Providers exclusively connect to Google over private network interconnections (PNI). Routes to your on-premises network don't appear in any VPC network of your Google Cloud project.	Routes to your on-premises network are learned by Cloud Routers in your project and applied as custom dynamic routes in your VPC network.
Does not provide direct access to VPC network resources that have only internal IP addresses.	Google offers an end-to-end SLA for the connectivity between your VPC network and on-premises network for Google-defined topologies.

For more information, see the Verified Peering Provider overview.

Direct Peering

Direct Peering enables you to establish a direct peering connection between your business network and Google's edge network and exchange high-throughput cloud traffic.

This capability is available at any of more than 100 locations in 33 countries around the world. For more information about Google's edge locations, see Google's peering site.

When established, Direct Peering provides a direct path from your on-premises network to Google services, including Google Cloud products that can be exposed through one or more public IP addresses. Traffic from Google's network to your on-premises network also takes that direct path, including traffic from VPC networks in your projects.

Direct Peering exists outside of Google Cloud. Unless you need to access Google Workspace applications, the recommended methods of access to Google Cloud are Dedicated Interconnect or Partner Interconnect.

Compare Direct Peering and Cloud Interconnect

The following table describes the differences between Direct Peering and Cloud Interconnect.

Direct Peering	Cloud Interconnect
Can be used by Google Cloud—for example, to access VMs through Cloud VPN—but does not require it.	Requires Google Cloud.
Provides direct access from your on-premises network to Google Workspace and Google APIs for the full suite of Google Cloud products.	Does not provide access to Google Workspace, but provides access to all other Google Cloud products and services from your on-premises network. Also allows access to supported APIs and services by using Private Google Access from on-premises hosts.
Does not provide direct access to VPC network resources that have only internal IP addresses.	Provides direct access to VPC network resources that have only internal IP addresses.
Has no setup or maintenance costs.	Has maintenance costs; see pricing.
Connects to Google's edge network.	Connects to Google's edge network.
Does not use any Google Cloud resources; configuration is opaque to Google Cloud projects.	Uses Google Cloud resources, such as Interconnect connections, VLAN attachments, and Cloud Routers.
To change the destination IP address ranges for your on-premises network, contact Google.	To change the destination IP address ranges for your on-premises network, adjust the routes that your routers share with Cloud Routers in your project.
Routes to your on-premises network don't appear in any VPC network of your Google Cloud project.	Routes to your on-premises network are learned by Cloud Routers in your project and applied as custom dynamic routes in your VPC network.
Google does not offer a service level agreement (SLA) with Direct Peering.	Google offers an end-to-end SLA for the connectivity between your VPC network and on-premises network for Google-defined topologies.

For more information, see the Direct Peering overview.

Carrier Peering

Carrier Peering enables you to access Google applications, such as Google Workspace, by using a service provider to obtain enterprise-grade network services that connect your infrastructure to Google.

When connecting to Google through a service provider, you can get connections with higher availability and lower latency, using one or more links. Work with your service provider to get the connection that you need.

When to use Carrier Peering

The following example describes a common use case for Carrier Peering.

To access Google Workspace applications from an on-premises network, an organization might need a perimeter network to reach Google's network. The perimeter network enables organizations to expose an isolated subnetwork to the public internet instead of their entire network. Instead of setting up and maintaining a perimeter network, the organization can work with a service provider so that their traffic travels on a dedicated link from their systems to Google. With the dedicated link, the organization gets a higher availability and lower latency connection to Google's network.

Unless you need to access Google Workspace applications as described in the preceding use case, Partner Interconnect is the recommended way to connect to Google through a service provider. To choose a product, see the Considerations section and the table that compares Carrier Peering with Cloud Interconnect.

Considerations

Review the following considerations to decide if Carrier Peering meets your needs:

• Carrier Peering exists outside of Google Cloud. Instead of Carrier Peering, the recommended methods of access to Google Cloud are Partner Interconnect, which uses a service provider, or Dedicated Interconnect, which provides a direct connection to Google.
• If used with Google Cloud, Carrier Peering doesn't produce any custom routes in a VPC network. Traffic sent from resources in a VPC network leaves by way of a route whose next hop is either a default internet gateway (a default route, for example) or a Cloud VPN tunnel.
• To send traffic through Carrier Peering by using a route whose next hop is a Cloud VPN tunnel, the IP address of your on-premises network's VPN gateway must be in your configured destination range.

Compare Carrier Peering and Cloud Interconnect

The following table describes the differences between Carrier Peering and Cloud Interconnect.

Carrier Peering	Cloud Interconnect
Can be used by Google Cloud, but does not require it.	Requires Google Cloud.
Gives you direct access from your on-premises network through a service provider's network to Google Workspace and to Google Cloud products that can be exposed through one or more public IP addresses.	Does not give you access to Google Workspace, but gives you access to all other Google Cloud products from your on-premises network. Also allows access to supported APIs and products by using Private Google Access from on-premises hosts.
Has service provider costs.	Has maintenance costs; see pricing.
Connects to Google's edge network through a service provider.	Connects to Google's edge network.
Does not use any Google Cloud resources; configuration is opaque to Google Cloud projects.	Uses Google Cloud resources, such as Interconnect connections, VLAN attachments, and Cloud Routers.
To change the destination IP address ranges for your on-premises network, contact Google.	To change the destination IP address ranges for your on-premises network, adjust the routes that your routers share with Cloud Routers in your project.
Routes to your on-premises network don't appear in any VPC network of your Google Cloud project.	Routes to your on-premises network are learned by Cloud Routers in your project and applied as custom dynamic routes in your VPC network.
Google does not offer a service level agreement (SLA) with Carrier Peering. If you are interested in an SLA, we recommend consulting with your network service provider to determine whether that provider might offer an SLA.	Google offers an end-to-end SLA for the connectivity between your VPC network and on-premises network for Google-defined topologies.

For more information, see the Carrier Peering overview.

Connecting to CDN providers

CDN Interconnect

CDN Interconnect enables select third-party Content Delivery Network (CDN) providers to establish direct peering links with Google's edge network at various locations, which enables you to direct your traffic from your Virtual Private Cloud (VPC) networks to a provider's network.

CDN Interconnect enables you to optimize your CDN population costs and use direct connectivity to select CDN providers from Google Cloud.

Your network traffic egressing from Google Cloud through one of these links benefits from the direct connectivity to supported CDN providers and is billed automatically with reduced pricing.

Setting up CDN Interconnect

If your CDN provider is already part of the program, you don't have to do anything. Traffic from supported Google Cloud locations to your CDN provider automatically takes advantage of the direct connection and reduced pricing.

Work with your supported CDN provider to learn what locations are supported and how to correctly configure your deployment to use intra-region egress routes. CDN Interconnect does not require any configuration or integration with Cloud Load Balancing.

If your CDN provider is not part of the program, contact your CDN provider and ask them to work with Google to get connected.

Typical use cases for CDN Interconnect

• High-volume egress traffic. If you're populating your CDN with large data files from Google Cloud, you can use the CDN Interconnect links between Google Cloud and selected providers to automatically optimize this traffic and save money.

• Frequent content updates. Cloud workloads that frequently update data stored in CDN locations benefit from using CDN Interconnect because the direct link to the CDN provider reduces latency for these CDN destinations.

  For example, if you have frequently updated data served by the CDN originally hosted on Google Cloud, you might consider using CDN Interconnect.

For information about pricing and service providers, see the CDN Interconnect overview.

What's next

• Network Connectivity key terms