From the course: Microsoft Azure Administrator (AZ-104) Cert Prep: 4 Configure and Manage Virtual Networking

Create and configure a VNet

A virtual network or VNet in Azure is a private network for your VMs. If you put several VMs in Azure, you may want them to be able to communicate with each other, and so Azure allows you to set up a private network and you can use private IP addresses. Each VNet has an IP address space. So all the VMs on the VNet have to come from that IP address space. Typically you use one of the non routable IP address spaces like 10.0. A VNet also has one or more subnets. So a subnet is just a logical subdivision of a VNet that allows you to further subdivide a VNet, a large VNet, into smaller pieces and as we'll see, it can play into network security as well. It's important to understand, too, that a VNet is scoped to a region. So when you create a VNet, you set it up in a region and that's where it lives. Here you see a picture of a virtual network on the right that has multiple subnets. So the production subnet has some VMs. We'll talk about these various components as this lesson unfolds. But you can use a VNet in Azure to talk to on-prem resources. You can use a VNet in Azure to even talk to other VNets. When you're setting up your VNets and subnets, it's a good idea to remember, in fact, it's a requirement, that an Azure VM has to be on the same -- in the same region where your VNet is. So if you have VMs in East U.S. , you will necessarily have a VNet in East U.S. If you also have VMs somewhere else, like in West U.S. , then you must have another VNet in West U.S. As I said previously, subnets are a logical subdivision of a VNet, so it's a good way to organize or group your VMs maybe by a type. You might want your web VMs to be on a particular subnet of your VNet so that you could control the security for those VMs differently than you would say database servers on a different subnet. VMs by default are assigned an IP address from the VNet address space when they boot up. So Azure keeps track of the address space that it hands out IP addresses that haven't been used. All VMs on a VNet can communicate with other VMs on the same VNet. So this private IP address space has IP connectivity. However, by default, VMs cannot communicate with VMs on a different VNet. We'll talk about the mechanism to turn that on, but by default, all the VMs in a VNet talk to each other, but not to VMs outside of that. Let me show you how to set up a VNet in the portal. So here I'm in the marketplace. I'm just going to search for a virtual network. Virtual network needs a resource group. I'm going to create a new one. I have one called west-rg, I'll use that because I want to make a VNet In West U.S. And I will call this -- Oh, I'll leave that. So IP address is next. We need a specified IP address range. The portal has already seen I have a 10.0 VNet so it's suggesting 10.1. Slash 16 means that there's 16 bits. The first 16 bits are net ID, so all the VMs on this VNet will start with 10.1. I need to have at least one subnet on a VNet, and you can see I have a default here. I'll just leave that. I'll leave these as well, some of these services we will discuss in later lessons. Review and create. VNets don't cost any money because they're really not any physical infrastructure. It's just some bookkeeping that Azure keeps track of for VMs that are going to be deployed. When it's finished, I'll show you the VNet. And it's done. So let's go to the resource. You can see my VNet has an address space specified, subnets are specified. No connected devices. So what would normally show up here would be in a VM network interfaces that were attached to this VNet. So VNetas are a necessary part of having VMs in Azure. If you have VMs, you'll have VNets. In fact, you'll have VNets where the VMs are. If you don't have VMs, you may not have VNets. You don't really need them for platform services.

Contents