Plan Azure virtual network and subnet address ranges accounting for Azure-reserved addresses.
Azure VNets, like AWS VPCs, reserve 5 IP addresses in every subnet: the network address, a default gateway address, two addresses reserved for mapping Azure DNS, and the broadcast address. Azure supports VNet address spaces considerably larger than AWS's /16 cap (down to /8 in principle, though most real deployments use /16 to /24), and subnets delegated to platform services like App Service Environments, Azure NetApp Files, or Azure Container Instances typically need a larger minimum subnet size (often /24 or larger) to leave room for the service's own scale-out address consumption.
Usable IPs per Azure subnet
usable = 2^(32 − subnet_prefix) − 5
The network address (first), the default gateway (second), two addresses reserved to map Azure's DNS servers into the VNet space (third and second-to-last), and the broadcast address (last) — identical in count, though not identical in exact purpose, to AWS's 5 reserved addresses.
Services like Azure App Service Environment or Azure NetApp Files provision their own internal infrastructure IPs within the delegated subnet as they scale, so a too-small subnet can block the service from scaling out or even from being created in the first place.
Yes — unlike some cloud providers, Azure lets you add additional address ranges to an existing VNet after creation, and you can also add/resize subnets as long as the new ranges don't overlap with existing subnets or peered VNets.
Yes — two VNets with overlapping IP address ranges cannot be peered together, which is why address space planning across an organization's full set of VNets (and any on-premises RFC 1918 ranges) matters from the start, not just within a single VNet.