To follow along with the instructions in this chapter, you will need the following:

• A PC with an internet connection
• An Azure subscription

Before we proceed to cover the security best practices, let us prepare our Azure subscription for the hands-on exercises that we will complete later in the chapter.

Before we get too far into Azure networking concepts, let’s establish what Azure VNet is and the capabilities that it provides.

A VNet is a virtual version of a physical network, implemented on the Azure cloud platform. The main advantage that it has over a traditional network is that we don’t need to implement or maintain the underlying physical hardware for this network (these responsibilities are offloaded to our cloud provider – Microsoft). But for the most part, we can achieve similar capabilities and architectures that we can achieve on-premises. We can even implement more flexible architectures with Azure VNets due to the software-defined nature.

So, what capabilities does Azure VNet provide? Here is a short list of some use cases:

• Connectivity for supported Azure services including VM, virtual machine scale sets (VMSSs), and 32 other services
• Native Internal TCP/UDP Load Balancing and proxy systems for Internal HTTP(S) Load Balancing
• Connects to on-premises networks using Cloud VPN tunnels and Cloud Interconnect attachments

Limitation

An Azure subscription can have up to 1,000 VNets as of the time of writing (April, 2022). An additional subscription will be needed to grow beyond this limit.

Azure VNet versus traditional networks

Even though Azure VNet is similar to a traditional on-premises network in many ways, there are still important differences, mainly due to restrictions that have been put in place by Microsoft to ensure security in a multi-tenant platform such as Azure. Here are some key ones:

• Azure VNet does not support Layer-2 semantics (Only Layer-3 and Layer-4). This means that concepts such as virtual LANs (vLANs) and Layer-2 broadcasts don’t work in Azure VNet. Figure 1.1 shows the output of running the arp -a command on a VM that is deployed in Azure VNet. You will notice that the MAC address resolution for VMs in the same subnet results in the same 12:34:56:78:9a:bc value. This is because we are on a shared platform and the VNet is a Layer-3 overlay instead of Layer-2:

Figure 1.1 – ARP table on an Azure VM

• Another key difference between a traditional network and Azure VNet is that some protocols and communication types are restricted from being used in Azure VNet. Protocols such as multicast, broadcast, DHCP unicast, UDP source port 65330, IP-in-IP encapsulated packets, and Generic Routing Encapsulation (GRE) packets are not allowed in Azure VNet. Any application or service capability that requires these protocols or communication types will need to be refactored before deployment into Azure VNet for it to work. The only protocols that are allowed are TCP, UDP, ICMP, and Unicast communication (except source port UDP/68 /, destination port UDP/67, and UDP source port 65330, which is reserved for the host).

Note

For more information on the differences of Azure VNet and traditional networks, refer to the document at https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq.

Now that you have some fundamental information on what Azure VNet is, let’s discuss how you would go about planning one, starting with considerations around naming it.

All Azure resources have a name that must be unique within a scope. The scope is different for each resource type. When creating a Vnet, its name must be unique within the scope of the resource group. This means that it is possible to have two Vnets in your Azure subscription with the same name as long as they don’t belong to the same resource group! This can be useful in a design that involves having the same Vnet resource name for both development and production environments, as shown in Figure 1.2.

Figure 1.2 – Vnet names must be unique for the resource group scope

Even though it is possible to have duplicate names within a subscription, it is not a recommended practice as it could later lead to confusion when investigating security incidents using logging information (we will cover network logging and monitoring later in this book). When investigating security incidents, it helps to be able to quickly identify affected resources and having a unique resource naming strategy for your Vnets helps with this.

Regarding naming best practices, it is best to define a naming convention as early as possible. This convention should be communicated to the teams with permission to create network resources in Azure, and preferably, the naming convention should be enforced using tools such as Azure Policy. To define a good naming strategy, consider these recommendations:

• Review resource name restrictions for the Vnet and other network resources in Azure. For example, a Vnet name can have up to 64 characters made up of alphanumerics, underscores, periods, and hyphens. Your naming convention should take this into consideration. Information on Vnet naming restrictions can be found at https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftnetwork.
• Consider including information about the following – resource type, resource location, deployment environment, and workload type in your naming convention. For example, a Vnet for production web services workloads in the East US region might be named prod-eastus-webservices-Vnet (Figure 1.3).

Figure 1.3 – Sample Vnet naming convention

For more thoughts on naming conventions, please refer to this document: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming.

Almost all Azure services are created in a regional location specified at creation time. I said almost all because there are some exceptions – so-called global or non-regional services that are not pinned to a region. Azure Vnet is a regional service.

As of the time of writing (April 2022), the Azure cloud has 55 active regions in which we can create Vnets (with nineteen announced regions coming soon).

So, which regions should you select when creating Vnets? Consider the following three points to guide your decision regarding this:

• Business compliance requirements: This is the first point that you should consider when deciding the Azure region to locate your Vnets in. If there are organizational/industry compliance requirements that require data residency or data sovereignty in a geographic area, then you must adhere to that! You don’t want to end up in a situation where your organization is fined or charged for violating governmental regulations! For example, if you are providing services to a US government agency, the workloads that you are using to provide those services may be required to be in Vnets created in one of the Azure US government regions.
• Proximity to the users: This is the second key point to consider regarding Vnet location. You want your networks in locations close to the end users to ensure the lowest network latency. For example, if your organization is based in the UK and your network will host workloads that will provide services to your customers in the area, it will probably be best to create your Vnet(s) in either the UK South or the UK West Azure regions. You could perform your own tests to determine latency information for your end users or you could leverage unofficial sites such as https://azurespeedtest.azurewebsites.net/ and https://cloudpingtest.com/azure.
• Resiliency requirements: This is another key point to consider when deciding where you should create your Vnets. Does your resiliency architecture require you to be able to distribute your network workloads in multiple data centers within the same region? If it does, then you need to select one of the regions that allow you to use availability zones (AZs) – distinct groups of data centers in the same region. Not all Azure regions currently support this capability. At the time of writing, only 25 of the 55 active regions support AZs. I will recommend checking this document for an up-to-date list before you create your network resources – https://docs.microsoft.com/en-us/azure/availability-zones/az-overview.

The following diagram shows an example of a Vnet with AZs:

Figure 1.4 – A Vnet with AZs

Also, keep in mind that the decision to distribute your network workloads in multiple AZs in a region results in an extra cost of 0.01 USD (0.008 GBP) per gigabyte of data transferred between AZs for both inbound and outbound traffic.