This chapter introduces Azure Virtual Networks, differences between the Azure Service Management and Azure Resource Manager models, and some key points that will help you to design your solution. We will also cover Azure Virtual Network subnet types and in which scenarios these subnets would be used. Finally, you will learn how to automate all the manual tasks that have been implemented throughout the chapter.

The following topics will be covered:

• Introduction to Microsoft Azure Networks
• Azure terminologies
• Azure Service Management (ASM) versus the Azure Resource Manager (ARM)
  model
• Azure Virtual Network (VNet)
• Automating your tasks

To go through the book smoothly, you need to have the following:

• An Azure subscription: You can sign up for a trial from the following link https://azure.microsoft.com/en-us/free/
• PowerShell: Make sure you have PowerShell V3, by running the following cmdlet to check the version $PSVersionTable.PSVersion
• Azure PowerShell module: You can download it from the following link https://www.microsoft.com/web/handlers/webpi.ashx/getinstaller/WindowsAzurePowershellGet.3f.3f.3fnew.appids
• Azure CLI 2.0: You can download it for your OS from the following links:
  • Windows: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-windows?view=azure-cli-latest
  • Linux: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-linux?view=azure-cli-latest
  • Mac: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-macos?view=azure-cli-latest

One of the major facts in our life is networking. In the beginning, human beings used to make networks communicate with each other to fulfill their needs. That's why when the computer revolution took place, networks were a very important piece of the puzzle to let computers communicate with each other.

Through the whole of the IT revolution, networks used to be an indispensable part of every IT environment to have a properly functioning environment. It is no surprise that networking is a vital part of cloud from many aspects, starting from the remote connection to your Azure VMs, to spanning your environment across on-premises and Azure. You will notice that networks are used with almost all Azure services, this includes, but is not limited to Azure VMs, Azure SQL Databases, Azure Web Apps, and so on.

At the time of writing, Microsoft Azure is generally available in 36 regions, with plans announced for six additional regions, as shown in the following table:

Due to an overlap of terms and some misperceptions about the ways that Azure services are delivered, terminology is a sticking point even for people who have been working with the technology for some time. The following table provides accurate, but short definitions for the terms related to Azure services. These definitions will be expanded upon in detail throughout the book, so don't worry if you are confused at first:

Previously, Azure used to provide its services via two portals, but recently, Microsoft discontinued the ASM (Classic) portal. However, if you have any services that were running in the classic portal you do not have to worry about them because they have been migrated to Azure ARM portal. Considering that these services would follow the old ASM model. Also, you will note that in the new Azure portal there are two flavors for them. For example, there will be Virtual Machines, and Virtual Machines (Classic).

Historically, Azure services were provided via one portal before 2014, the classic portal, which can be accessed via the following link https://manage.windowsazure.com/. As of now, this portal will redirect to the ARM portal.

The model that was used for that portal is called the ASM model, within which each resource existed independently. You could not manage your resources together, you had to build up and track each resource. For example, you will have to manage the networks from the NETWORKS blade, and the same goes for the storage, virtual machines, and so on. So, when your environment gets bigger, there will be chaos in the management scheme. You will have to know which Azure Virtual Machines are using which virtual networks to do its communications, and that might lead to some critical situations, such as reaching the limits of the allowed number of public IPs, and whenever you need to add a new public IP to be used for a VM in your environment, you would not be able to do so because of the poor management of resources. This would not be your only concern while working with the ASM model. If you want to delete a solution with multiple resources, you will have to do it with each resource manually, and so on.

This is how the classic portal looked:

In 2014, Microsoft launched a new portal that follows a new model, called the ARM model, which can be accessed via the following link https://portal.azure.com/.

When you open the Azure portal, it will look as follows:

This model depends on the concept of resource groups, which means you can group all your resources within a container, resulting in resources being deployed in parallel. As a result, you will not face the same problems as you did with the ASM model.

The following diagram describes the deployed resources through the ARM model:

Here are the benefits you will gain using that portal:

• Ability to manage your resources as a group instead of managing them separately.
• Using Role-Based Access Control (RBAC) to control access to resources, so that you can assign permissions to a user on a resource or some resources, but not to other resources (as it was in the classic portal).
• Using tags to organize and classify your resources, which can help you with billing. For example, you might want to monitor the billing of some resources that make up a solution, for example, a web server. By assigning a tag to the resources that make up that solution, you would be able to monitor its billing, and so on.
• Support the usability of JSON to deploy resources instead of using the portal:
  
  • Deploy resources in parallel instead of deploying them sequentially, and waiting until every resource deployment finishes to deploy another one.
  • Specify dependencies during the resources deployment. For example, a VM will not be created until a storage account and a virtual network get deployed, because the VM VHD would need a place to be stored in and an IP address from a virtual network.
  • Reuse of the JSON template to deploy solutions with the same specifications.

For a better understanding of the ARM model, you might need to consider the following key points:

• Resources with the same lifecycle should be gathered in the same resource group
• Resources in different regions can be in the same resource group
• Every resource must be assigned to a resource group, so whenever you want to move a resource between resource groups you must remove it from its current resource group and then add it to the new resource group
• Resource groups support RBAC, wherein a user can have access to some specific resources, and have no access to the others
• Some resources can be shared across resource groups such as storage accounts
• ARM virtual machines can only be placed in ARM storage accounts
• You cannot create a virtual machine using the ARM model and assign it to a virtual network built using the ASM model
• You cannot use a prebuilt image that was created by ASM APIs to build a VM using the ARM model, but as a workaround you can copy the VHD files from the storage account in the classic portal to a storage account created in the ARM model
• You can migrate assets from the ASM model to the ARM model
• Every resource must be assigned to a resource group, so whenever you want to move a resource between resource groups you must remove it from its current resource group, and then add it to the new resource group

As you have a network in your on-premises (private data center) to facilitate the communication between your machines/devices and even to secure and isolate machines/devices from each other, you will need to do the same tasks in the cloud. That is why Microsoft offers Azure VNet.

Azure VNet is one of the most commonly used Microsoft Azure Networking services. Azure VNet is sort of like a LAN within which you can have address spaces that can be divided into multiple subnets. Considering that, only private IPs ranges can be used for the address spaces and their subnets.

Azure VNet has many benefits and capabilities. The following benefits are some of them:

• Isolation: Each virtual network is isolated from other virtual networks. Therefore, you can have your dev/test environment in a virtual network separated from the production environment that exits in other virtual networks.
• Communicating with other VNets: By default, virtual networks are isolated from each other. However, you can reach out resources in another virtual network, because virtual networks can be connected to each other.
• Broad network access: By default, all Azure services have access to the internet, which means you can access Azure services from wherever you want, using whatever you want, as long you have an internet connection.
• Hybrid connectivity: Azure VNet can be spanned to your data center. As a result, you will be able to connect to both your Azure resources and on-premises resources privately without the need to connect via the internet.
• Security: You can secure your virtual networks by setting rules that determine which inbound and outbound traffic can be flowed to and outside the virtual network.

Creating an Azure VNet is a pretty straightforward process. To do this task, follow these steps:

1. Open the ARM portal and log in using the account associated with your Azure subscription.

2. Once logged in, navigate to More services, and search for virtual network, as shown in the following screenshot:

3. You will be navigated to a new blade, wherein you can display the virtual networks you have created, and you can also create new virtual networks, as shown in the following screenshot:

4. Click on Add, and a new blade will be opened for which you have to fill the following fields:
   • Name: The name of the virtual network.
   • Address space: The virtual network's address range in CIDR notion.
   • Subscription: If you have multiple subscriptions associated to the account you have logged in with, you have to specify which subscription will be charged for this service.
   • Resource group: Specify whether you want to create a new resource group for the resource you are creating, or use an existing one.
   • Location: The region on which this virtual network will operate.
   • Subnet-name: The name of the first subnet in the virtual network you are creating.
   • Subnet | Address range: The subnet's address range in CIDR notion. It must be contained by the address space of the virtual network.
   • Service endpoints (Preview): It can be used in securing your traffic between some Azure services in Microsoft's backbone network. More information about it will be covered in Chapter 2, Delving into Azure Virtual Networks:

5. Click on Create, and within a moment the virtual network will be created.

You can add other address spaces to the virtual network, and later those address spaces can be divided into subnets. To add another address space, follow these steps:

1. Navigate to the Virtual networks blade, and you will find that the virtual network you have created is already there, as shown in the following screenshot:

2. Click on the virtual network, and a new blade will pop up, as shown in the following screenshot:

3. Then, you will navigate to Address space, wherein you will find all the address spaces of this virtual network, as shown in the following screenshot:

4. To add a new address space, you only need to hover over Add additional address range, and add the address space you would need, then click on Save, as shown in the following screenshot:

5. Once you save the changes, the address space will be a part of the virtual network.

There are two types of subnets in Azure VNet:

• Subnet: The normal form of subnets, which is the result of dividing the virtual network
• Gateway subnet: The subnet that acts as a gateway for communication with other networks

By default, you must specify at least one subnet while creating the virtual network, as discussed earlier. However, later you might need to have other subnets, and to do so, you have to follow these steps:

1. Navigate to the virtual network that you have created earlier and then go to SETTINGS | Subnets, as shown in the following screenshot:

2. Click on Subnets, and a new blade will be opened, where you need to specify the following:
   • Name: The name of the subnet.
   • Address range (CIDR block): The subnet's address range in CIDR notation (considering that it must be contained by the address space of the virtual network).
   • Network security group: This works like a firewall to filter what traffic that be allowed to flow in/out of the network. More information about this topic will be covered in Chapter 2, Delving into Azure Virtual Networks.
   • Route table: You can expand the communication between multiple VNets by setting a route table. More information about this topic will be covered in Chapter 4, Network Connectivity Scenarios in Azure.
   • Service endpoints (Preview): As mentioned earlier, this can be used to let some Azure services communicate in Microsoft's backbone network. More information about it will be covered in Chapter 2, Delving into Azure Virtual Networks.

3. Once you click on OK, the subnet will be added within a moment.

Creating the gateway subnet is no different than the normal subnet creation, except you cannot set the name of the gateway subnet, as shown in the following screenshot:

While building your virtual network, you might need to consider the following points:

• You cannot add the following address spaces to your virtual network:
  • 224.0.0.0/4 (multicast)
  • 255.255.255.255/32 (broadcast)
  • 127.0.0.0/8 (loopback)
  • 169.254.0.0/16 (link-local)
  • 168.63.129.16/32 (internal DNS)
• You cannot connect virtual networks that have overlapped address spaces
• As a default limit, you can create 50 virtual networks per region per subscription, but it can be increased up to 1,000 virtual networks if you contact support
• As a default limit, you can create 1,000 subnets per virtual network, but it can be increased up to 10,000 subnets, if you contact support
• As a default limit, you can have 4,096 private IPs per virtual network, but it can be increased up to 8,192 if you contact support

It is no surprise that we commonly face repetitive and time-consuming tasks. For example, you might want to create multiple storage accounts. You would have to follow the previous guide multiple times to get your job done. This is why Microsoft supports its Azure services with multiple ways of automating most of the tasks that can be implemented in Azure. Throughout this book, two of the automation methods that Azure supports will be used.

PowerShell is commonly used with most Microsoft products, and Azure is not less important than any of these products.

Mainly, you can use Azure PowerShell cmdlets to manage Azure Networking tasks, however, you should be aware that Microsoft Azure has two types of cmdlets, one for the ASM model, and another for the ARM model, which we will be using throughout this book.

The main difference between cmdlets of the ASM model and the ARM model is, there will be an RM added to the cmdlet of the current portal.

For example, if you want to create an ASM virtual network, you would use the following cmdlet:

New-AzureVirtualNetwork

But for the ARM model, you would use the following:

New-AzureRMVirtualNetwork

By default, you can use Azure PowerShell cmdlets in Windows PowerShell, but you will have to install its module first.

There are two ways of installing the Azure PowerShell module on Windows:

• Download and install the module from the following link: https://www.microsoft.com/web/downloads/platform.aspx
• Install the module from PowerShell Gallery

The following are the required steps to get Azure PowerShell installed:

1. Open PowerShell in an elevated mode.
2. To install the Azure PowerShell module for the current portal run the following cmdlet Install-Module AzureRM. If your PowerShell requires a NuGet provider you will be asked to agree to install it, and you will have to agree for the installation policy modification, as the repository is not available on your environment, as shown in the following screenshot:

To be able to run your PowerShell cmdlets against Azure successfully, you need to log in first to Azure using the following cmdlet:

Login-AzureRMAccount

Then, you will be prompted to enter the credentials of your Azure account. Voila! You are logged in and you can run Azure PowerShell cmdlets successfully.

To create an Azure VNet, you first need to create the subnets that will be attached to this virtual network. Therefore, let's get started by creating the subnets:

$NSubnet = New-AzureRMVirtualNetworkSubnetConfig –Name NSubnet -AddressPrefix 192.168.1.0/24
$GWSubnet = New-AzureRMVirtualNetworkSubnetConfig –Name GatewaySubnet -AddressPrefix 192.168.2.0/27

Now you are ready to create a virtual network by triggering the following cmdlet:

New-AzureRMVirtualNetwork -ResourceGroupName PacktPub -Location WestEurope -Name PSVNet -AddressPrefix 192.168.0.0/16 -Subnet $NSubnet,$GWSubnet

Congratulations! You have your virtual network up and running with two subnets associated to it, one of them is a gateway subnet.

To add an address space to a virtual network, you need retrieve the virtual network first and store it in a variable by running the following cmdlet:

$VNet = Get-AzureRMVirtualNetwork -ResourceGroupName PacktPub -Name PSVNet

Then, you can add the address space by running the following cmdlet:

$VNet.AddressSpace.AddressPrefixes.Add("10.1.0.0/16")

Finally, you need to save the changes you have made by running the following cmdlet:

Set-AzureRmVirtualNetwork -VirtualNetwork $VNet

Azure CLI is an open source, cross platform that supports implementing all the tasks you can do in Azure portal, with commands.

Azure CLI comes in two flavors:

• Azure CLI 2.0: Which supports only the current Azure portal
• Azure CLI 1.0: Which supports both portals

Throughout this book, we will be using Azure CLI 2.0, so let's get started with its installation.

Perform the following steps to install Azure CLI 2.0:

1. Download Azure CLI 2.0, from the following link: https://azurecliprod.blob.core.windows.net/msi/azure-cli-2.0.22.msi

2. Once downloaded, you can start the installation:

3. Once you click on Install, it will start to validate your environment to
   check whether it is compatible with it or not, then it starts the
   installation:

4. Once the installation completes, you can click on Finish, and you are good to go:

5. Once done, you can open cmd, and write az to access Azure CLI commands:

To create a virtual network using Azure CLI 2.0, you have to follow these steps:

1. Log in to your Azure account using the following command az login, you have to open the URL that pops up on the CLI, and then enter the following code:

2. To create a new virtual network, you need to run the following command:

az network vnet create --name CLIVNet --resource-group PacktPub --location westeurope --address-prefix 192.168.0.0/16 --subnet-name s1 --subnet-prefix 192.168.1.0/24

To add a gateway subnet to a virtual network, you need to run the following command:

az network vnet subnet create --address-prefix 192.168.7.0/27 --name GatewaySubnet --resource-group PacktPub --vnet-name CLIVNet

To add an address space to a virtual network, you can run the following command:

az network vnet update address-prefixes –add <Add JSON String>

Remember that you will need to add a JSON string that describes the address space.

So far, we have covered some preliminary subject matters regarding Azure generally, and
Azure Networking specifically. Some things were not covered in detail, but detailed discussions will be raised in the coming chapters.

In the upcoming chapters, Azure networks architecture and more Azure networking services will be covered in detail. Therefore, the knowledge gained in this chapter is required for a better understanding of the coming chapters.

• Microsoft has data centers all over the globe in all continents (true/false)
• You can assign a single Azure resource to multiple resource groups (true/false)
• State three benefits of using the ARM model instead of the ASM model
• State the tools that can be used to automate Azure tasks
• What is the difference between address space and a subnet in terms of Azure networking?
• What is the difference between a subnet and gateway subnet in terms of Azure networking?
• Can you use 168.63.129.16/32 as an address space? Why/why not?

For more information about virtual networks, you can check out the following link: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview.