VPC network peering allows private connectivity across two VPCs while keeping them administratively separated. Peered VPCs can either be in the same or different projects; they may even belong to different organizations. As opposed to a Shared VPC, managing VPC peering is decentralized. Network and security admins at both ends manage their routing and firewall tables without having access to a peer VPC.
VPC peering provides several advantages. First, it prevents VPC traffic from being exposed to the internet, resulting in increased security and reduced latency. It also offers cost savings compared to using public IP addresses for communication.
To configure VPC peering, you can use a predefined Compute Network Admin role. In the VPC network menu, there is a section for VPC network peering, as shown in Figure 9.13.
This is where a peering connection can be initiated. It’s important to note that when you create a peering, unique IP ranges for subnets in both VPCs are required for the connection to be successfully established. A reminder of this requirement is given during the process:
Figure 9.13 – Creating a peering connection between two VPCs
To establish a peering connection, you must indicate the VPC in your project that will be used for peering and the location of the destination VPC. Peering can occur within the same project or a different one. Figure 9.14 is a follow-up to the peering connection setup depicted in Figure 9.13, where you can choose the network you wish to peer.
When the peering is ready, it will be in an inactive state because a peering needs to be configured at both ends. This means that once one side is done, a network administrator that manages the other side will have to go through similar steps for both ends to communicate. Either side can also remove the peering to stop communication.
Note that VPC peering is not transitive, and only directly peered VPCs can communicate. So, for example, if we have three VPCs called VPC-A, VPC-B, and VPC-C, and if VPC-A peers with VPC-B, and VPC-B peers with VPC-C, VPC-A won’t be able to communicate with VPC-C.
Figure 9.14 – Creating a peering connection between two VPCs in the same project
The following screenshot presents how routes are exchanged between VPCs. Take a look at the my-vpc-peering details of the local-vpc network. The local-vpc network peers with global-vpc. Both belong to the same project. On the right is a global-vpc view that lists subnets in this VPC. The peering connection details for my-vpc-peering on the left list all the routes imported from global-vpc. You can see that the subnets match those from the global-vpc subnet view. When a VPC peering finalizes, both sides exchange information about their local subnets so that the opposite side can use this information and route traffic toward these subnets:
Figure 9.15 – Creating a Compute Engine VM with an interface in a shared subnet
VPC peers export all their subnet routes. There is no option to advertise routes selectively. If a VPC also has custom routes (such as a route to an on-premises subnet via a VPN tunnel or a static route), you can import/export such static and dynamic routes via a VPC peering connection. Similar to subnet routes, you can’t select individual custom routes.
The following screenshot presents an example of a VPC peering between two VPCs under a single project. global-vpc has three subnets: in Warsaw (10.0.1.0/24) in europe-central2, in Sydney (10.0.2.0/24) in australia-southeast1, and in Vegas (10.0.3.0/24) in us-west4 region. There is also the custom route to the on-premises site in Zurich in the europe-west6 (10.99.99.0/24) region. local-vpc has one subnet in Zurich (172.16.0.0/24) in the europe-west6 region. When local-vpc peers with global-vpc, it exports its route, 172.16.0.0/24, and imports routes from global-vpc: 10.0.1.0/24, 10.0.2.0/24, and 10.0.3.0/24. Also, because importing custom routes is enabled, it receives a route to the on-premises site: 10.99.99.0/24. A Compute Engine VM located in Zurich in the europe-west6 region can communicate with VMs in the global-vpc region and on-premises subnet, assuming firewall rules allow it.
Note that although we cannot select which subnet routes are imported/exported over peering, we can leverage firewall rules to control this traffic.
Figure 9.16 – Example of VPC peering between two VPCs
VPC peering and Shared VPC approach multi-project networking differently. Shared VPC is a centralized approach where network and security admins consolidate networking resources in a host project. Both host and service projects need to belong to the same organization. Shared VPC is often considered a concept that introduces less administrative work. But it cannot be used in scenarios where we want to connect two VPCs in the same project. Alternatively, VPC peering is a decentralized approach where administrators can only manage resources at their end. Connected VPCs can belong to the same project or a different one, even to a different organization.
Ultimately, the choice between Shared VPC and VPC peering will depend on your specific needs and goals for your network.
Now that we’ve explored how to establish a network connection between Google Cloud networks in different VPCs, let’s look at how Google Cloud networks can be linked with on-premises networks.