Hello and welcome to VPC network peering. In this lesson, I will provide you with an overview of what VPC network peering is and what it offers.

At its core, VPC network peering offers the ability for resources to communicate across two different VPC networks using internal IP addresses, whether or not they belong to the same project, or even to the same organization. Using VPC network peering allows you to connect VPC networks so that such resources can communicate internally without sending traffic over the public Internet. Instead, the traffic stays within the Google network.

Organizations will often use VPC network peering when deploying software-as-a-service ecosystems on the Google cloud platform. In such cases, the services can be made available privately across different VPC networks.

Leveraging VPC network peering instead of using external IP addresses or VPNs to connect networks allows you to reduce network latency, improve network security, and reduce network costs. Reduced latency is achieved because communications occur over internal addresses only. This almost always offers lower latency than using external addresses. Since VPC network peering allows communication to remain internal to the Google network, security is improved because the traffic is never exposed to the public Internet. Network cost savings are achieved due to the use of internal only IP addresses because there are no egress bandwidth charges incurred.

You can use VPC network peering with compute engine, GKE, and with app engine flexible environment. Because peered VPC networks are administratively separate, things like firewalls, VPNs, routes, and other traffic management tools are managed separately in each VPC network.

When you set up VPC network peering, you need to set up each side of the peering Association separately. Only after you’ve completed the peering configuration on both sides of the peering, will the peering become active.

While it’s possible for a specific VPC network to peer with multiple other VPC networks, there is a maximum limit of 25 connections to a single VPC network. This means you cannot connect any more than 25 different VPC networks to a specific VPC network through VPC network peering. There is also a limit on the number of primary and secondary subnet IP ranges that can be assigned to subnets in all networks of a specific peering group. This limit is 400.

Another key limitation you should be aware of is the maximum number of VM’s in a peering group. This maximum number of VM instances that are allowed in a peering group is 15,500.

In my opinion, the most important limitation to be aware of is the fact that only directly peered networks can communicate with each other. There is no transitive peering, which means if Network A and Network C are both peered to Network B, Networks A and C will not be able to communicate over peering. You’d have to directly peer A and C if you want them to communicate with one another.

There are also several other VPC peering limits to be aware of. For a complete list, visit the URL that you see on your screen:

https://cloud.google.com/vpc/docs/quota#vpc-peering

When peering VPC networks, there are some behaviors to keep in mind - depending on the implementation. 

Whenever you attempt to peer two VPC networks, Google Cloud will check to see if there are any overlapping subnet ranges between the two networks being peered. If Google Cloud identifies any overlaps, the peering fails. This is because overlapping ranges prevent full-mesh connectivity due to inherent routing issues that would be caused.

The image on your screen is an example of peering with overlapped ranges.

So, what happens when overlapping occurs when you create new subnets in a VPC network or expand subnets in a VPC network?

Well, Google Cloud does the same check. It will confirm that the new subnet range does not overlap with any subnets within the same VPC network or with any subnets in directly peered VPC networks. If Google Cloud detects an overlapped subnet range, the creation or expansion fails.

I should also mention that Google Cloud will also ensure that no overlapping subnet ranges are allowed across VPC networks that share a common network peer. 

The example on your screen is an example of this.

Notice that N1 and N3 share a common peer – which is N2. In this example, we see Subnet-5 being created in N3. Since the range for Subnet-5 overlaps the range of Subnet-1 in N1, which is an indirect peer, the subnet creation of Subnet-5 would fail. This is something that often trips up even experienced IT professionals – so keep it in mind. Overlapping ranges equals bad.

While you can peer virtual networks, you cannot peer virtual networks with on-prem physical networks. Instead, if you need to connect a physical on-prem network to a VPC network, you can use Cloud VPN or Cloud Interconnect. I mentioned these earlier in the course.

Cloud VPN allows you to connect VPC networks on Google Cloud Platform to physical on-prem networks and to virtual networks on other cloud platforms, like AWS and Azure. You would use Cloud Interconnect to leverage a high-speed physical connection to connect a VPC network to a physical on-prem network.

Speaking of on-prem networks, I should point out that a VPC network is often used as a “transit network”. And what I mean by that is this… 

Let’s say, for example, you have an existing VPN connection between your physical on-prem network and a VPC network in Google Cloud. What happens if you need to establish connectivity between the on-prem network and several other VPC networks? Do you really want to create a separate VPN connection for every VPC network you need to connect to? Of course not.

In situations like this, where you need to share a VPN connection with other VPC networks, you can peer your other VPC networks with the one that has the VPN connected. This turns the VPN-connected network into a “transit network”. It’s called a transit network because the other, peered networks can transit it to communicate with the physical on-prem network.

The image on your screen demonstrates how this works. Notice the VPN-B connection that connects Network-B in Google Cloud to the on-prem network. Once I peer Network-A and Network-C with Network-B, both A and C will also be able to communicate with the on-prem network over the VPN connection. Keep in mind, however, that the transitive peering rules still apply to Network-A and Network-C, meaning that, while Network-A can communicate with the on-prem network and with Network-B, Network-A will not be able to communicate with Network-C, since there is no peering established between A and C. The same goes for communication from C to A.  

Join me in the next lesson, where I’ll show you how to configure VPC network peering.