Source: Google Cloud networking in depth: Simplify routing between your VPCs with VPC peering from Google Cloud
Editor’s note: Google Cloud networking products and services fall into five main pillars: ‘Connect,’ ‘Scale,’ ‘Secure,’ ‘Optimize,’ and ‘Modernize.’ At Google Cloud Next ‘19 we announced several additions to our networking portfolio, and heard from customers, prospects and partners who wanted to learn more about the technical aspects of these announcements. What follows is a deep dive into the Connect pillar, exploring the enhanced routing capabilities in Google Cloud VPC. Stay tuned in the coming weeks as we explore the Google Cloud networking pillars in depth.
Network routing is about creating reliable paths between multiple networks by exchanging IP address information, where a network is either remote behind some type of hybrid connectivity service or a Virtual Private Cloud (VPC) network.
Today, we thought we would share a little more insight into how to use a new VPC peering capability to help you improve your on-prem connectivity to Google Cloud Platform (GCP), share VPNs across multiple VPCs or accessing a third party appliance on a peered VPC.
In Google Cloud a VPC is global so VPC peering is not needed to communicate between regions. Still, organizations may want to separate their deployments in different VPCs for isolation purposes and in this case VPC peering is ideal to keep those entities connected. But until now, you could only exchange subnet routes with VPC peering. For example, if you learned a BGP dynamic route in one VPC via Cloud Router, it couldn’t be used or wasn’t visible from any of its peered VPCs.
At Google Cloud Next ’19, we announced that you can now exchange any type of routes between two peered VPC networks, including static routes, subnet routes and dynamic BGP routes. Let’s look at a couple of use cases where it might be useful.
Using a peered VPC service with static routes
Many applications or services are using static routes instead of subnets routes for connectivity. An example is using Equal Cost Multi-Path (ECMP) with static routes to load balance traffic to multiple third party appliances. Starting now, you can set up your VPC peering so that two VPCs exchange their static routes; this means that those appliances are available from another VPC. You can do this by configuring import/export policies on a VPC peering connection. By default only subnet routes are exchanged across peers.
In the following example, there are two VPC networks. VPC-A is peered with VPC-B. A static route is created on VPC-B. VPC-B exports that route to VPC-A which is importing it. It results in the static route being visible in VPC-A.
Better connectivity from an on-prem network
Imagine that you have two VPCs connected via VPC peering and you would like to reach both of them from an on-prem network with a single VPN. This is a very common use case as many managed services in GCP use VPC peering, including Cloud SQL. (Note: To better understand the existing types of services and connections in GCP, check out this Google Cloud Next ’19breakout session on how to privately access your Google Cloud or third-party managed services.)
Connecting those VPCs from an on-prem network means that you need the on-prem routes to be advertised to both VPCs. In the example below, VPC-A is connected to an on-prem network and to another VPC-B. On-prem routes are exported to VPC-B through VPC-A, resulting in the connectivity between the on-prem network and both VPCs.
You can use this functionality to share a single on-prem hybrid connection such as a VPN tunnel or an interconnect between multiple VPC networks, by creating a transit VPC.
What’s next for VPC connectivity
As enterprises migrate different types of workloads, public cloud providers’ networking topologies will become more complex. GCP routing solutions like VPC peering will continue to become more flexible with extensible policy filters to fine-tune your connectivity and security boundaries. In a way, VPC peering inherits many attributes of traditional routing protocols like BGP.
In short, we’re far from done. Click here to learn more about GCP cloud networking and reach us at firstname.lastname@example.org.