Building VMs in Azure is a common task, but to do this task well, and to make it operate properly, you need to understand the considerations of Azure VNets for Azure VMs. These considerations are as follows:

• Azure VNets enable you to bring your own IPv4/IPv6 addresses and assign them to Azure VMs, statically or dynamically
• You do not have access to the role that acts as DHCP or provides IP addresses; you can only control the ranges you want to use in the form of address ranges and subnets
• Installing a DHCP role on one of the Azure VMs is currently unsupported; this is because Azure does not use traditional Layer-2 or Layer-3 topology, and instead uses Layer-3 traffic with tunneling to emulate a Layer-2 LAN
• Private IP addresses can be used for internal communication; external communication can be done via public IP addresses
• You can assign multiple private and public IP addresses to a single VM
• You can assign multiple NICs to a single VM
• By default, all the VMs within the same virtual network can communicate with each other, unless otherwise specified by an NSG on a subnet within this virtual network
• The network security group (NSG) can sometimes cause an overhead; without this overhead, however, all VMs within the same subnet would communicate with each other
• By default, an inbound security rule is created for remote desktops for Windows-based VMs, and SSH for Linux-based VMs
• The inbound security rules are first applied on the NSG of the subnet and then the VM NIC NSG – for example, if the subnet's NSG allows HTTP traffic, it will pass through it; however, it may not reach its destination if the VM NIC NSG does not allow it
• The outbound security rules are applied for the VM NIC NSG first, and then applied on the subnet NSG
• Multiple NICs assigned to a VM can exist in different subnets
• Azure VMs with multiple NICs in the same availability set do not have to have the same number of NICs, but the VMs must have at least two NICs
• When you attach an NIC to a VM, you need to ensure that they exist in the same location and subscription
• The NIC and the VNet must exist in the same subscription and location
• The NIC's MAC address cannot be changed until the VM to which the NIC is assigned is deleted
• Once the VM is created, you cannot change the VNet to which it is assigned; however, you can change the subnet to which the VM is assigned
• You cannot attach an existing NIC to a VM during its creation, but you can add an existing NIC as an additional NIC
• By default, a dynamic public IP address is assigned to the VM during creation, but this address will change if the VM is stopped or deleted; to ensure it will not change, you need to ensure its IP address is static
• In a multi-NIC VM, the NSG that is applied to one NIC does not affect the others