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.
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
- 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:
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:
East US 2
North Central US
South Central US
West Central US
West Central US
West US 2
West US 2
US Gov Virginia
US Gov Iowa
US DoD East
US DoD Central
US Gov Arizona
US Gov Texas
Sao Paulo State
New South Wales
Australia Central 1
Australia Central 2
South Africa West
South Africa North
This global presence means you can build your networks in the nearest region, and access them from anywhere in the world, considering that Microsoft keeps building new data centers in new regions, so latency between your on-premises environment and Azure is decreased.
You can find out the nearest region to you with the lowest latency via the following website http://www.azurespeed.com/. Azure services are available in 140 countries around the globe and support 17 languages, and 24 currencies.
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:
Figure 1.1: Azure Classic portal
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:
Figure 1.2: Azure portal
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:
Figure 1.3: Resource manager management model at a high level
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.
- 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
You can change the background of the portal by double-clicking on any unused area of the dashboard. You can navigate between four colors (blue, dark blue, white, and black). For further information about the difference between the ARM and ASM models, check out the following article: https://blogs.technet.microsoft.com/meamcs/2016/12/22/difference-between-azure-service-manager-and-azure-resource-manager/.
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.
The subnets within each address space are automatically routed. The address range of a subnet that is in use cannot be edited.
- 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.
- Open the ARM portal and log in using the account associated with your Azure subscription.
- Once logged in, navigate to
More services, and search for
virtual network, as shown in the following screenshot:
Figure 1.4: Searching for virtual networks blade
- 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:
Figure 1.5: Virtual networks blade
- 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.
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:
Figure 1.6: Creating a virtual network
- Click on
Create, and within a moment the virtual network will be created.
- Navigate to the
Virtual networksblade, and you will find that the virtual network you have created is already there, as shown in the following screenshot:
Figure 1.7: Displaying the created virtual networks
- Click on the virtual network, and a new blade will pop up, as shown in the following screenshot:
Figure 1.8: PP-Virtual Network overview
- 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:
Figure 1.9: Address spaces of the virtual network
- 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:
Figure 1.10: Adding new address space
- Once you save the changes, the address space will be a part of the virtual network.
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:
- Navigate to the virtual network that you have created earlier and then go to
Subnets, as shown in the following screenshot:
Figure 1.11: Virtual Network Subnets
- 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.
Figure 1.12: Adding subnets
- Once you click on
OK, the subnet will be added within a moment.
When specifying the subnet's address range, you must have noted that there are five reserved IPs. The first and the last IPs are reserved for protocol conformance known as network and broadcast in addition to three more IPs used for Azure services.
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:
Figure 1.13: Adding gateway subnet
- You cannot add the following address spaces to your virtual network:
- 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.
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:
But for the ARM model, you would use the following:
Most of the time this would be the case. But a few Cmdlets are totally different and some others don't even exist in the ASM model and do exist in the ARM model.
By default, you can use Azure PowerShell cmdlets in Windows PowerShell, but you will have to install its module first.
- Download and install the module from the following link: https://www.microsoft.com/web/downloads/platform.aspx
- Install the module from PowerShell Gallery
- Open PowerShell in an elevated mode.
- 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:
Figure 1.14 Installing the AzureRM PowerShell module
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.
$VNet = Get-AzureRMVirtualNetwork -ResourceGroupName PacktPub -Name PSVNet
Then, you can add the address space by running the following cmdlet:
Finally, you need to save the changes you have made by running the following cmdlet:
Set-AzureRmVirtualNetwork -VirtualNetwork $VNet
Azure CLI comes in two flavors:
Throughout this book, we will be using Azure CLI 2.0, so let's get started with its installation.
- Download Azure CLI 2.0, from the following link: https://azurecliprod.blob.core.windows.net/msi/azure-cli-2.0.22.msi
- Once downloaded, you can start the installation:
Figure 1.15: Installing Azure CLI 2.0
- 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:
Figure 1.16: Installing Azure CLI 2.0
- Once the installation completes, you can click on
Finish, and you are good to go:
Figure 1.17: Installing Azure CLI 2.0
- Once done, you can open
cmd, and write
azto access Azure CLI commands:
Figure 1.18: Opening the Azure CLI using CMD
- 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:
Figure 1.19: Logging in to Azure via Azure CLI 2.0
- 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
az network vnet subnet create --address-prefix 192.168.7.0/27 --name GatewaySubnet --resource-group PacktPub --vnet-name CLIVNet
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
126.96.36.199/32as 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.