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.

 

CIDR IP Addresses Fit within a /16 Wasted IP's Left With
/28 16 4096 20480 45056
/27 32 2048 10240 55296
/26 64 1024 5120 60416
/25 128 512 2560 62976
/24 256 256 1280 64256
/23 512 128 640 64896
/22 1024 64 320 65216
/21 2048 32 160 65376
/20 4096 16 80 65456


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.