Proprietary + Confidential

Interconnecting
Networks

In this module, we focus on Interconnecting Networks.

Different applications and workloads require different network connectivity solutions.

That is why Google supports multiple ways to connect your infrastructure to Google
Cloud.
 Proprietary + Confidential

Agenda

01 Cloud VPN
Lab: Configuring Google Cloud HA VPN

02 Cloud Interconnect and Peering

03 Sharing VPC Networks

In this module, we’ll focus on Google Cloud’s hybrid connectivity products, which are
Cloud VPN, Cloud Interconnect, and Peering. We’ll also look at options for sharing
VPC networks within Google Cloud.

Let’s start by talking about Cloud VPN so that you can explore it in a lab.
 Proprietary + Confidential

Cloud VPN

01
 Proprietary + Confidential

Classic VPN securely connects your on-premises

network to your Google Cloud VPC network
Cloud VPN
● Useful for low-volume data connections

● 99.9% SLA

● Supports:
○ Site-to-site VPN
○ Static routes
○ Dynamic routes (Cloud Router)
○ IKEv1 and IKEv2 ciphers

Cloud VPN securely connects your on-premises network to your Google Cloud VPC
network through an IPsec VPN tunnel. Traffic traveling between the two networks is
encrypted by one VPN gateway, then decrypted by the other VPN gateway. This
protects your data as it travels over the public internet, and that’s why Cloud VPN is
useful for low-volume data connections.

As a managed service, Classic VPN provides an SLA of 99.9% service availability

and supports site-to-site VPN, static and dynamic routes, and IKEv1 and IKEv2
ciphers. Cloud VPN doesn't support use cases where client computers need to “dial
in” to a VPN using client VPN software. Also, dynamic routes are configured with
Cloud Router, which we will cover briefly.

For more information about the SLA and these features, please refer to the
documentation page.
 Proprietary + Confidential

Classic VPN topology

VPN Tunnel (Encrypted Traffic) Internet On-premises

External IP

On-premises
Network
Project

On-Premises
VPC Network us-east1 Google Cloud VPN Gateway
Regional Max.MTU = 1460 bytes
External IP
Routing Table
VPC Routing On-premises
Cloud VPN Gateway Subnets & Resources

10.0.1.0/24
us-west1
10.0.2.0/24
10.21.0.0/16 192.168.1.0/24

Google Cloud Google Cloud

10.0.29.0/24
Resources Resources

10.0.30.0/24

Let me walk through an example of Cloud VPN. This diagram shows a Classic VPN
connection between your VPC and on-premises network. Your VPC network has
subnets in us-east1 and us-west1, with Google Cloud resources in each of those
regions. These resources are able to communicate using their internal IP addresses
because routing within a network is automatically configured (assuming that firewall
rules allow the communication).

Now, in order to connect to your on-premises network and its resources, you need to
configure your Cloud VPN gateway, on-premises VPN gateway, and two VPN tunnels.
The Cloud VPN gateway is a regional resource that uses a regional external IP
address.

Your on-premises VPN gateway can be a physical device in your data center or a
physical or software-based VPN offering in another cloud provider's network. This
VPN gateway also has an external IP address.

A VPN tunnel then connects your VPN gateways and serves as the virtual medium
through which encrypted traffic is passed. In order to create a connection between
two VPN gateways, you must establish two VPN tunnels. Each tunnel defines the
connection from the perspective of its gateway, and traffic can only pass when the
pair of tunnels is established.
Now, one thing to remember when using Cloud VPN is that the maximum
transmission unit, or MTU, for your on-premises VPN gateway cannot be greater than
1460 bytes. This is because of the encryption and encapsulation of packets. For more
information about this MTU consideration, please refer to the documentation page.
 Proprietary + Confidential

HA VPN overview

● Provides 99.99% service availability.

● Google Cloud automatically chooses two external IP addresses.

○ Supports multiple tunnels
○ VPN tunnels connected to HA VPN gateways must use dynamic (BGP) routing

● Supports site-to-site VPN for different topologies/configuration scenarios:

○ An HA VPN gateway to peer VPN devices
○ An HA VPN gateway to an Amazon Web Services (AWS) virtual private gateway
○ Two HA VPN gateways connected to each other

In addition to Classic VPN, Google Cloud also offers a second type of Cloud VPN
gateway, HA VPN.

HA VPN is a high availability Cloud VPN solution that lets you securely connect your
on-premises network to your Virtual Private Cloud (VPC) network through an IPsec
VPN connection in a single region. HA VPN provides an SLA of 99.99% service
availability. To guarantee a 99.99% availability SLA for HA VPN connections, you must
properly configure two or four tunnels from your HA VPN gateway to your peer VPN
gateway or to another HA VPN gateway.

When you create an HA VPN gateway, Google Cloud automatically chooses two
external IP addresses, one for each of its fixed number of two 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 a 99.99% service availability SLA. VPN tunnels connected to HA
VPN gateways must use dynamic (BGP) routing. Depending on the way that you
configure route priorities for HA VPN tunnels, you can create an active/active or
active/passive routing configuration.
HA VPN supports site-to-site VPN in one of the following recommended topologies or
configuration scenarios:
● An HA VPN gateway to peer VPN devices
● An HA VPN gateway to an Amazon Web Services (AWS) virtual private
gateway
● Two HA VPN gateways connected to each other

Let's explore these configurations in a bit more detail.

 Proprietary + Confidential

HA VPN to peer VPN gateway topology

VPN Tunnel 0 (encrypted traffic)

VPN Tunnel 1 (encrypted traffic)

BGP (routes exchanged)

BGP (routes exchanged)

Internet

External IP address and External IP address and

BGP IP address BGP IP address
Google Cloud project 169.254.0.2 169.254.1.2

VPC network: network-a On-premises VPN On-premises VPN

Gateway 1 Gateway 2

us-central1
On-premises network
Interface 0 Regional
external IP address
HA VPN gateway
VPC routing
ha-vpn-gw-a Interface 1 Regional
On-premises subnets and resources
external IP address
(ASN 65002)
BGP Session 0 192.168.1.0/24
169.254.0.1
Cloud Router router-a (ASN …
192.168.30.0/24
65001) BGP Session 1
us-west1 169.254.1.1

subnet-a-west: 10.0.2.0/24 subnet-a-central: 10.0.1.0/24

Google Cloud Google Cloud

resources resources

Data plane
Control plane

There are three typical peer gateway configurations for HA VPN. An HA VPN gateway
to two separate peer VPN devices, each with its own IP address, an HA VPN gateway
to one peer VPN device that uses two separate IP addresses and an HA VPN
gateway to one peer VPN device that uses one IP address.

Let's walk through an example. In this topology, one HA VPN gateway connects to
two peer devices. Each peer device has one interface and one external IP address.
The HA VPN gateway uses two tunnels, one tunnel to each peer device. If your
peer-side gateway is hardware-based, having a second peer-side gateway provides
redundancy and failover on that side of the connection.

A second physical gateway lets you take one of the gateways offline for software
upgrades or other scheduled maintenance. It also protects you if there is a failure in
one of the devices.

In Google Cloud, the REDUNDANCY_TYPE for this configuration takes the value
TWO_IPS_REDUNDANCY. The example shown here provides 99.99% availability.
 Proprietary + Confidential

HA VPN to AWS peer gateway topology

AWS Cloud
Google Cloud project
us-east1
Virtual Private Cloud

AWS VPN
Connection #1 us-east4

Pub IP1
Transit Gateway (TGW) Int 0 HA Cloud VPN
AWS VPC Pub IP2 Subnet 10.1.1.0/24
Or Int 1 Gateway
10.2.2.0/24
Virtual Private Gateway (VGM) Pub IP3
Pub IP4 Internet

Cloud Router VPC Routing

AWS VPN
Connection #2

When configuring an HA VPN external VPN gateway to Amazon Web Services

(AWS), you can use either a transit gateway or a virtual private gateway. Only the
transit gateway supports equal-cost multipath (ECMP) routing. When enabled, ECMP
equally distributes traffic across active tunnels. Let’s walk through an example.

In this topology, there are three major gateway components to set up for this
configuration. An HA VPN gateway in Google Cloud with two interfaces, two AWS
virtual private gateways, which connect to your HA VPN gateway, and an external
VPN gateway resource in Google Cloud that represents your AWS virtual private
gateway. This resource provides information to Google Cloud about your AWS
gateway. The supported AWS configuration uses a total of four tunnels. Two tunnels
from one AWS virtual private gateway to one interface of the HA VPN gateway, and
two tunnels from the other AWS virtual private gateway to the other interface of the
HA VPN gateway.
 Proprietary + Confidential

HA VPN between Google Cloud networks topology

VPN tunnel: tunnel-a-to-b-if-0 VPN tunnel: tunnel-b-to-a-if-0

VPN tunnel: tunnel-a-to-b-if-1 VPN tunnel: tunnel-b-to-a-if-1

BGP (routes exchanged) BGP (routes exchanged)

Google production
Data plane BGP (routes exchanged)
BGP (routes exchanged) network
Control plane

Interface 0 Regional
external IP address

Interface 1 Regional
external IP address

if-tunnel-b-to-a-if-0
Google Cloud project Google Cloud project 169.254.0.2

if-tunnel-b-to-a-if-1
VPC network: network-a VPC network: network-b 169.254.1.2

us-central1 us-central1
Interface 0 Regional
external IP address
HA VPN gateway HA VPN gateway
ha-vpn-gw-a Interface 1 Regional ha-vpn-gw-b
external IP address
if-tunnel-a-to-b-if-0
Cloud Router router-a (ASN 169.254.0.1 Cloud Router router-b (ASN
65001) if-tunnel-a-to-b-if-1 65002)
us-west1 169.254.1.1
us-east1

subnet-a-west: 10.0.2.0/24 subnet-a-central: 10.0.1.0/24 subnet-b-east: 192.168.2.0/24 Subnet-b-central: 192.168.1.0/24

Google Cloud Google Cloud Google Cloud Google Cloud

resources resources resources resources

You can connect two Google Cloud VPC networks together by using an HA VPN
gateway in each network. The configuration shown provides 99.99% availability. From
the perspective of each HA VPN gateway you create two tunnels. You connect
interface 0 on one HA VPN gateway to interface 0 on the other HA VPN, and
interface 1 on one HA VPN gateway to interface 1 on the other HA VPN.

For more information on HA VPN, refer to the documentation Cloud VPN topologies.
For information on moving to HA VPN, see Moving to HA VPN.
 Proprietary + Confidential

Dynamic routing with Cloud Router

Peer Gateway with

graceful restart Cloud Router

BGP Session
Peer
Network
Rack 1: 10.0.1.0/24
10.20.0.0/16
(Test)
Rack 2: 10.0.2.0/24

10.21.0.0/16 Google VPN Internet Peer Gateway

(Prod) Gateway 169.254.1.2

Rack 29: 10.0.29.0/24

10.22.0.0/16
(Staging) 169.254.1.1 VPN tunnel using
Cloud Router Rack 30: 10.0.30.0/24
dynamic routing

BGP link local

IP addresses

We mentioned earlier that Cloud VPN supports both static and dynamic routes. In
order to use dynamic routes, you need to configure Cloud Routers. Cloud Router can
manage routes for a Cloud VPN tunnel using Border Gateway Protocol, or BGP. This
routing method allows for routes to be updated and exchanged without changing the
tunnel configuration.

For example, this diagram shows two different regional subnets in a VPC network,
namely Test and Prod. The on-premises network has 29 subnets, and the two
networks are connected through Cloud VPN tunnels. Now, how would you handle
adding new subnets? For example, how would you add a new “Staging” subnet in the
Google Cloud network and a new on-premises 10.0.30.0/24 subnet to handle growing
traffic in your data center?

To automatically propagate network configuration changes, the VPN tunnel uses

Cloud Router to establish a BGP session between the VPC and the on-premises VPN
gateway, which must support BGP. The new subnets are then seamlessly advertised
between networks. This means that instances in the new subnets can start sending
and receiving traffic immediately, as you will explore in the upcoming lab.

To set up BGP, an additional IP address has to be assigned to each end of the VPN
tunnel. These two IP addresses must be link-local IP addresses, belonging to the IP
address range 169.254.0.0/16. These addresses are not part of IP address space of
either network and are used exclusively for establishing a BGP session.
 Proprietary + Confidential

Lab Intro
Configuring Google Cloud HA VPN

Let’s apply what we just covered.

 Proprietary + Confidential

Lab objectives

01 Create two VPC networks and instances

02 Configure HA VPN gateways

03 Configure dynamic routing with VPN tunnels

04 Configure global dynamic routing mode

05 Verify and test HA VPN gateway configuration

In this lab you create a global VPC called vpc-demo, with two custom subnets in
us-east1 and us-central1. In this VPC, you add a Compute Engine instance in each
region. You then create a second VPC called on-prem to simulate a customer's
on-premises data center. In this second VPC, you add a subnet in region us-central1
and a Compute Engine instance running in this region. Finally, you add an HA VPN
and a cloud router in each VPC and run two tunnels from each HA VPN gateway
before testing the configuration to verify the 99.99% SLA.
 Proprietary + Confidential

Cloud Interconnect

02
and Peering

Next, let’s talk about the Cloud Interconnect and Peering services.
 Proprietary + Confidential

Dedicated Shared

Layer 3
Direct Peering Carrier Peering

Layer 2
Dedicated Interconnect Partner Interconnect

There are different Cloud Interconnect and Peering services available to connect your
infrastructure to Google’s network. These services can be split into Dedicated versus
Shared connections and Layer 2 versus Layer 3 connections. The services are Direct
Peering, Carrier Peering, Dedicated Interconnect, and Partner Interconnect.

Dedicated connections provide a direct connection to Google’s network, but shared

connections provide a connection to Google’s network through a partner. Layer 2
connections use a VLAN that pipes directly into your Google Cloud environment,
providing connectivity to internal IP addresses in the RFC 1918 address space. Layer
3 connections provide access to Google Workspace services, YouTube, and Google
Cloud APIs using public IP addresses.
 Proprietary + Confidential

Dedicated Shared

Layer 3
Direct Peering Cloud VPN Carrier Peering

Layer 2
Dedicated Interconnect Partner Interconnect

Now, as we just explained earlier, Google also offers its own Virtual Private Network
service, called Cloud VPN. This service uses the public internet, but traffic is
encrypted and provides access to internal IP addresses. That’s why Cloud VPN is a
useful addition to Direct Peering and Carrier Peering.

Let me explain the Cloud Interconnect and Peering services separately first and then
I’ll provide some guidance on choosing the right connection.
 Proprietary + Confidential

Dedicated Interconnect provides direct physical

connections
Dedicated
Interconnect

On-premises network

My-network (my-project1) Colocation facility Subnet:

192.168.0.0/24
us-central1 10.128.0.0/20 Zone 1
On-premises
User
Google router
Compute Cloud Router
Peering Edge
Link-local address: 196.168.0.11
Link-local address: 169.254.10.2
10.128.0.2
169.254.10.1 my-interconnect
(my-project1)

Dedicated Interconnect provides direct physical connections between your

on-premises network and Google’s network. This enables you to transfer large
amounts of data between networks, which can be more cost-effective than purchasing
additional bandwidth over the public internet.

In order to use Dedicated Interconnect, you need to provision a cross connect

between the Google network and your own router in a common colocation facility, as
shown in this diagram. To exchange routes between the networks, you configure a
BGP session over the interconnect between the Cloud Router and the on-premises
router. This will allow user traffic from the on-premises network to reach Google Cloud
resources on the VPC network, and vice versa.

Dedicated Interconnect can be configured to offer a 99.9% or a 99.99% uptime SLA.

See the Dedicated Interconnect documentation for details on how to achieve these
SLAs.
 Proprietary + Confidential

Amsterdam Stockholm
Denver

Toronto Hamburg
Chicago London
Frankfurt
Paris Munich
Seattle
Montréal Osaka
Marseille
Salt Lake City New York Seoul
Zurich
Tokyo
Hong Kong
Milan
San Jose Ashburn Madrid
Atlanta
Los Angeles Dallas

Las Vegas
Miami Taipei
Queretaro
Council Bluffs Mumbai

Chennai
São Paulo Singapore

Kuala Lumpur Jakarta Sydney

Rio de Janeiro

Colocation
facility Buenos Aires

locations Dedicated
Interconnect

In order to use Dedicated Interconnect, your network must physically meet Google’s
network in a supported colocation facility. This map shows the locations where you
can create dedicated connections. For a full list of these locations, please refer to the
documentation page.

Now, you might look at this map and say, “well I am nowhere near one of those
locations.” That’s when you want to consider Partner Interconnect.
 Proprietary + Confidential

Partner Interconnect provides connectivity

through a supported service provider
Partner
Interconnect
Service provide network On-premises network

VPC Network
On-premises
Google Cloud region subnet

VPC subnet

Co-location facility

Cloud Cloud Service provider On-premises

Router peering edge peering edge router

BGP

Partner Interconnect provides connectivity between your on-premises network and

your VPC network through a supported service provider. This is useful if your data
center is in a physical location that cannot reach a Dedicated Interconnect colocation
facility or if your data needs don't warrant a Dedicated Interconnect.

In order to use Partner Interconnect, you work with a supported service provider to
connect your VPC and on-premises networks. For a full list of providers, please refer
to the documentation page.

These service providers have existing physical connections to Google's network that
they make available for their customers to use. After you establish connectivity with a
service provider, you can request a Partner Interconnect connection from your service
provider. Then, you establish a BGP session between your Cloud Router and
on-premises router to start passing traffic between your networks via the service
provider's network.

Partner Interconnect can be configured to offer a 99.9% or a 99.99% uptime SLA

between Google and the service provider. See the Partner Interconnect
documentation for details on how to achieve these SLAs.
 Proprietary + Confidential

Comparison of Interconnect options

Connection Provides Capacity Requirements Access Type

Encrypted tunnel to VPC

IPsec VPN 1.5-3 Gbps per On-premises VPN
networks through the public
tunnel tunnel gateway
internet

Dedicated Dedicated, direct 10 Gbps or Connection in Internal IP

Interconnect connection to VPC networks 100 Gbps per link colocation facility addresses

Dedicated bandwidth, 50 Mbps –

Partner Service
connection to VPC network 50 Gbps per
Interconnect provider
through a service provider connection

Let me compare the interconnect options that we just discussed. All of these options
provide internal IP address access between resources in your on-premises network
and in your VPC network. The main differences are the connection capacity and the
requirements for using a service.

● The IPsec VPN tunnels that Cloud VPN offers have a capacity of 1.5 to 3
Gbps per tunnel and require a VPN device on your on-premises network. The
1.5-Gbps capacity applies to traffic that traverses the public internet, and the
3-Gbps capacity applies to traffic that is traversing a direct peering link. You
can configure multiple tunnels if you want to scale this capacity.
● Dedicated Interconnect has a capacity of 10 Gbps or 100 Gbps per link and
requires you to have a connection in a Google-supported colocation facility.
You can have up to 8 links to achieve multiples of 10 Gbps, or up to 2 links to
achieve multiples of 100 Gbps, but 10 Gbps is the minimum capacity.
● Partner Interconnect has a capacity of 50 Mbps to 50 Gbps per connection,
and requirements depend on the service provider.

My recommendation is to start with VPN tunnels. When you need enterprise-grade

connections to Google Cloud, switch to Dedicated Interconnect or Partner
Interconnect, depending on your proximity to a colocation facility and your capacity
requirements.
 Proprietary + Confidential

Direct Peering provides a direct connection between

your business network and Google’s

● Broad-reaching edge network locations

● Exchange BGP routes

● Reach all of Google’s services

● Peering requirements

● No SLA

Let’s talk about the Cloud Peering services, which are Direct Peering and Carrier
Peering. These services are useful when you require access to Google and Google
Cloud properties.

Google allows you to establish a Direct Peering connection between your business
network and Google’s. With this connection you will be able to exchange internet
traffic between your network and Google’s at one of Google’s broad-reaching edge
network locations.

Direct Peering with Google is done by exchanging BGP routes between Google and
the peering entity. After a Direct Peering connection is in place, you can use it to
reach all of Google’s services, including the full suite of Google Cloud products.
Unlike Dedicated Interconnect, Direct Peering does not have an SLA.

In order to use Direct Peering, you need to satisfy the peering requirements listed
here.
 Proprietary + Confidential

Grace Hopper
Havfrue
(US, UK, ES)
(US, IE, DK)
2022
2019
Dunant
(US, FR)
Faster 2020
(US, JP, TW)
2016

Equiano
(PT, NG, ZA)
2021
SJC
PLCN (JP, HK, SG)
(US, TW) 2013
2020

Unity
(US, JP)
2010 Curie Monet
(CL, US) (US, BR)
2019 2017

JGA-S
Junior (GU, AU)
(Rio, Santos) 2019

Edge Points
2018
Tannat
(BR, UY, AR) Indigo
2018 (SG, ID, AU)

of Presence
2019

Edge point Current region Future region

(PoPs) of presence
Network
with 3 zones with 3 zones

Google Cloud’s Edge Points of Presence, or PoPs, are where Google's network
connects to the rest of the internet via peering. PoPs are present on over 90 internet
exchanges and at over 100 interconnection facilities around the world.

For more information about these exchange points and facilities, we recommend
looking at Google’s PeeringDB entries, which are linked here:

https://www.peeringdb.com/asn/15169
https://www.peeringdb.com/net/4319

If you look at this map and say “Hey, I am nowhere near one of those locations,” you
will want to consider Carrier Peering.
 Proprietary + Confidential

Carrier Peering provides connectivity through a

supported partner

● Carrier Peering partner

● Reach all of Google’s services

● Partner requirements

● No SLA

If you require access to Google public infrastructure and cannot satisfy Google’s
peering requirements, you can connect via a Carrier Peering partner. Work directly
with your service provider to get the connection you need and to understand the
partner’s requirements. For a full list of available service providers, please refer to the
documentation page.

Now, just like Direct Peering, Carrier Peering does not have an SLA.
 Proprietary + Confidential

Comparison of Peering options

Connection Provides Capacity Requirements Access Type

Dedicated, direct Connection in

10 Gbps
Direct Peering connection to Google's Google Cloud
Per link
network PoPs
Public IP
addresses

Peering through service

Carrier Varies based on
provider to Google’s public Service provider
Peering partner offering
network

Let me compare the peering options that we just discussed. All of these options
provide public IP address access to all of Google’s services. The main differences are
capacity and the requirements for using a service.

● Direct Peering has a capacity of 10 Gbps per link and requires you to have a
connection in a Google Cloud Edge Point of Presence.
● Carrier Peering’s capacity and requirements vary depending on the service
provider that you work with.
 Proprietary + Confidential

5 ways to connect your infrastructure to Google Cloud

Dedicated Shared

Layer 3
Direct Peering Cloud VPN Carrier Peering

Layer 2
Dedicated Interconnect Partner Interconnect

Now that we have discussed all the different connection services, let me help you
determine which service best meets your hybrid connectivity needs.

We started this lesson by introducing the 5 different ways to connect your

infrastructure to Google Cloud. We split these services into Dedicated versus Shared
connections and Layer 2 versus Layer 3 connections.
 Proprietary + Confidential

Choosing a network connection option

Interconnect Peering

Direct access to RFC1918 IPs Access to Google public IPs

in your VPC - with SLA only - without SLA

Dedicated Partner Cloud VPN Direct Peering Carrier Peering

Interconnect Interconnect

Another way to organize these services is by Interconnect services and by Peering

services.

Interconnect services provide direct access to RFC1918 IP addresses in your VPC,

with an SLA. Peering services, in contrast, offer access to Google public IP addresses
only, without an SLA.
 Proprietary + Confidential

Connect your
infrastructure
to the cloud? Yes
No
Connect to Extend the reach of
Workspace/ your network to
YouTube? Google Cloud?

Meet Google’s Meet at one of Modest bandwidth,

peering Google’s colocation short duration, trials,
requirements? facilities? encrypted channel

Own encryption
mechanisms for
Direct Carrier sensitive traffic? Cloud Partner
Peering Peering VPN Interconnect

10 Gbps too much or

Partner multiple clouds Dedicated
Interconnect Interconnect

Another way to choose the right service that meets your needs is with a flow diagram.
Let me walk you through this diagram from the top, using the assumption that you
want to extend your infrastructure to the cloud.

Ask yourself whether you need to extend your network for Workspace services,
YouTube, or Google Cloud APIs. If you do, choose one of the Peering services. If you
can meet Google’s Direct Peering requirements, choose Direct Peering; otherwise,
choose Carrier Peering.

If you don’t need to extend your network for Workspace services or Google Cloud
APIs but want to extend the reach of your network to Google Cloud, you want to pick
one of the Interconnect services. If you cannot meet Google at one of its colocation
facilities, choose Cloud VPN or Partner Interconnect. This choice will depend on your
bandwidth and encryption requirements, along with the purpose of the connection.
Specifically, if you have modest bandwidth needs, will use the connection for short
durations and trials, and require an encrypted channel, choose Cloud VPN; otherwise,
choose Partner Interconnect. If you can meet Google at one of its colocation facilities,
you might jump to Dedicated Interconnect; however, if you cannot provide your own
encryption mechanisms for sensitive traffic, feel that a 10-Gbps connection is too big,
or want access to multiple clouds, you’ll want to consider Cloud VPN or Partner
Interconnect instead.
 Proprietary + Confidential

03 Sharing VPC Networks

Let’s move our attention from hybrid connectivity to sharing VPC networks.

In the simplest cloud environment, a single project might have one VPC network,
spanning many regions, with VM instances hosting very large and complicated
applications. However, many organizations commonly deploy multiple, isolated
projects with multiple VPC networks and subnets.

In this lesson, we are going to cover two configurations for sharing VPC networks
across Google Cloud projects. First, we will go over shared VPC, which allows you to
share a network across several projects in your Google Cloud organization. Then, we
will go over VPC Network Peering, which allows you to configure private
communication across projects in the same or different organizations.
 Proprietary + Confidential

Shared VPC

Cloud VPC Network

On-Premises
Recommendation Service

Data Warehouse

Web Application Server Personalization Service

Processed Changes Data Warehouse

Clients

Analytics Service

Data Warehouse

Connectivity Google Cloud Project

Shared VPC allows an organization to connect resources from multiple projects to a

common VPC network. This allows the resources to communicate with each other
securely and efficiently using internal IPs from that network.

For example, in this diagram there is one network that belongs to the Web Application
Server’s project. This network is shared with three other projects, namely the
Recommendation Service, the Personalization Service, and the Analytics Service.
Each of those service projects has instances that are in the same network as the Web
Application Server and allow for private communication to that server, using internal
IP addresses. The Web Application Server communicates with clients and
on-premises using the server’s external IP address. The backend services, in
contrast, cannot be reached externally because they only communicate using internal
IP addresses.

When you use shared VPC, you designate a project as a host project and attach one
or more other service projects to it. In this case, the Web Application Server’s project
is the host project, and the three other projects are the service projects. The overall
VPC network is called the shared VPC network.
 Proprietary + Confidential

VPC peering

Organization node Organization

example.com node SaaS.com

VPC Consumer Network VPC Producer Network

Consumer Producer
Consumer Producer
Instance Admin Instance Admin
Network Network
Admin Admin
Private IP
Project customer-prod Project service-prod

Client Serving Instance

Compute Engine Compute Engine

VPC Network Peering, in contrast, allows private RFC 1918 connectivity across two
VPC networks, regardless of whether they belong to the same project or the same
organization. Now, remember that each VPC network will have firewall rules that
define what traffic is allowed or denied between the networks.

For example, in this diagram there are two organizations that represent a consumer
and a producer, respectively. Each organization has its own organization node, VPC
network, VM instances, Network Admin, and Instance Admin. In order for VPC
Network Peering to be established successfully, the Producer Network Admin needs
to peer the Producer Network with the Consumer Network, and the Consumer
Network Admin needs to peer the Consumer Network with the Producer Network.
When both peering connections are created, the VPC Network Peering session
becomes Active and routes are exchanged. This allows the virtual machine instances
to communicate privately using their internal IP addresses.

VPC Network Peering is a decentralized or distributed approach to multi-project

networking, because each VPC network may remain under the control of separate
administrator groups and maintains its own global firewall and routing tables.
Historically, such projects would consider external IP addresses or VPNs to facilitate
private communication between VPC networks. However, VPC Network Peering does
not incur the network latency, security, and cost drawbacks that are present when
using external IP addresses or VPNs.
 Proprietary + Confidential

Shared VPC versus VPC peering

Consideration Shared VPC VPC Network Peering

Across organizations No Yes

Within project No Yes

Network administration Centralized Decentralized

Now that we’ve talked about Shared VPC and VPC Network Peering, let me compare
both of these configurations to help you decide which is appropriate for a given
situation.

If you want to configure private communication between VPC networks in different

organizations, you have to use VPC Network Peering. Shared VPC only works within
the same organization.

Somewhat similarly, if you want to configure private communication between VPC

networks in the same project, you have to use VPC Network Peering. This doesn’t
mean that the networks need to be in the same project, but they can be. Shared VPC
only works across projects.
 Proprietary + Confidential

Shared VPC vs. VPC peering

Consideration Shared VPC VPC Network Peering

Across organizations No Yes

Within project No Yes

Network administration Centralized Decentralized

Organization Admin Organization Admin (if same org)

Shared VPC Admin Security and Security and Security and

Network Network Network
Security and Network Admins Admins Admins Admins

Project Owner Project Owner Project Owner Project Owner Project Owner Project Owner

In my opinion, the biggest difference between the two configurations is the network
administration models. Shared VPC is a centralized approach to multi-project
networking, because security and network policy occurs in a single designated VPC
network. In contrast, VPC Network Peering is a decentralized approach, because
each VPC network can remain under the control of separate administrator groups and
maintains its own global firewall and routing tables.

If you want to learn more about Shared VPC and VPC peering, we recommend the
Networking in Google Cloud course.
 Proprietary + Confidential

Quiz
 Proprietary + Confidential

Question #1
Question

What is the purpose of virtual private networking (VPN)?

A. It is a method to detect intruders at the edge of a network boundary

B. VPNs are also called access control lists, or ACLs, and they limit network access

C. To enable a secure communication method (a tunnel) to connect two trusted

environments through an untrusted environment, such as the internet

D. The main purpose is to encrypt data so that it can be stored in an encrypted format
 Proprietary + Confidential

Question #1
Answer

What is the purpose of virtual private networking (VPN)?

A. It is a method to detect intruders at the edge of a network boundary

B. VPNs are also called access control lists, or ACLs, and they limit network access

C. To enable a secure communication method (a tunnel) to connect two trusted

environments through an untrusted environment, such as the internet

D. The main purpose is to encrypt data so that it can be stored in an encrypted format

Explanation:
VPNs use IPSec tunnels to provide an encapsulated and encrypted path through a
hostile or untrusted environment.
 Proprietary + Confidential

Question #2
Question

Which Google Cloud Interconnect service requires a connection in a Google Cloud

colocation facility and provides 10 Gbps per link?

A. Cloud VPN

B. Dedicated Interconnect

C. Partner Interconnect

D. Direct Peering

E. Carrier Peering
 Proprietary + Confidential

Question #2
Answer

Which Google Cloud Interconnect service requires a connection in a Google Cloud

colocation facility and provides 10 Gbps per link?

A. Cloud VPN

B. Dedicated Interconnect

C. Partner Interconnect

D. Direct Peering

E. Carrier Peering

Explanation:
A. That’s incorrect. IPsec VPN tunnels provide 1.5-3 Gbps per tunnel and do not
connect at a Google Cloud colocation facility.
B. Correct! Dedicated Interconnect requires a connection in a Google Cloud
colocation facility and provides 10 Gbps per link.
C. That’s incorrect. Partner Interconnect connects at a service provider.
D. That’s incorrect. Direct Peering is not a Google Cloud Interconnect service.
E. That’s incorrect. Carrier Peering is not a Google Cloud Interconnect service.
 Proprietary + Confidential

Question #3
Question

If you cannot meet Google’s peering requirements, which network connection service
should you choose to connect to Google Workspace and YouTube?

A. Dedicated Interconnect

B. Partner Interconnect

C. Direct Peering

D. Carrier Peering
 Proprietary + Confidential

Question #3
Answer

If you cannot meet Google’s peering requirements, which network connection service
should you choose to connect to Google Workspace and YouTube?

A. Dedicated Interconnect

B. Partner Interconnect

C. Direct Peering

D. Carrier Peering

Explanation:
A. That’s incorrect. Dedicated Interconnect is not a peering service.
B. That’s incorrect. Partner Interconnect is not a peering service.
C. That’s incorrect. Direct Peering requires you to meet Google’s peering
requirements.
D. That’s correct! Carrier Peering allows you to connect to Google Workspace
and YouTube without meeting Google’s peering requirements.
 Proprietary + Confidential

Question #4
Question

Which of the following approaches to multi-project networking, uses a centralized network

administration model?

A. VPC Network Peering

B. Shared VPC

C. Cloud VPN
 Proprietary + Confidential

Question #4
Answer

Which of the following approaches to multi-project networking, uses a centralized network

administration model?

A. VPC Network Peering

B. Shared VPC

C. Cloud VPN

Explanation:
A. That’s incorrect. VPC Network Peering is a decentralized approach, because
each VPC network can remain under the control of separate administrator
groups and maintains its own global firewall and routing tables.
B. Correct! Shared VPC is a centralized approach to multi-project networking,
because security and network policy occurs in a single designated VPC
network.
C. That’s incorrect. Please review the course material.
 Proprietary + Confidential

Review:
Interconnecting Networks

In this module, we looked at the five different ways of connecting your infrastructure to
Google Cloud, which are Dedicated Interconnect, Partner Interconnect, Cloud VPN,
Direct Peering, and Carrier Peering. We also gave you some guidance on how to
choose between different services. Remember, you might start out using one service,
and as your requirements change or new colocation facilities open, switch to a
different service.

We also gave you a brief overview of shared VPC and VPC Network Peering, which
are two configurations for sharing VPC networks across Google Cloud projects.