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