Understanding Azure VNet

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.