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.