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 2024, including:

• VPCs
• Projects
• Networks
• Regions
• Zones
• Subnets
• Switching
• Routing
• Firewalls

Essentially, we’ll be going over this diagram:

Google’s Global Cloud Network

Needless to say, 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 completely separate physical infrastructure, networking, and isolated control planes that ensure typical failure events only affect that zone. This is why 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 of 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 in order 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 of 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 in order 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.

Firewall rules can match IP addresses or ranges, but can also match tags.  Tags are user-defined strings that help organize firewall policies for standards-based policy approach. For example, you could have a tag called web-server, and have a firewall policy that says any VM with the tag web-server should have ports HTTP, HTTPS, and SSH opened.

Firewall rules are at the network resource level and are not shared between projects are other networks.

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.

Network Billing

I won’t go into too much detail here, but the gist is GCP bills clients for egress traffic only.  Egress traffic is considered as traffic to the Internet, or from one region to another (in the same network), or between zones within a region.

You are not billed for ingress traffic. Ingress traffic includes VM-to-VM traffic in a single zone (same region, network), and traffic to most GCP services.

Some notes on caveats/limitations

• VPC networks only support IPv4 unicast traffic (No IPv6, or broadcast/multicast)
• Maximum of 7000 VM instances per VPC network

Get started with GCP

Sign up for a free GCP account to play around with some of these features!

Google Cloud Platform FAQs