Elastic Cloud Infrastructure: Scaling and Automation - Summary Notes

This following illustration talks about Cloud VPN:

Fig.1

Cloud VPN securely connects a customers on-prem network to their GCP VPC network through an IPSec VPN Tunnel
Traffic between the two networks is encrypted by a VPN Gateway on one end of the Tunnel and then decrypted by the other VPN Gateway on the other end of the Tunnel
Cloud VPN is useful for low volume data connections
As a managed service Cloud VPN provides a 99.9 percent SLA
Cloud VPN supports site to site VPN Static and Dynamic routes
Dynamic routes can be configured with Cloud Router
This following illustration shows an example Cloud VPN topology:

Fig.2

The user has a VPC network with subnets as well as other resources in the Regions us-east1 and us-west1
The resources across those Regions are able to communicate using their Internal IP addresses because routing within a network is automatically configured (assuming that firewall rules allow the communication)
In order to connect to the customers on-prem network and its resources, the customer needs to configure their on-prem VPN Gateway to communicate with the Cloud VPN Gateway through VPN Tunnels
The VPN Gateway is a Regional resource that uses a Regional External IP address
The on-prem VPN Gateway can be a physical device in the customers data center OR a physical (or software) based VPN offering in another Cloud providers network. This VPN Gateway will also have an External IP address
A VPN Tunnel then connects the two VPN Gateways and serves as the virtual medium through which encrypted traffic is passed
In order to create a connection between two VPN Gateways, one must establish 2 VPN Tunnels. Each Tunnel defines the connection from the perspective of its VPN Gateway and traffic can only pass when the pair of Tunnels is established
For example, if we had 2 VPC networks vpc-1 and vpc-2 with the corresponding subnets subnet-1 and subent-2. The path from subnet-1 to subnet-2 is not the same as the path from subnet-2 to subnet-1. If both Tunnels are not established, one would not be able to ping the remote server on its internal IP address. The ping might reach the remote server, but the response can't be returned
The Maximum Transmission Unit (MTU) size for the user's on-premises VPN Gateway cannot be greater than 1460 bytes. This is because of the encryption and encapsulation of packets
This following illustration shows Dynamic Routing using a Cloud Router:

Fig.3

Cloud Router can manage routes from VPN Tunnel using Border Gateway Protocol (BGP). This routing method allows for routes to be updated and exchanged without changing the Tunnel configuration
The example in Fig.3 above shows 2 different Regional subnets in a VPC network, namely, test and prod. The on-prem network has 29 subnets and the two networks are connected through VPN Tunnels
To handle adding new subnets to the topology that automatically propagate network configuration changes, the VPN Tunnel uses Cloud Router to establish a BGP session between the VPC and the on-prem VPN Gateway which must support BGP. The new subnets are then seamlessly advertised between the networks in the topology. This means that instances in the new subnets can start sending and receiving traffic immediately
To set up BGP, an additional IP address has to be assigned to each end of the VPN Tunnel. These 2 IP addresses must be Link-Local IP addresses in 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
The purpose of VPN is to enable a secure communication Tunnel to connect 2 trusted environments through an untrusted envrionment (the Internet)

This following illustration shows the different Cloud Interconnect and Peering options:

Fig.4

There are different Cloud Interconnect and Peering services available to connect a customers infrastructure to Google's network. These services can be split into Dedicated versus Shared connections and Layer 2 verses Layer 3 connections
The Cloud Interconnect and Peering options are Direct Peering, Carrier Peering, Dedicated Interconnect, and Partner Interconnect
Dedicated connections provide a direct connection to Google's network
Shared connections provide a connection to Google's network through a partner network
Layer 2 connections use a VLAN that pipes directly into a user's GCP environment, providing connectivity to Internal IP addresses in the RFC 1918 address space
Layer 3 connections provide access to G Suite services, YouTube and Google Cloud APIs using public IP addresses

Dedicated Interconnect provides direct physical connections between a customers on-prem network and Google's network. This enables one to transfer a large amount of data between networks which can be more cost-effective than purchasing additional bandwidth over the public Internet
This following illustration shows the direct physical connect using Dedicated Interconnect:

Fig.5

To use a Dedicated Interconnect one must provision a cross-connect between the Google network and their own Router in a common co-location facility as shown in Fig.5 above
To exchange routes between the two networks, one must configure a BGP session over the Interconnect between the Cloud Router and the on-prem Router. This will allow user traffic from the on-prem network to reach GCP resources on the VPC network and vice-versa
Dedicated Interconnect can be configured to offer a 99.9 percent or a 99.99 percent uptime SLA
In order to use Dedicated Interconnect, the customerss network must physically meet Google's network in a supported co-location facility
This following illustration shows a map with co-location facilities where one can create dedicated connections:

Fig.6

If a customers network (data center) is not near any of the Google co-location facilities (as shown in the map in Fig.6 above), that is when the customer may want to consider a Partner Interconnect
This following illustration shows the connection using Partner Interconnect:

Fig.7

Partner Interconnect provides connectivity between a customers on-prem network and their VPC network through a supported Service Provider
The Service Providers have existing physical connections to Google's network that they make available for their customers to use
After a customer establishes connectivity to the Service Provider, they can request a Partner Interconnect connection from their Service Provider. That will establish a BGP session between the customers Cloud Router and On-premise Router to start passing traffic between their networks via the Service Providers network
Partner Interconnect can be configured to offer a 99.9 percent or 99.99 percent uptime SLA between Google and the Service Provider
This following illustration shows the comparison between Cloud VPN, Dedicated Interconnect, and Partner Interconnect:

Fig.8

All of the Interconnect options provide an Internal IP address access between resources in the customers on-prem network and their VPC network
The IPSec VPN Tunnels that Cloud VPN offers have a capacity of 1.5 Gbps to 3 Gbps per Tunnel and require VPN device on the customers on-prem network
The 1.5 Gbps capacity applies to the traffic that traverses the public Internet and the 3 Gbps capacity applies to the traffic that is traversing a Direct Peering link
One can configure multiple VPN Tunnels if they want to scale the capacity
Dedicated Interconnect has a capacity of 10 Gbps per link and requires one to have a connection in a Google supported co-location facility
One can have up to 8 Dedicated Interconnect links to achieve multiples of 10 Gbps but 10 Gbps is the minimum capacity
Currently there is a feature in beta that provides 100 Gbps per link with a maximum of 2 links
Partner Interconnect has a capacity of 50 Mbps to 10 Gbps per connection and requirements depend on the Service Provider

There are two types of Cloud Peering services - Direct Peering and Carrier Peering
With Cloud Peering services, one will be able to exchange internet traffic between their network and Google's at one of the Google's broad-reaching Edge Network locations
This following illustration shows the Direct Peering option:

Fig.9

Direct Peering with Google is done by exchanging BGP routes between Google and the peering entity
Once the Direct Peering connection is in place, one can use it to reach all the Google's services including the full suite of Google Cloud Platform products
Direct Peering DOES NOT have an SLA
This following illustration shows a map with the locations of the Google's Edge Points of Presence (PoPs):

Fig.10

GCP's Edge Points of Presence (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
If a customers network (data center) is not near any of the PoPs (as shown in the map in Fig.10 above), then the customer may want to consider a Carrier Peering
This following illustration talks about Carrier Peering option:

Fig.11

Carrier Peering DOES NOT have an SLA
This following illustration shows the comparison between Direct Peering and Carrier Peering:

Fig.12

All of the Peering options provide Public IP address access to all of Google's services
Direct Peering has a capacity of 10 Gbps per link and requires one to have a connection in a GCP Edge PoPs
Carrier Peering's capacity and requirements vary depending on the service provider
This following illustration shows the two Interconnect and Peering options:

Fig.13

Interconnect services provide direct access to RFC 1918 IP addresses in a customers VPC with an SLA
Peering services in contrast offer access to Google public IP addresses only without an SLA
This following illustration shows a decision tree of the connection options:

Fig.14

If a customer needs to extend their network for G Suite services, YouTube or Google Cloud APIs, then they choose one of the Peering services
If the customer can meet Google's Direct Peering requirements, they choose Direct Peering. Otherwise, they choose Carrier Peering
If a customer wants to extend the reach of their network to GCP, they may want to pick one of the Interconnect services
If the customer cannot meet Google at one of its co-location facilities, they may want to choose Cloud VPN or Partner Interconnect. This choice will depend on their bandwidth and encryption requirements along with the purpose of the connection

Typically organizations commonly deploy multiple isolated GCP Projects with multiple VPC networks and subnets. There are 2 options for sharing VPC networks across GCP projects - Shared VPC and VPC Network Peering
Shared VPC allows one to share a common VPC network across several Projects in their GCP organization. This allows the resources to communicate with each other securely and efficiently using internal IPs from that VPC network
VPC Network Peering allows one to configure private RFC 1918 communication across Projects in same or different organizations
This following illustration shows an example of Shared VPC:

Fig.15

From the Fig.15 above, there is one network that belongs to the Web Application Servers Project. This network is shared with three other Projects, namely, the Recommendation service, the Personalization service, and the Analytics service
Each of these service Projects has VM instances that are in the same network as the Web Application Server Project and allow for private communication to that server using the internal IP addresses
The Web Application Server communicates with clients and on-premises using the server's external IP address
The 3 backend services (the Recommendation service, the Personalization service, and the Analytics service) in contrast cannot be reached externally because they only communicate using internal IP addresses
With Shared VPC, one designates a Project as a Host Project and attaches one or more other service Projects to it. The overall VPC network is called the Shared VPC network
This following illustration shows an example of VPC Peering:

Fig.16

From the Fig.16 above, 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. Similarly, 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 VM 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
VPC Network Peering does not incur the network latency, security, and cost drawbacks that are present when using external IP addresses or VPNs
This following table compares both Shared VPC and VPC Network Peering:

Fig.17

For private communication between VPC networks in the same Project or Projects in different organizations, choose VPC Network Peering
Shared VPC only works within the same organization across Projects
Shared VPC is a centralized approach to multi-Project networking because security and network policy occurs in a single designated VPC network
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