GCP: Virtual Private Cloud

Today I’m reviewing some details related to GCP’s managed networking objects and management tools referred to as the Virtual Private Cloud, or VPC. The VPC is very similar to physical networks except that it is virtualized on distributed Google server space. The VPC is essential to allow any of your Google Cloud projects and services to communicate both internally and externally. As with all GCP services, Virtual Private Cloud services are specific to and configured within GCP projects–just something to keep in mind while talking about this cloud networking environment. The default GCP project can contain up to five networks that can also be shared/peered with other GCP project networks.

Networks & Subnetworks

A GCP network is a global–spanning all availability regions–networking object containing subnetworks. The network object has no default IP address range, but is instead a set of all addresses used by a project’s services. Services, such as VM instances that exist within the same virtual network can communicate over interal IP addresses even if their respective subnetworks are in different regions. Thus each network can be described as a private, global network. Services located in different networks, even if in the same region, as well as external services and clients communicate via external IP addresses. One thing to note is that services of the same project communicating over external IP addresses won’t actually touch the public internet, but rather traverse the Google edge service router network.

GCP networks are available in two general modes, Auto(default) and Custom. The Auto Mode network creates one subnet per availability region, with each region having a predefined range of IP addresses with a fixed /20 subnet mask. Alternatively, the Custom Mode network has no default subnets and allows full administrative control of subnets and IP ranges, with a few restrictions on subnet IP range overlap. Auto Mode networks can be converted to Custom Mode networks, but such a conversion shouldn’t be undertaken lightly as it is not possible to switch back from a Custom to Auto Mode network. The Auto Mode network can be expanded from a /20 to /16 subnet mask space, but again the process is not reversible and larger subnets are generally to be avoided beyond what’s actually needed as it increases the risk of address collision. A highlight of VPC subnet expansion on GCP is that it’s possible, and in fact quite easy, to expand the subnet with zero downtime of services on the subnet via the Cloud Console network management tool.

Regions & Zones

Localization of services with GCP Regions and Zones provides data protection/redundancy and high service availability. Regions are related to subnets in that each subnet spans a particular region including all of that region’s zones. The subnet provides a range of addresses for the given region with typical address range restrictions for network gateway and broadcast addresses. Services, even within different zones of the same region, can be in the same subnet. This also makes securing the network easier as firewall rules for the subnet can apply to services in a zones covered by the subnet.

IP Addressing

Every service in GCP can have two IP addresses: a required internal IP address allocated from its subnet range via DHCP lease renewed every 24 hours and an optional external IP address either assigned from an ephemeral pool of addresses or a reserved, static address. The internal IP addresses are mapped to VM instance names and registed with a network-scope DNS. External IP address are not visible to VM instances and are mapped internally to an instances internal IP address. Notably, a reserved static address not currently attached to a running VM instance is billed at higher rate than either a pool address or a reserved address that is attached to a VM instance.

Billing

Here’s an overview of some billing differences between the networking options we’ve been looking at. These are just to get an idea of how different services are billed comparitively and they can, of course, change at any time. GCP also offers a pretty cool Pricing Calculator that has enough granularity to capture variations in network type and usage.

Cloud Shell Fun

While virtually all of the networking adminstration tasks are easily accomplished from the Cloud Console GUI, I enjoy working in the command line and the integrated Cloud Shell makes it really easy with the gcloud SDK preinstalled and admin privledges to the project you’re working on. Let’s look at a few network setup tasks from the command line.

First, let’s create a new Custom Mode network.

$ gcloud compute networks create matnet \
	> --subnet-mode=custom

Boom, virtual network created, but there’s not much too it yet. Remember the Custom Mode networks don’t include all of the default Auto Mode subnets and firewall rules. So let’s add a subnet in the us-west2 region.

$ gcloud compute networks subnets create matnet-subnet-us-west \
	> --region=us-west2 \
	> --range=172.24.0.0/24

Great, now we have a network with a subnet deployed. We can check that everything deployed correctly.

$ gcloud compute networks list && gcloud compute networks subnets list --sort-by=NETWORK

NAME           SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
matnet         CUSTOM       REGIONAL

NAME                   REGION           NETWORK        RANGE
matnet-subnet-us-west  us-west2         matnet         176.24.0.0/24

Now we can set some basic rules for the network to allow specific external ingress traffic. These rules can be created individually for more granularity or grouped together as below.

$ gcloud compute firewall-rules create matnet-allow-icmp-ssh-rdp \
	> --network=matnet \
	> --direction=INGRESS \
	> --action=ALLOW \
	> --priority=1000
	> --rules=icmp,tcp:22,tcp:3389 \
	> --source-ranges=0.0.0.0/0

We can list our firewall rules to make sure things look correct.

$ gcloud compute firewall-rules list --sort-by=NETWORK

NAME                              NETWORK        DIRECTION  PRIORITY  ALLOW
matnet-allow-icmp-ssh-rdp	     matnet         INGRESS    1000      icmp,tcp:22,tcp:3389

Finally, we can create a new VM instance on the subnet and see that it’s working.

$ gcloud compute instances create matnet-home-vm \
	> --zone=us-west2-b \
	> --machine-type=f1-micro \
	> --subnet=matnet-subnet-us-west

NAME              ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
matnet-home-vm    us-west2-b     f1-micro                   172.24.0.2   34.66.197.202  RUNNING

We can see that the VM spun up correctly and that its internal IP address is correctly within the subnet IP address range we specified. The external address is an ephemeral address as discussed earlier. That all looks great to me!

In my next post, I’ll look at some common cloud network designs.