The address space for a given VNet can be as small as a CIDR /29 with 8 available IP addresses- please don’t ever assign that small or an address space to VNet! So, that address space can go all the way up to a CIDR /16 with 65,536 IP addresses (maximum amount of IP’s available per VNet). Another fun fact is that subnets, that make up the allocated address space for a VNet, can only have a maximum of 3,000 provisioned per given VNet (source). So subnetting at that scale needs a bit of planning. More on that another time perhaps.

Now that we’ve got some constraints laid out, I thought I’d share the bellow table that is particularly relevant to subnet provisioning for VNets.

Whats interesting is that the smaller the subnets that are provisioned, the more wasted IP addresses there are. Lets define that statement- this is because with any given subnet, the Azure network fabric requires 5 IP addresses which can’t be used by customers (therefore, thats why a /29 is the smallest available subnet).

Assuming we want to leverage a /16 address range in a given VNet, its not until you lay out (like bellow) the amount of different subnets available that you see the potential for wasted IP addresses when subnetting, especially when you’re considering the use lots of smaller subnets.

Note: this can also apply and extend to multiple VNets if you are working with a single /16 address space for your entire Azure IP address allocation on say a subscription basis, or region basis.

My thoughts

• You want to assign adequate address space to VNets so that you don’t run into downstream outages, but you don’t want to overextend that address space and leave a bunch of it locked and unusable elsewhere either
  • For example, assigning a /16 to a VNet, but then only having a handful of /24 subnets utilised because that’s all the IP address requirements there are
• There isn’t a one size fits all formula as most environments share similarities, every environment is at a different scale
• Finding a good balance between subnet size vs wasted IP addresses is the main challenge as that directly impacts available IP addresses
• Smaller subnets certainly have their place in VNets, and are required for certain workloads (for example the GatewaySubnet)
• My baseline though centres around
  • Uniformity
  • Establishing repeatable and easy to follow patterns
  • Alignment with existing networking patterns
• /24 is a good baseline to start with for subnets, as most existing network segments use this range
  • It’s the ‘Goldilocks’ or ‘just right’ subnet size
  • That /24 baseline keeps things simple, and I believe is important to do so as over complication happens to often in IT
  • Maxing out with only /24s in a /16 keeps well within VNet limitations and loses only ~1280 IP’s
  • When considering a /16, losing ~1280 or about ~2% of IP’s, I think thats an acceptable trade off
  • Moving one step down to /25 and up to /23 is then fairly easy and the three of these subnets when deployed at scale don’t waste too many IP addresses, as calculated above

Enjoy and happy subnetting..