Got it

Google Cloud Platform (GCP) Networking Fundamentals

Latest reply: May 28, 2022 14:29:17 805 32 15 4 0

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:


  • 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.


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.


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:


Resolution of this name is handled by an internal metadata server that acts as a DNS resolver (, 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.

  • x
  • convention:

Created Jan 21, 2022 15:35:16

Very useful post
View more
  • x
  • convention:

Saqibaz Created Feb 19, 2022 03:27:27 (0) (0)
Thanks for liking  
Created Jan 22, 2022 05:30:51

Thanks for sharing knowledge
View more
  • x
  • convention:

Saqibaz Created Feb 19, 2022 03:27:22 (0) (0)
Thanks for liking  
Created Jan 22, 2022 07:41:35

Thanks for sharing!
View more
  • x
  • convention:

Saqibaz Created Feb 19, 2022 03:27:17 (0) (0)
Thanks for liking  
MVE Author Created Jan 22, 2022 07:43:22

Google Cloud Platform (GCP) Networking Fundamentals-4620197-1
View more
  • x
  • convention:

Saqibaz Created Jan 22, 2022 08:17:19 (0) (0)
Created Jan 23, 2022 18:59:02

Thanks for sharing
View more
  • x
  • convention:

Saqibaz Created Feb 1, 2022 17:42:45 (0) (0)
Thank You for the Feedback !  
MVE Author Created Feb 1, 2022 12:33:59

Well done! Very useful
View more
  • x
  • convention:

Saqibaz Created Feb 1, 2022 17:42:36 (0) (0)
Thank You for the Feedback !  
Created Feb 2, 2022 23:00:49

View more
  • x
  • convention:

Saqibaz Created Mar 2, 2022 05:37:04 (0) (0)
Thank you for taking the time to review this post.  
Created Feb 3, 2022 02:24:42

Interesting to know if one needs to deal with GCP.
View more
  • x
  • convention:

safarasa Created Feb 16, 2022 15:49:35 (0) (0)
Thank You for the Feedback !  
Moderator Author Created Feb 16, 2022 04:58:48

thankyou for
sharing such a complete detail of every aspects of topic...
View more
  • x
  • convention:

Saqibaz Created Feb 16, 2022 15:51:09 (0) (0)
Thank You for the Feedback !  
Back to list


You need to log in to comment to the post Login | Register

Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " User Agreement."

My Followers

Login and enjoy all the member benefits


Are you sure to block this user?
Users on your blacklist cannot comment on your post,cannot mention you, cannot send you private messages.
Please bind your phone number to obtain invitation bonus.
Information Protection Guide
Thanks for using Huawei Enterprise Support Community! We will help you learn how we collect, use, store and share your personal information and the rights you have in accordance with Privacy Policy and User Agreement.