Hands-on VPC Peering Configuration on GCP


When it comes to talk about GCP networking, we must know what Virtual Private Cloud (VPC) is. According to GCP document, a Virtual Private Cloud (VPC) network is a virtual version of a physical network, such as a data center network. It provides connectivity for your Compute Engine virtual machine (VM) instancesGoogle Kubernetes Engine (GKE) clustersApp Engine flexible environment instances, and other resources in your project. GCP has an amazing video talking about VPC and all of you are really recommended to watch. From my point of view, VPC is nothing but just a “landing”. Our VM servers are just like a “building”. What we have to do is to plan which area should place which buildings. For example, we could classify our “area” by function. We could group our application servers into one VPC network, web servers into another one VPC network and database servers into another one VPC network. Of course, you could have your own design, it depends on your needs. For best practices, please take a look on this Google document. In fact, similar VPC service also appears on AWS and Azure those popular public cloud.

VPC Network Peering

In real situation, the networking is quite complicated especially in some big compines. For instance, one big company could own a few small companies. Then they may have different subnets and communicate with each others through internal IP. First of all, you may say you could still access the instances through external IP because Google Cloud will assign a external IP address to each instance. Actually, accessing instances through external IP is not secure. Secondly, You may also have a question that do we need many routers to control our traffic between different subnets? The answer is no if we use VPC network peering. So, what is VPC network peering? According to Google, VPC Network Peering enables you to peer VPC networks so that workloads in different VPC networks can communicate in private RFC 1918 space. Traffic stays within Google’s network and doesn’t traverse the public internet. I am a practical guy and don’t want to talk too much, let’s experience it.

Solution Diagram

Generally speaking, we just have a few steps to configure the above solution:

  1. Create network-1 and network-2
  2. Create subnet-a and subnet-b
  3. Ensure the firewall allows access to the network-1 and network-2
  4. Create instance on the subnet-a and subnet-b respectively
  5. Configure VPC peering for both sides
  6. Test it.


In console, we choose Cloud Shell and then click the editor mode such that we could easily review our code.

The we have to setup our environment e.g. define project, zone and region:

gcloud config set project <you-project-id>
gcloud config set compute/zone us-central1-a
gcloud config set compute/region us-central1

Please download my prepared file from github or

git clone https://github.com/manbobo2002/gcp-vpc.git
cd ~/gcp-vpc

Create Network, Subnet, Firewall rules and Instances

Instead of implementing the solution on console, I just create a script to build up all the things by typing:

sh startup.sh

Then, all the required infrastructure are done. If you see my recent articles, you may observe that I love to create some scripts to implement the solution. The reason is that it will reduce the mistakes caused by manual operations. Also, it is a good practice to automate some tasks. Of course, I will still explain the script step by step.

Create network and subnet

First of all, we create the network-1 and subnet-a with IP range and region us-east1. For some of you may not be familiar with IP, “/8” means we take the first 8 bits as our subnet mask. In short, the IP range will fall from to Also, we create the network-2 and subnet-b with IP range and region asia-east1. That means the IP range will fall from to Please note that we CANNOT overlap our IP ranges in different subnets. It makes sense because when we plan our landing, we should not put our “building” to an area which overlaps another “building”.

Secondly, we create a firewall rule that allows ssh (tcp:22), remote desktop (tcp:3389) and ping (icmp) from any source.

Thirdly, we create an instance on the subnet-a and subnet-b respectively. Since this is a demonstration only, we use the cheapest machine type f1-micro. Now the environment is ready. But we still do not set VPC peering, just see the result now.

Connectivity Test before configuring VPC peering

We firstly go to the Compute Engine and SSH to the vm-network-1 instance. Then we ping the external and internal IP of vm-network-2.

ping -c 5 <external_ip_of_vm-network-2>
ping -c 5 <internal_ip_of_vm-network-2>

As we expect, vm-network-1 could only ping the external IP.

Let’s do the same thing with vm-network-2.

ping -c 5 <external_ip_of_vm-network-1>
ping -c 5 <internal_ip_of_vm-network-1>

Same result in vm-network-2. Now, let’s configure the VPC peering.

Configure VPC Peering

Similarly, I have prepared a script to automate the setup process. Back to Cloud Shell and type:

sh vpc-peering.sh

What we have done is to create a VPC network peering on both sides. It is important because if we only create one side, then the traffic could be allowed only one direction. Then test it again.

Connectivity Test after configuring VPC peering

We back to the Compute Engine and SSH the instance again.

ping -c 5 <external_ip_of_vm-network-2>
ping -c 5 <internal_ip_of_vm-network-2>

Now we successfully connect vm-network-2 through private IP. Then we do the same things on vm-network-2

ping -c 5 <external_ip_of_vm-network-1>
ping -c 5 <internal_ip_of_vm-network-1>

Same result to connect vm-network-1 through private IP.

Clean Up

If you want to clean up everything, you just have to run the cleanup script on Cloud Shell:

sh cleanup.sh

All the things we created in this tutorial are deleted.

In most cases, we just have to replace “create” by “delete” if we want to delete something. The flag -q means “quiet”, it will not ask you “yes or no” and run the default setting when you add this flag.


To conclude, VPC let us communicate with different subnet through private IP. According to Google, VPC also has the below benefits:

  • Network Latency: Public IP networking suffers higher latency than private networking. All peering traffic stays within Google’s network.
  • Network Security: Service owners do not need to have their services exposed to the public Internet and deal with its associated risks.
  • Network Cost: Google Cloud charges egress bandwidth pricing for networks using external IPs to communicate even if the traffic is within the same zone. If however, the networks are peered they can use internal IPs to communicate and save on those egress costs. Regular network pricing still applies to all traffic.

Enjoy VPC!

Leave a Reply