How to Configure Google Cloud VPC Peering for Cross-Project Networking

Connecting Cloud Environments Securely

In modern cloud architecture, you rarely run all your workloads in a single project. As your infrastructure scales, you might have one Google Cloud Platform (GCP) project for your production database, and a completely separate project for your analytics environment or microservices. If these two environments need to communicate, routing traffic over the public internet is incredibly insecure and incurs high egress data transfer costs. Google Cloud VPC Network Peering solves this problem. It allows internal IP addresses in two separate Virtual Private Cloud (VPC) networks to route traffic directly to each other as if they were on the exact same physical switch, utilizing Google’s private, ultra-low-latency fiber network.

Step 1: Understand the Requirements

Before initiating a VPC Peering connection, you must meet two critical requirements:

• No Subnet Overlap: The subnet IP ranges in VPC Network A cannot overlap with the subnet IP ranges in VPC Network B. For example, if both VPCs use the 10.0.0.0/24 subnet, peering will fail because the routers will not know where to send packets.
• Bidirectional Setup: VPC peering is not a one-way street. You must configure the peering connection in Network A pointing to Network B, and configure it in Network B pointing to Network A. The connection only becomes active when both sides are configured.

Step 2: Initiate Peering from Network A

Log into the Google Cloud Console and navigate to the project containing your first VPC network. Open the Cloud Shell (the terminal icon in the top right corner) and execute the following command to initiate the connection from Network A to Network B:

gcloud compute networks peerings create peer-a-to-b \
    --network=network-a \
    --peer-project=project-b-id \
    --peer-network=network-b

Note: Replace network-a with your local VPC name, project-b-id with the exact Project ID of the second project, and network-b with the name of the destination VPC.

Step 3: Accept Peering from Network B

At this stage, the peering connection in Network A is in an “INACTIVE” state because Network B has not accepted it. Switch your Cloud Shell context to the second project (or ask the administrator of Project B to run this command):

gcloud compute networks peerings create peer-b-to-a \
    --network=network-b \
    --peer-project=project-a-id \
    --peer-network=network-a

As soon as this second command executes successfully, Google Cloud will automatically synchronize the routing tables for both VPCs. The status of both peering connections will change to “ACTIVE”.

Step 4: Configure Firewall Rules for Ingress Traffic

A common mistake is assuming that active VPC Peering automatically allows all traffic. It does not. VPC Peering only creates the routes; your VPC firewalls still block incoming traffic by default. You must explicitly allow ingress traffic from the peered network.

To allow all internal traffic (TCP, UDP, ICMP) from Network A’s subnet (e.g., 10.1.0.0/16) to enter Network B, run this command in Project B:

gcloud compute firewall-rules create allow-peered-vpc-a \
    --network=network-b \
    --allow=tcp,udp,icmp \
    --source-ranges=10.1.0.0/16 \
    --description="Allow internal traffic from peered VPC A"

You must repeat this process in Project A, allowing the subnet range of Network B.

Step 5: Verify the Connection

To verify the peering is fully functional, SSH into a Compute Engine virtual machine in Network A and ping the internal private IP address of a virtual machine in Network B:

ping -c 4 10.2.0.5

If you receive replies, your VPC Peering is successfully established. Your cross-project infrastructure is now communicating securely over Google’s internal backbone without ever touching the public internet.