Now, let's make things a little more interesting and add a second VPC. This one I'm going to call demovpc-2, and then, I need to add a subnet. Subnet-3 is going to use 10.3.0.0/16. And I need to make sure to enable both the SSH and ICMP rules, and then, I'll fast forward until the VPC is created. Now, I have two VPCs, demovpc-2 only currently has a single subnet but let me show you how to add more. To do that, click on the 'VPC' and then, click on 'Add subnet'. I'll create subnet-4 and I'll set it to 10.4. Notice that it will automatically add routes for all of your subnets. Also notice that your VPC firewall rules apply to all subnets, not just the ones you created initially. I need to add a couple of VMs to subnet-3 and 4.

Let me quickly do that. And now, let me test that they're responding on their public IPs. Okay. That works. So, we know that VMs in the same VPC can connect to each other using their internal IPs. But what about VMs that are in different VPCs? Well, let's give it a try. And you can see the answer is no. And that's because by default, there is no route defined between two VPCs. I can ping instance 4 from instance 3, but I cannot ping instance 4 from instance 1. Luckily, there's an easy way to enable this feature if you want. VPC network peering enables internal connectivity between two VPC networks. It even works for VPCs in different projects. So, this means you can link your team's VPC with another team's VPC. Let me show you how to set this up.

First, I need to create a peering from demovpc-1 to demovpc-2. So, my peering was created but notice the status says inactive and that's because it's waiting for me to create a peer connection in the other direction as well. I need to also peer from demovpc-2 to demovpc-1. Now, this might seem a little odd to you that I have to create it for both sides, but remember peering can happen across projects, so you need to set it up on both sides to work. This is because you don't want another team to enable peering to your VPC without your permission. Of course, if you control both VPCs, then the process just feels a little repetitive. Okay. Now, you can see that peering has been properly established. So, now I should be able to route traffic between demovpc-1 and demovpc-2. Let me again try to ping instance 4 from instance 1. And now, it works. So, generally, you want to split things up into separate VPCs for isolation.

But if you do need two VPCs to talk to each other, you now know how to do that using VPC peering. Now, there's going to be some times where you need to join more than just two VPCs. Let's say your company wants to share resources across many different teams and projects. Well, that's best accomplished by using a shared VPC. Now, a shared VPC is a VPC hosted in one project but it can be accessed and used by other projects. All you have to do is set a project as the host, define the subnets for the VPC, and then, set the permissions for who can access and edit your VPC. I'm not going to actually run through the whole process because we're running short on time. So, this should give you enough so that you understand the basics of how to build and manage your own private networks on GCP. To end this video, I'm going to go through and quickly clean up everything we just created. First, I need to delete all my VMs. Then, before I can delete my VPCs, I have to first remove the peering connections. Okay. Now that the peering is shut down, I can delete my VPCs. And there we go, I've cleaned everything up and my account looks the same as when we started.