Virtual Private Cloud networking in Google Cloud

Thursday 4 July 2024

Virtual Private Cloud networking in Google Cloud

This article extends my notes from Coursera course Google Cloud Fundamentals: Core Infrastructure | Coursera.

Virtual Private Cloud networking

Virtual private cloud (VPC):

secure, individual, private cloud-computing model hosted within a public cloud (e.g. Google Cloud)
on it customers can run code, store data, host websites, and do anything else they could do in an ordinary private cloud, but this private cloud is hosted remotely by a public cloud provider
provides networking functionality to:

Compute Engine virtual machine (VM) instances
Kubernetes Engine containers
App Engine flexible environment

without it we cannot create VM instances, containers, or App Engine applications => each Google Cloud project has a default network to get us started
Users can define their own (custom) virtual private cloud inside their Google Cloud project or simply use default virtual private cloud
VPCs combine the scalability and convenience of public cloud computing with the data isolation of private cloud computing
VPC networks connect Google Cloud resources to each other and to the internet. This includes:

segmenting networks
using firewall rules to restrict access to instances
creating static routes to forward traffic to specific destinations

We can think of a VPC network as similar to a physical network, except that it is virtualized within Google Cloud
VPC network is a global resource that consists of a list of regional virtual subnetworks (subnets) in data centers, all connected by a global wide area network (WAN)
VPC networks are logically isolated from each other in Google Cloud
Each Google Cloud project has a default network with subnets, routes, and firewall rules.
Without a VPC network:

there are no routes and no firewall rules
we cannot create a VM instance

Regions have three or more zones. For example, the us-west1 region denotes a region on the west coast of the United States that has three zones: us-west1-a, us-west1-b, and us-west1-c. Resources that live in a zone, such as virtual machine instances or zonal persistent disks, are referred to as zonal resources. Other resources, like static external IP addresses, are regional. Regional resources can be used by any resource in that region, regardless of zone, while zonal resources can only be used by other resources in the same zone. [Regions and zones | Compute Engine Documentation | Google Cloud]

Google VPC networks are global (cross-regional, as opposed to AWS VPCs which are per-region). This architecture makes it easy to define network layouts with global scope.

They can also have subnets, which is a segmented piece of the larger network, in any Google Cloud region worldwide.

Subnets can span the zones that make up a region (=> subnets are per-region, they can span multiple zones - data centres). Resources can even be in different zones on the same subnet.
Each subnet/region gets IP address range assigned. When an instance is created for our VPC network, it will be assigned an IP from the appropriate region’s address range.
The size of a subnet can be increased by expanding the range of IP addresses allocated to it, and doing so won’t affect virtual machines that are already configured
The default network has a subnet in each Google Cloud region
Each subnet is associated with a Google Cloud region and a private RFC 1918 CIDR block for its internal IP addresses range and a gateway

Example: VPC network named vpc1 has two subnets defined in the asia-east1 and us-east1 regions. If the VPC has three Compute Engine VMs attached to it, it means they’re neighbors on the same subnet even though they’re in different zones.

Subnet 10.0.0.0/24 is in asia-east1 region and ec2 instances can be in different zones, although in the same subnet:

ec2 with IP 10.0.0.2 is in asia-east1-a
ec2 with IP 10.0.0.3 is in asia-east1-b
ec2 with IP 10.0.0.4 is in asia-east1-c

Subnet 10.0.1.0/24 is in us-east1 region and ec2 instances can be in different zones, although in the same subnet:

ec2 with IP 10.0.1.2 is in us-east1-b
ec2 with IP 10.0.1.3 is in us-east1-c
ec2 with IP 10.0.1.4 is in us-east1-d

This capability can be used to build solutions that are resilient to disruptions yet retain a simple network layout.

This image shows a similar VPC and subnets layout:

source: https://cloud.google.com/static/vpc/images/vpc-overview-example.svg

Subnets let us create our own private cloud topology within Google Cloud. For Subnet creation mode we can choose Automatic to create a subnet in each region, or Custom to manually define the subnets.

When we create a VPC, if for Subnet creation mode we choose Automatic, we'll get Auto mode VPC Network. Auto mode networks create subnets in each region automatically.

If we ever delete the default network, we can quickly re-create it by creating an auto mode network.

Custom creation mode supports IPv4, or IPv4 and IPv6 (dual-stack). Automatic creation mode supports IPv4 (single-stack) only.

By default, when we create a VM instance in a VPC, its External IP address is ephemeral. If an instance is stopped, any ephemeral external IP addresses assigned to the instance are released back into the general Compute Engine pool and become available for use by other projects. When a stopped instance is started again, a new ephemeral external IP address is assigned to the instance. Alternatively, we can reserve a static external IP address, which assigns the address to our project indefinitely until we explicitly release it.

Virtual Private Cloud compatibility features

Routing Tables

Routes tell VM instances and the VPC network how to send traffic from an instance to a destination, either inside the network or outside Google Cloud.

Each VPC network comes with some default routes to route traffic among its subnets and send traffic from eligible instances to the internet.

There is a route for each subnet. These routes are managed for us, but we can create custom static routes to direct some packets to specific destinations. For example, we can create a route that sends all outbound traffic to an instance configured as a NAT gateway.

Much like physical networks, VPCs have routing tables. VPC routing tables are:

built-in so we don’t have to provision or manage a router
used to forward traffic from one instance to another within the same network, across subnetworks, or even between Google Cloud zones, without requiring an external IP address

Firewall

Firewall rules control incoming or outgoing traffic to an instance. By default, incoming traffic from outside our network is blocked.

VPCs provide a global distributed firewall:

we don’t have to provision or manage it
it can be controlled to restrict access to instances through both incoming and outgoing traffic
Firewall rules can be defined through network tags on Compute Engine instances

Example: we can tag all our web servers with, say, “WEB,” and write a firewall rule saying that traffic on ports 80 or 443 is allowed into all VMs with the “WEB” tag, no matter what their IP address happens to be

Each VPC network implements a distributed virtual firewall that we can configure.

Firewall rules allow us to control which packets are allowed to travel to which destinations.

Every VPC network has two implied firewall rules that block all incoming connections and allow all outgoing connections.

Firewall rules table has the following columns: Targets, Filters, Protocols/ports, and Action.

In GCP Console, in the left pane, if we click Firewall, we'll notice that there are 4 Ingress firewall rules for the default network:

default-allow-icmp
default-allow-rdp
default-allow-ssh
default-allow-internal

These firewall rules allow ICMP, RDP, and SSH ingress traffic from anywhere (0.0.0.0/0) and all TCP, UDP, and ICMP traffic within the network (e.g. 10.128.0.0/9).

When creating a new VPC, in Firewall section we can select all available rules. These are the same standard firewall rules that the default network has. The deny-all-ingress and allow-all-egress rules are also displayed, but you cannot check or uncheck them because they are implied. These two rules have a lower Priority (higher integers indicate lower priorities) so that the allow ICMP, custom, RDP and SSH rules are considered first.

After recreating the default network, allow-internal changes to allow-custom firewall rule. We can ping from within one VM instance another VM instance's internal IP (another instance can be in different region!) because of the allow-custom firewall rule.

*-allow-icmp firewall rule allows the ping to VM's external IP.

We can SSH to VM instance we create because of the allow-ssh firewall rule, which allows incoming traffic from anywhere (0.0.0.0/0) for tcp:22. The SSH connection works seamlessly because Compute Engine generates an SSH key for us and stores it in one of the following locations:

By default, Compute Engine adds the generated key to project or instance metadata.
If our account is configured to use OS Login, Compute Engine stores the generated key with our our account.

Alternatively, we can control access to Linux instances by creating SSH keys and editing public SSH key metadata.

To test connectivity to VM's internal or external IP we can use:

ping -c 4 <IP>

VPC Peering

VPCs belong to Google Cloud projects. VPC Peering:

used when our company has several Google Cloud projects, and the VPCs need to talk to each other
with it, a relationship between two VPCs can be established to exchange traffic

Shared VPC

Uses the full power of Identity Access Management (IAM) to control who and what in one project can interact with a VPC in another.

Connecting networks to Google VPC

There are several effective ways to connect the Google Virtual Private Cloud networks to other networks such as on-premises networks or networks in other clouds:

Cloud VPN can be used to create a “tunnel” connection over the internet

To make the connection dynamic, a Google Cloud feature called Cloud Router can be used. Cloud Router lets other networks and Google VPC, exchange route information over the VPN using the Border Gateway Protocol. Using this method, if we add a new subnet to our Google VPC, our on-premises network will automatically get routes to it.
Using the internet to connect networks isn't always the best option, either because of security concerns or because of bandwidth reliability

Direct Peering for “peering” with Google

Peering means putting a router in the same public data center as a Google point of presence (PoP) and using it to exchange traffic between networks
Google has more than 100 points of presence around the world.

Carrier Peering program - for customers who aren’t already in a point of presence

Gives direct access from 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
Downside: it isn’t covered by a Google Service Level Agreement

Dedicated Interconnect can be used if getting the highest uptimes for interconnection is important

Allows for one or more direct, private connections to Google
If these connections have topologies that meet Google’s specifications, they can be covered by an SLA of up to 99.99%.
These connections can be backed up by a VPN for even greater reliability.
Service Level Agreement is available

Partner Interconnect provides connectivity between an on-premises network and a VPC network through a supported service provider.

Useful if a data center is in a physical location that can't reach a Dedicated Interconnect colocation facility, or if the data needs don’t warrant an entire 10 GigaBytes per second connection.
Depending on availability needs, Partner Interconnect can be configured to support mission-critical services or applications that can tolerate some downtime.
As with Dedicated Interconnect, if these connections have topologies that meet Google’s specifications, they can be covered by an SLA of up to 99.99%

Cross-Cloud Interconnect helps establish high-bandwidth dedicated connectivity between Google Cloud and another cloud service provider

Google provisions a dedicated physical connection between the Google network and that of another cloud service provider. We can use this connection to peer our Google Virtual Private Cloud network with our network that's hosted by a supported cloud service provider.
Supports our adoption of an integrated multicloud strategy. In addition to supporting various cloud service providers, Cross-Cloud Interconnect offers reduced complexity, site-to-site data transfer, and encryption.
Connections are available in two sizes: 10 Gbps or 100 Gbps.