Understanding private IP address assignment for subnet workloads
When resources are deployed into an Azure VNet subnet, a private IP address is automatically assigned from the subnet’s address range. If the subnet is a single-stack subnet (IPv4 only), Azure assigns an IPv4 address to the workload. If the subnet is a dual-stack subnet (both IPv4 and IPv6), Azure assigns both an IPv4 and an IPv6 address if the service supports IPv6 assignments. As of the time of writing, only VMs and VMSS NICs support both IPv4 and IPv6, other VNet services/resources support only IPv4 private IP assignments.
There are two methods for private IP assignments in an Azure VNet subnet (Figure 1.31):
- The first method is dynamic assignment where the next available unassigned or unreserved private IP address, from the subnet’s address range, is automatically assigned to a resource. This is the equivalent of using Dynamic Host Configuration Protocol (DHCP) on-premises. For example, in a subnet with a
10.10.1.0/24address range, if the10.10.1.4address is already assigned to another resource, the next available address –10.10.1.5– is automatically assigned to the next resource. This method is the default allocation method for all VNet resources, including VNet-integrated platform services. For VM and VMSS NICs, dynamic IP addresses are released if a network interface is deleted or re-assigned to a different subnet within the same VNet.
Figure 1.31 – VNet resource private IP assignment options
- The second method is static assignment, where an unassigned or unreserved IP address can be reserved for a resource from the subnet’s address range. This may be necessary for situations where clients or other services are hardcoded to locate an application via its IP address instead of its Domain Name System (DNS) record (we will cover DNS options in Azure in the second chapter of this book). It is highly recommended to implement a static IP assignment by changing the private IP allocation method from the Azure platform instead of setting the IP statically from the operating system (as we would do on-premises). The latter method could lead to loss of access if the resource is moved into a different subnet. This method is not supported by all VNet resources but it is supported for common ones, such as VM NIC (Figure 1.31) and Azure Cache for Redis (Figure 1.32).
Figure 1.32 – Static IP assignment for a VNet deployed Cache for Redis resource
As a general rule, you should avoid static private IP assignments as much as possible. This is because cloud-hosted workloads are usually dynamic with capabilities such as auto-scaling that allow resources to be added/removed in response to the volume of requests being received. Using the default dynamic assignment method means that we have one less thing to worry about.
It is also important to note that VM network interfaces can have more than one private IP assignment (Figure 1.33). Actually, they can have up to 256 private IP assignments!
Figure 1.33 – Multiple private IP assignments for a VM NIC
Enough discussion for now; let us review this in practice. But first, we need to determine the locations and VM sizes that we will be using.
