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 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.

What's interesting is that the smaller the subnets that are provisioned, the more _wasted_ IP addresses there are. Let's 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, that's why a /29 is the smallest available subnet).

Assuming we want to leverage a /16 address range in a given VNet, it's not until you layout (like bellow) the number 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 centres around:

1. 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

2. 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 too 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 that's 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.