Google Cloud Platform (GCP) Networking Fundamentals
If your organization or customers haven’t yet migrated to the cloud, don’t think it won’t happen, because it very likely will.
If you’re a network engineer, system admin, or anyone that is supporting infrastructure in the cloud, it’s in in your best interest to understand how it differs from your traditional on-premises data center environments – networking included.
If you’ve worked with Amazon Web Services (AWS) or Microsoft Azure, you’ll feel quite at home with GCP, which shares much of the same concepts and capabilities.
However, there are a few key differences between each provider that you should be aware of if migrating or mobilizing workloads between them.
GCP Components & Fundamentals include:
In this article, we’ll be going over some of the networking basics of GCP for 2022, including:
VPCs
Projects
Networks
Regions
Zones
Subnets
Switching
Routing
Firewalls
Essentially, we’ll be going over this diagram:
Google’s Global Cloud Network
Google is global, meaning as a customer of GCP you can be global too. As of this writing, GCP has 11 regions, 33 zones and over 100 points of presence throughout the globe.
Regions and Zones
When architecting your apps in GCP, it’s important to understand regions and zones, as well as the resources that are regional or zonal.
A region is a specific geographical location that is sub-divided into zones. For example, in the Americas, you have four regions, and each of these regions is broken down into multiple zones:
Americas:
Region: us-central1
Zone: us-central1-a
Zone: us-central1-b
Zone: us-central1-c
Zone: us-central1-f
Region: us-west1
Zone: us-west1-a
Zone: us-west1-b
Zone: us-west1-c
Region: us-east4
Zone: us-east4-a
Zone: us-east4-b
Zone: us-east4-c
Region: us-east1
Zone: us-east1-b
Zone: us-east1-c
Zone: us-east1-d
This diagram shows the (current) regions and zones in GCP:
While some of the core resources in GCP are global, others may be restricted by region or zone. Regional resources can be used anywhere within the same region, while zonal resources can be used anywhere within the same zone. Some examples of this are:
Global Resources:
Images
Snapshots
VPC Network
Firewalls
Routes
Regional Resources:
Static external IP addresses
Subnets
Zonal Resources:
Instances (VMs)
Persistent Disks
For example, I can attach a disk from one instance to another within the same zone, but I cannot do this across zones. However, since images and snapshots are Global Resources, I can use these across zones in the same region.
Why use Regions and Zones?
When building an application for high availability and fault tolerance, it’s crucial to distribute your resources across multiple zones and regions.
Zones are independent of each other, with separate physical infrastructure, networking, and isolated control planes that ensure typical failure events only affect that zone. Therefore, you should have your application distributed across zones, to handle the failure of any particular zone. The same applies to regional issues.
Another design consideration is speed and latency. Zones have high-bandwidth, low-latency connections to other zones in the same region. Moreover, if most user traffic will be initiated from certain parts of the globe, it’s best to design for regions and zones closest to that point of service.
Virtual Private Cloud (VPC)
Verbatim from Google’s documentation:
“A Virtual Private Cloud (VPC) is a global private isolated virtual network partition that provides managed networking functionality for your Google Cloud Platform (GCP) resources.”
You can think of a VPC as a virtual version of your traditional physical network. VPCs are global, spanning all regions. The instances within the VPC have internal IP addresses and can communicate privately with each other across the globe. This logical representation of your network infrastructure abstracts much of the complexities of dealing with on-premises architectures.
In this diagram, you can see the default VPC network spanning multiple regions and zones, and subnets within various parts of the network servicing VMs. All these subnets can natively route to each other, and as long as the firewalls permit it, VMs can reach one another within this VPC.
GCP Projects
Before going further, I just want to briefly mention projects within GCP. Before you can do anything, you must create a project. A project is really an organizational construct used for billing and permissions. Some organizations use projects for various apps or various environments like Prod/Test/Dev; some use it for departments like Finance/HR/Marketing etc.; some use it to provide billing to customers based on their usage within a cloud-hosted environment. The important part to understand is that it’s simply a way to organize resources from a billing and permissions perspective, and each project has its own VPC network(s) isolated from other projects in GCP.
VPC Networks and Subnets
When you create your first project in GCP, you’ll have the option to automatically create your VPC network or custom build it. Assuming you choose auto mode – a default network with a series of default subnets will be deployed ready for immediate use. VM instances can be deployed on the default subnets without any network configuration.
Don’t confuse “VPC network” with something related to IP addresses. Instead, relate “VPC network” to that of a network topology or if you have a networking background – VRF.
Each network has its own subnets, routes, firewall, internal DNS, and more beyond the basics listed here.
GCP Project
VPC Network
Subnets
Routes
Firewall
Internal DNS
Screenshot from GCP console showing default network and a default subnet in each region:
Note in the screenshot that the VPC network called default is global, while each of the subnets within it is regional. When you create an instance, you’ll place it in a subnet. Instances in this subnet can be in any zone within the region it’s assigned to. Even though subnets are regional, instances can communicate with other instances in the same VPC network using their private IP addresses. Of course, you can isolate these subnets within the network if you wish using firewall policies.
If you want complete isolation between various applications, customers, etc., you could create multiple networks.
You can have up to five networks per project, including the default network. Multiple networks within a single project can provide multi-tenancy, IP overlap, or isolation within the project itself. Just another option instead of having multiple projects.
IP Addresses
Each VM instance in GCP will have an internal IP address and typically an external IP address. The internal IP address is used to communicate between instances in the same VPC network, while the external IP address is used to communicate with instances in other networks or the Internet. These IP addresses are ephemeral by default but can be statically assigned.
Internal IPs are allocated to instances from the subnet’s IP range via DHCP. This means the IPs are ephemeral and will be released if the instance is deleted.
External IPs are also assigned via DHCP from some Google-provided pool. These IPs are mapped to the internal IPs of the VM instances for you. You can reserve static IP addresses if needed.
Regarding Static External IP Addresses, they can be either global or regional depending on your requirements. For example, global static IP addresses are available for global forwarding rules used for global load balancing.
Routes
GCP is a global software-defined network with layers of controllers and impressive routing capabilities that have been mostly abstracted for the end-user. All networks have routes to communicate with each other. The default network has a default route to the internet and individual routes to each subnet. Here’s a screenshot from the console:
Routes are considered a “network resource” and cannot be shared between projects or networks. Tables are used to tell which routes and rules apply to each VM instance. Routes could apply to multiple instances or single instances depending on the tags used in the route statement. If an instance tag is used, the route applies to that instance, and if an instance tag is not used, then the route applies to all instances in that network. Individual read-only route tables are created for each VM instance based off the parent route table.
The picture below from Google documentation helps visualize the concept of these route tables. Even though there are no “routers” in the software-defined network, you can still think of each VM instance as connected to some core router, with all traffic passing through it based on the perspective of each node’s individual route table.
Routing decisions apply to traffic egressing a VM. The most specific route in the table will match. Traffic must match a route and firewall rule for it to pass.
You can add custom static routes or setup BGP for dynamic routing between clouds or on-premises environments.
Firewalls
Each VPC network has its own distributed firewall, which allows or denies traffic into and out of the network, and between VM instances. The firewall has an explicit-deny policy, meaning that any traffic that needs to be permitted must have a rule created. You cannot create “deny” rules, only “allow” rules.
If you have a concept in your mind that all this traffic is flowing through some single firewall chokepoint device somewhere, you’re mistaken. GCP is a full SDN, with firewall policies applied at the instance-level, no matter where it resides. These checks are performed immediately without having to funnel traffic through dedicated security appliances.
DNS Resolution
Another great thing about GCP is the way it handles DNS. When a VM instance is created, DNS entries are automatically created resolving to a formatted hostname.
FQDN = <pre>[hostname].c.[project-id].internal</pre>
So, if I had an instance named “porcupine” in my project called “tree”, my DNS FQDN would be:
porcupine.c.tree.internal
Resolution of this name is handled by an internal metadata server that acts as a DNS resolver (169.254.169.254), provided as a part of Google Compute Engine (GCE). This resolver will answer both internal queries and external DNS queries using Google’s public DNS servers.
If an instance or service needs to be accessed publicly by FQDN, a public-facing DNS record will need to exist pointing to the external IP address of the instance or service. This can be done by publishing public DNS records. You have the option of using some external DNS service outside of GCP or using Google Cloud DNS.
