Hello and welcome to concepts and best practices. In this lesson, we are going to take a look at some key vNet concepts and best practices that you should follow when deploying vNets.

Azure virtual networks are the foundation upon which many or most other Azure resources are built. They allow resources like virtual machines to securely communicate with each other, with resources deployed to on-prem networks, and with the Internet. While a virtual network in Azure is quite similar to a physical network that you would see in on-prem data center, the virtual network offers additional benefits, including improved availability, scalability, and isolation.

There are four key terms or concepts that you must be familiar with before deploying an Azure virtual network. They include the address space, subnets, regions, and subscriptions.

Whenever you deploy a virtual network in Azure, you’ll be prompted to define an address space. The address space that you define must consist of public or private addresses that conform to RFC 1918. When you deploy resources and attach them to a virtual network in Azure, the private IP addresses that are assigned to them are pulled from the address space that you define. For example, if you were to provision a virtual network with an address space of 192.168.0.0/16, any resources that are connected to that virtual network would be assigned addresses from that range. Those devices would get addresses like 192.168.0.4, 192.168.0.5, and so on and so forth.

Just as they do in a physical network, subnets allow you to segment a specific virtual network into one or more different subnetworks, hence the name subnets. When you do this, what you are really doing is carving out a portion of the virtual network's address space and assigning it to each subnet that you create. Azure resources can then be deployed to each subnet as necessary. Segmenting a virtual network address space into different subnets allows you to more efficiently leverage your addressing in a way that matches your organization’s requirements. Subnets also allow you to better secure resources through the use of network security groups.

When you deploy a virtual network in Microsoft Azure, it is scoped to a single region or location. That being said, if you need to enable connectivity across different regions, you can connect multiple virtual networks from multiple different regions through virtual network peering, which we will talk about in more detail later on.

In addition to being scoped to a single region or location, each virtual network that you deploy is scoped to a specific subscription.

there are several best practices that you should keep in mind as you build out your virtual networks in Microsoft Azure.

First and foremost, when deploying a virtual network, you need to ensure that the address space that you define for that virtual network does not overlap with any other network ranges that your organization uses. A real-world example of this best practice would be a situation where you plan to deploy a virtual network that will be connected to your physical on-prem network over a site to site VPN. If your on-prem network consists of a 192.168.0.0/16 address space or subnet, you wouldn’t want your Azure virtual network to overlap that specific address space or subnet because such an overlap could cause routing issues.

Speaking of subnets, you should never create a subnet that encompasses the entire address space of the virtual network. In other words, if you deploy a virtual network with an address space of 192.168.0.0/16, you really should not be creating a subnet for that virtual network with an address range of 192.168.0.0/16. Instead, you should be planning ahead and leaving some of the address space available for future use. This means any subnets that are defined on that virtual network should only use a portion of the complete virtual network address space.

It’s also recommended that instead of defining numerous smaller virtual networks, you should define fewer larger virtual networks. By leveraging fewer large virtual networks rather than a bunch of little virtual networks, you can prevent or minimize management overhead.

And last but not least, you should be securing all virtual networks that you create with network security groups. By assigning network security groups to the subnets that have been defined for a virtual network, you can retain control over what traffic passes between those subnets.

For those who may not be familiar with network security groups, a network security group is an Azure resource that you use to filter network traffic to and from Azure resources that are attached to a virtual network. When you create a network security group, that security group contains security rules that you can define. These security rules are used to allow and deny inbound and outbound network traffic to and from your subnets and the resources that are attached to them.

For more information on network security groups, visit the URL that you see on your screen: https://docs.microsoft.com/en-us/azure/virtual-network/security-overview