Innovative Software Technology-Mastering VPC Network Peering in Google Cloud: A Step-by-Step Guide to Secure Internal Communication

Connecting isolated Virtual Private Cloud (VPC) networks securely is a common requirement in cloud projects, enabling resources within them to communicate privately using internal IP addresses, without any exposure to the public internet. This critical functionality is precisely what VPC Network Peering delivers. It facilitates low-latency, private, and secure communication pathways between distinct VPCs, all while maintaining their administrative separation.

This guide will walk you through a practical demonstration of setting up two independent VPCs, deploying virtual machine (VM) instances within them, and then configuring VPC Peering to establish secure internal communication.

Understanding the Journey: What We’ll Accomplish

Our step-by-step journey will involve:

Establishing Two VPCs: Creating vpc1 and vpc2, each with custom network configurations.
Defining Subnets: Setting up vpc1subnet and vpc2subnet within their respective VPCs.
Launching VMs: Deploying vpc1-vm and vpc2-vm into these subnets.
Initial Connectivity Check: Observing the lack of communication between VMs before peering.
Implementing VPC Peering: Configuring the peering connection between vpc1 and vpc2.
Verifying Enhanced Connectivity: Confirming successful communication after peering is active.

Step 01: Laying the Foundation – Creating Our VPCs and Subnets

We begin by setting up two distinct VPC networks, vpc1 and vpc2, each with its own subnet.

VPC1 and Subnet Configuration

VPC Name: vpc1
Mode: Custom (allowing us to define specific subnets)
Essential Firewall Rules: allow-ssh, allow-icmp, allow-custom (to permit SSH access, ping requests, and other custom traffic within the network)
Routing: Default (Global)
Subnet Name: vpc1subnet
Region: us-central1
IP Range (CIDR): 10.1.0.0/16

VPC2 and Subnet Configuration

VPC Name: vpc2
Mode: Custom
Essential Firewall Rules: allow-ssh, allow-icmp, allow-custom
Routing: Default (Global)
Subnet Name: vpc2subnet
Region: us-central1
IP Range (CIDR): 10.8.0.0/16

These configurations ensure that, by default, vpc1 and vpc2 are entirely isolated from each other, preventing any direct internal communication.

Step 02: Populating Our Networks with VM Instances

Next, we’ll deploy a virtual machine into each of our newly created subnets. These VMs will be our test subjects for verifying connectivity.

Make sure your Google Cloud project is correctly set. Replace gcpdemos with your project ID.

# Set Project
gcloud config set project gcpdemos

# VM in vpc1subnet
gcloud compute instances create vpc1-vm \
    --zone=us-central1-a \
    --machine-type=e2-micro \
    --network-interface=subnet=vpc1subnet

# VM in vpc2subnet
gcloud compute instances create vpc2-vm \
    --zone=us-central1-a \
    --machine-type=e2-micro \
    --network-interface=subnet=vpc2subnet

The above commands will create:

vpc1-vm: An e2-micro VM in the us-central1-a zone, connected to vpc1subnet.
vpc2-vm: Another e2-micro VM in the us-central1-a zone, connected to vpc2subnet.

Step 03: Initial Connectivity Test – Expecting Failure

Before configuring VPC Peering, it’s crucial to confirm that our VMs, residing in separate VPCs, cannot communicate. This step highlights the default isolation.

# Connect to vpc1-vm
gcloud compute ssh vpc1-vm --zone=us-central1-a --project=gcpdemos

# Try ping vpc2-vm internal IP
ping <vpc2-vm-internal-ip>
# ❌ Should FAIL

# Connect to vpc2-vm
gcloud compute ssh vpc2-vm --zone=us-central1-a --project=gcpdemos

# Try ping vpc1-vm internal IP
ping <vpc1-vm-internal-ip>
# ❌ Should FAIL

When you attempt to ping the internal IP of vpc2-vm from vpc1-vm, or vice-versa, the requests will fail. This is the expected behavior, demonstrating the inherent isolation between the two VPCs.

Step 04: Unleashing Communication – Configuring VPC Peering

Now, let’s establish the peering connection to enable secure, private communication between vpc1 and vpc2. This involves creating two peering connections, one initiated from each VPC to its peer.

Peering from VPC1 to VPC2

Navigate to VPC Network > VPC network peering in your Google Cloud console.
Click CREATE PEERING CONNECTION.
Name: vpc1-to-vpc2-peering
Your VPC network: Select vpc1.
Peer project ID: Enter your project ID (e.g., gcpdemos).
Peer VPC network: Select vpc2.
Ensure Enable import/export custom route advertisements is selected to allow subnet routes to be exchanged.

Peering from VPC2 to VPC1

Repeat the process, creating another peering connection.
Name: vpc2-to-vpc1-peering
Your VPC network: Select vpc2.
Peer project ID: Enter your project ID.
Peer VPC network: Select vpc1.
Enable Enable import/export custom route advertisements.

Once both connections are created, Google Cloud automatically establishes the peering, and the status will transition to ACTIVE.

Step 05: Verifying VPC Peering Connection Status

To confirm that the peering is successfully established:

Go to VPC Network > VPC network peering in your Google Cloud console.
Observe the status of both vpc1-to-vpc2-peering and vpc2-to-vpc1-peering. Both should display an ACTIVE status, indicated by a green checkmark (✅).

An active status signifies that the private connection between the two VPCs is now operational.

Step 06: Final Connectivity Test – Witnessing Success!

With VPC Peering in place, we should now be able to ping our VMs across the VPC boundaries using their internal IP addresses.

# From vpc1-vm → vpc2-vm
gcloud compute ssh vpc1-vm --zone=us-central1-a --project=gcpdemos
ping <vpc2-vm-internal-ip>
# ✅ Should PASS

# From vpc2-vm → vpc1-vm
gcloud compute ssh vpc2-vm --zone=us-central1-a --project=gcpdemos
ping <vpc1-vm-internal-ip>
# ✅ Should PASS

You will now find that pinging vpc2-vm from vpc1-vm, and vpc1-vm from vpc2-vm, will be successful. This confirms that VPC Network Peering has enabled seamless, private communication between the resources in our previously isolated networks.

Step 07: Post-Demonstration Cleanup

To avoid incurring unnecessary costs, remember to clean up all the resources created during this demonstration:

Delete both VM instances (vpc1-vm and vpc2-vm).
Remove the VPC Peering connections (vpc1-to-vpc2-peering and vpc2-to-vpc1-peering).
Delete the two VPC networks (vpc1 and vpc2) and their associated subnets.

Summary: The Power of VPC Network Peering

This exercise vividly demonstrates the capabilities of VPC Network Peering:

Before Peering: VMs in distinct VPCs are inherently isolated and cannot communicate via internal IPs.
After Peering: Private, low-latency connectivity is established, enabling secure communication over internal IP addresses as if they were part of the same network.

Key Use Cases for VPC Peering:

Multi-project Architectures: Ideal for organizations managing different aspects of an application in separate Google Cloud projects.
SaaS Provider Services: Enables Software-as-a-Service (SaaS) providers to offer their services securely to customer VPCs without exposing them to the internet.
Connecting Development/Testing with Shared Services: Facilitates linking development and testing environments with centralized services (like logging, monitoring, or databases) in a shared services VPC.

With just a few straightforward steps, you can harness the power of VPC Network Peering in Google Cloud to create robust, secure, and privately interconnected cloud environments.