Simplify routing with VPC Peering

The Internet as we know it is made up of an expansive group of separate and autonomous networks, each with its own subnetworks and unique IP addresses. By using this framework, any server can connect with one another as if they were on the same network. Now networks can maintain security and isolation with enough flexibility to afford seamless communication. The same is true for a cloud network, with the ability to create your own web of subnetworks under a single global virtual private cloud.

As your cloud footprint grows, however, an inevitable problem persists — you begin to face a mountain of individual VPCs, and “VPC islanding” starts to happen. That is, as you start to enable more data-center regions to be used by your service, you start to get more complexity overhead to bootstrap, manage, and maintain these VPCs in each region (with no simple way of integration). Usually, the primary goal is to share resources between networks (for example, to build a hub and spoke network topology).

Traditionally, most corporations’ first approach would be to set up a slew of VPNs. This allows customers and employees to securely access cloud resources despite being on the public internet. That, however, will come with its own complexities and scalability limitations. To explain, many cloud providers’ infrastructure is made up of large data center complexes in geographical regions across the globe, with each region subdivided into zones for service redundancy. Connectivity between these regions, for the most part, happens over the public internet.

The benefit of this approach is that the internet provides ubiquitous connectivity. But, there are a number of downsides that come with this:

• First off, you’ll face unpredictable performance. Because deploying a VPN requires the use of public IP addresses, you have no control over jitter, delay, and packet loss in the public internet — oof — management complexity. An overhead of 10–15% on throughput may be reasonable from one network to another, but as you scale, it can drastically reduce the performance of your overall environment.
• You are also victim to suboptimal routes. The number of hops your traffic must traverse through the public internet is most likely not optimized for your business — you are at the mercy of network outages and carriers’ BGP policies.
• And let’s not forget about the security risks. The internet is where the good people are (aka your customers), but it’s also unfortunately where the bad people are. While you can encrypt your traffic in transit, you still run a risk when sending inter-region communications over the public internet.

As I explained in my previous post, all VPCs in Google Cloud are by default global. This means you no longer need to deploy a VPC for each region, nor set up VPNs between regions for cross-regional, private communication. Inherently, this allows you to build once and move on. However, this doesn’t work for every organization. Some structures require more fine grained control over VPC deployment, effectively needing to deploy different VPCs across each region for isolation purposes. For example, a company may need separate VPCs for subsidiaries, partners, or customers, yet would like to set up transit between VPCs for file sharing or access to a primary data repository.

So how do you connect your private cloud networks without losing hair over it?

VPC Peering

VPC Peering lets you have private connectivity across two VPC networks regardless of whether or not they belong to the same project or organization. Essentially, it lets you peer VPC networks so that workloads in different VPC networks can communicate, and traffic stays within Google’s network — without traversing the public internet.

This is useful in cases where you have SaaS ecosystems in GCP. You can make services available privately across different VPC networks within and across organizations, or in organizations with several network administrative domains. For example, you might have a VPC for the finance department, and another VPC for the accounting department. The finance department needs access to all resources that are in the accounting department, and the accounting department requires access to all resources in the finance department.

When you use VPC Peering, GCP creates a peering connection, which exchanges the subnet routes between the two peered networks. If firewall rules in each network permit communication, VM instances in one network can communicate with instances in the peered network through private IPs. Voila!

On-prem access

More than likely you’ll need to connect your on premise network to one of the cloud VPCs. In this case, you can either use Cloud VPN or Cloud Interconnect to securely connect your on-premises network to your VPC network. If you are exporting custom routes, your peered VPC networks can also connect to your on-premises network. On the on-premises side, you would need to create routes so that traffic going to your VPC networks is directed to the VPN tunnel (I’ll cover this more in my next post).

VPC Peering set up

Enough of me talking, let’s walk through peering set up:

1. Create 2 VPCs with 1 subnet and non-overlapping IP ranges. If you get a notice to enable the compute.googleapis.com API, select Yes.

gcloud compute networks create vpc1 --subnet-mode=custom
gcloud compute networks create vpc2 --subnet-mode=custom
gcloud compute networks subnets create subnet1 --network=vpc1 --range=10.0.0.0/24
gcloud compute networks subnets create subnet2 --network=vpc2 --range=10.8.0.0/24

2. Using the GCP Marketplace, deploy a Wordpress instance in vpc1 and a mySQL instance in vpc2 respectively.

Give each a name (wordpress-instance, mysql-instance). Add an admin email.

Leave all as default, but make sure to edit the zone to the same region your VPC is deployed in, and edit the Networking section to deploy in the respective VPC.

Take note of the mySQL username and password on the deployment page.

3. Now let’s create a peering connection from the wordpress vpc1 to the mySQL vpc2.

gcloud compute networks peerings create vpc-wordpress-mysql \
    --auto-create-routes \
    --network=vpc1 \
    --peer-network vpc2 

4. Do the same from the mySQL vpc2 to the Wordpress vpc1.

gcloud compute networks peerings create vpc-mysql-wordpress \
    --auto-create-routes \
    --network=vpc2 \
    --peer-network vpc1

Once complete you should see the state as ACTIVE.

On the VPC network peering console, you will also see a green checkmark on the VPC Peering console confirming the peering connection between vpc1 and vpc2 have been established.

5. Check the Routes page and you will see it has automatically created subnet routes between the two networks.

6. Now create firewall rules to allow traffic from the other internal network to each VPC. For security reasons, only allow traffic to specific ports, and from trusted source IP ranges.

gcloud compute firewall-rules create allow-ssh-wordpress --network vpc1 --allow tcp:22 --source-ranges 0.0.0.0/0
gcloud compute firewall-rules create allow-ssh-mysql --network vpc2 --allow tcp:22 --source-ranges 0.0.0.0/0
gcloud compute firewall-rules create allow-wordpress-mysql --network vpc2 --allow tcp:3306,icmp --source-ranges 10.0.0.0/24

7. Let’s test peering connection. On the Compute Engine instances page, copy the mySQL-instance-vm private IP address.

8. Now SSH into the Wordpress instance.

9. In the SSH terminal, enter the following command.

mysql -u root -h [MYSQL_PRIVATE_IP] -p

Enter the mySQL instance root password from the deployment page.

10. You should now have been able to log into the mySQL instance from the Wordpress instance and enter a SQL command such as:

SHOW DATABASES;

If you get back a result, you can confirm you’ve been able to establish a peering connection between the VPCs! The Wordpress instance can access the private IP of the mySQL instance via the peering routes created.

Tips for smooth sailing

To avoid hitting any bumps in the road, pay attention to the following:

• VPC Network Peering works with Compute Engine, GKE, and App Engine flexible environments.
• Peered VPC networks remain administratively separate. Routes, firewalls, VPNs, and other traffic management tools are administered and applied separately in each of the VPC networks.

No overlaps

One key thing to note is since VPC peering creates a full mesh connectivity between subnets, you can’t have overlapping IP ranges as this would cause routing issues. At the time of peering, GCP checks to see if there are any subnets with overlapping IP ranges between the two VPCs or any of their peered networks. If there is an overlap, peering is not established. The same applies when you expand an IP range in a peered network — if there are overlapping ranges, expansion will fail.

Ready, set, go

All in all, VPC Network Peering gives you several advantages over using external IP addresses or VPNs to connect networks, including:

• Network Latency: All peering traffic stays within Google’s network, reducing public IP latency.
• Network Security: Service owners don’t need to have their services exposed to the public internet and deal with its associated risks.
• Network Cost: GCP 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.

Now what?

1. Deep dive on VPC Peering here.
2. Subscribe to the GCP Youtube channel and follow my video series Networking End-to-End.
3. Check out Networking 102 where I discuss peering with Networking Specialist, Ryan Pryzbl.
4. Want more content? Follow me on Twitter @swongful.
5. And check out the Google’s Cloud events near you.

Stay tuned for more on this series and thanks for joining me on this wild ride to demystify cloud networking.