Configuring Azure virtual network subnets with CIDR notation

For people new to networking, creating Azure Virtual subnets can be tricky. Learn how CIDR notation works to segment ranges of IP addresses.

When you create an Azure virtual , you'll get default IP addresses that look something like this:

Azure Virtual Networks add dialogAzure Virtual Networks add dialog

This gives you a private address space at with 65,536 addresses to use. Great!

(Note: These private IP addresses are not routable across the internet. If your devices need to be accessible on the public internet, visit Public IP addresses).

Now it's not recommended to put all of your resources into that same address space. It's inefficient from a network routing perspective, and it makes it harder to secure traffic and limit it between devices. A good security principle that applies to networking is to limit “lateral movement”, that is the ability for a hacker or infected device to easily communicate with other systems in your network. If we left this without any subnets, one compromised device could talk to the other 65,535 devices in our network.

Azure suggests that we add a subnet called default, with a Subnet address range of What does that mean?

Well, subnets (literally sub networks) carve up or segment a bigger address space into smaller sections. We can then limit traffic in and out of this subnet (to the devices in this address space segment) by configuring a network security group. We can also add a network security group to the network interface of a specific virtual machine, to gives us another layer of network security control. To learn how this works, visit How network security groups filter network traffic.

Imagine your virtual network is a round, decorated birthday cake. You've carved out one segment of that birthday cake as a subnet, so it contains a smaller amount of those 65,536 addresses. How many does it contain? That depends on what CIDR notation you've used!

CIDR (Classless Inter-Domain Routing) is a method for allocating IP addresses. It's the /x number, and that number determines how many IP addresses will be available in that subnet.

Stay with me if you want to go down the math rabbit hole of IP addressing for a moment or skip to the next part.  IP addresses (v4) are written as a set of four numbers, like

These are converted to binary (the ones and zeroes that computers use), to look like this:

11000000 10101000 00000001 00000000.

We create a subnet by adding a “mask” to this number, telling the computer how many of the digits we want to read and keep the same (left to right).

With a /24, we're saying “grab the first 24 digits” for this subnet, so that keeps the 192.168.1 and leaves us the “.0” on the end as a pool of addresses we can use in this subnet.

Those last 8 binary digits can only add up to 255 (with binary being a base 2 system) AND including zero as a possible value, which has defined our available 256 addresses we can use in this subnet – 0 to 255.

If we'd used a /29, keeping the first 29 digits, we'd only have 8 available IP addresses in this subnet, because 11000000 10101000 00000001 00000xxx leaves us just 000 left – a maximum binary value of 7 plus our zero value equals 8 IP addresses.

If you're old school and are used to specifying subnet masks like, that's a /24 CIDR notation, with its range of 256 IP addresses ( to

Skipped to here? Let's continue!

The CIDR number is like specifying how large you want the slices of cake to be. Fortunately, you don't have to do the math, because there are a ton of free CIDR notation tables and calculators on the internet that will tell you how many addresses you'll have in your subnet if you use a /28 or a /18 for example. When you add a subnet to your Azure virtual network, you'll also get a note as you create it, telling you how many addresses will be available with the values you have entered.

Just remember, a subnet segments those address from the pool of your total available addresses. Segment two large subnets and you may not have room to add any more subnets.

In our example, the recommended default gives us a subnet of 256 IP addresses EXCEPT Azure reserves 5 of these (the first and last address in each subnet for protocol conformance and 3 additional addresses for Azure service usage), so we have 251 available in Azure. This bundles up addresses

So what if we want to add another subnet to this virtual network? Now we have to make sure we don't overlap that subnet we already have!

Azure will suggest we use Generally, /24 is a good size for a subnet, and now we'd have:
Default to
Subnet2 to
Again, keeping the first 3 parts of the IP address (24 digits in binary) the same.

Now we can keep on carving up our virtual network into different subnets, within the original to addresses (our address space). Or, on reflection, we could have used a smaller CIDR notation for the original Azure Virtual Network, and created multiple different Vnets, each with their own subnets. There are just a couple of extra things to note …

Azure Virtual Network disallowed address spaces
The following address spaces cannot be used: (Multicast) (Broadcast) (Loopback) (Link-local) (Internal DNS, DHCP, and Azure health probe)

Learn more at Create a virtual network

On-premises networks
IP addressing has to be unique – you can't have two resources with the same IP address. If you've configured a Site-to-Site to allow connectivity to/from an on-premises network, consider which private IP address spaces are in use in that on-prem environment, so your Azure vnets and subnets don't conflict.

Gateway subnet
Speaking of connections, if you're using an Azure Gateway it also needs gateway subnet of IP addresses. There are some rules around the configuration of this particular type of subnet – it must only contain your virtual network gateway resources, it must be named GatewaySubnet and it must be sized appropriately. You can't change this sizing once you've deployed it, so Microsoft recommends a CIDR notation of /27 or “larger” (e.g. /26) to give you room for growth.
For more information on VPN Gateways, visit About VPN Gateway configuration settings

Want to learn more?

Secure and govern workloads with network level segmentation

Plan virtual networks – subnets

Add, change, or delete a virtual network subnet

Gateway subnet guidance – About VPN gateway configuration settings

Azure Virtual Network and Azure VPN Gateway modules on Microsoft Learn


This article was originally published by Microsoft's Core Infrastructure and Security Blog. You can find the original article here.