Azure Networking: Expanding Subnets with Multiple Prefixes without Downtime.

In Azure, a subnet has a single address prefix, a part of your Virtual Network (VNet) address space. This works fine until your workloads outgrow the available IPs. Traditionally, the fix meant creating a new subnet and moving resources, often causing downtime. Now, Azure has introduced a multiple-prefix subnet feature that lets you expand capacity without redeploying.

Sometimes, your subnet prefix is too small and doesn’t fit your needs anymore. In many situations, it is not a problem.

Think of a subnet as a logical grouping of virtual network interfaces (vNICs) that share the same network policies, like Network Security Groups (NSGs), NAT Gateways, and route tables. Within the same VNet, vNICs can communicate directly, regardless of which subnet they’re in. Adding a new prefix to the VNET and creating a new subnet will be enough to overcome the shortage of IP addresses in the first Subnet.

But with stateful or large-scale deployments, like Virtual Machine Scale Sets (VMSS), IP exhaustion can be painful. Redeploying VMSS into a new subnet means downtime, scaling delays, and potential customer impact.

Fortunately, a new feature in Azure Virtual Network allows you to add a new prefix to a subnet. This feature is only available in PowerShell, Azure CLI, ARM Template, and Bicep.

Let’s take an example: an application needs an Azure SQL Database, a load balancer, and 10 to 15 VMs with the application. To ease the deployment, VMSS with the flexible orchestration mode.

You create a VNET for the application, with the 192.168.0.0/24 prefix. Within this VNET, two subnets are created, one for the private endpoint of the Database, 192.168.0.0/29, and one for the VMSS and the LB (192.168.0.128/27). The last prefix has enough IP addresses to support scaling operation (27 free IPs).

Everything works perfectly until the marketing team announces that the application will be presented on social media and TV, so you need to increase the capacity at least sixfold, which means at least 90 VMSS instances or a /25 prefix.

There are two solutions:

• Create a new subnet and move the VMSS. This is the default solution until now, but a downtime is needed.
• Add a prefix to the existing subnet. This is the new feature.

A /25 prefix is needed, but to avoid any disturbance while scaling, a /24 is better. A new prefix will be added to the VNET and then to the subnet.

The multiple-prefix feature is currently supported via PowerShell, Azure CLI, ARM templates, and Bicep. The Azure portal is not supported. Below is a PowerShell example to expand a subnet without downtime.

The first step is to update the Azure PowerShell module.

Update-Module-NameAz-Force 

After that, a new /24 prefix needs to be added to the current VNET.

$vnet= Get-AzVirtualNetwork -Name <VnetName> -ResourceGroupName <ResourceGroupName> $vnet.AddressSpace.AddressPrefixes.Add("192.168.1.0/24") Set-AzVirtualNetwork-VirtualNetwork $vnet 

After that, we can add the new prefix to the subnet.

$vnet=Get-AzVirtualNetwork -Name <VnetName> ResourceGroupName <ResourceGroupName> Set-AzVirtualNetworkSubnetConfig -Name'APP' -VirtualNetwork$vnet-AddressPrefix '192.168.0.128/27','192.168.1.0/24' $vnet|Set-AzVirtualNetwork 

The subnet has been updated. If you take a look at the Azure Portal, you will get:

You can see that Azure reserves the first three available IP addresses of each prefix for internal use.

However, you will have no option to manage this from the portal.

But you can also manage multiple prefixes in a subnet using Bicep and ARM templates. You will need to use at least the 2018-08-01 API version to use the property called addressPrefixes. This property uses an array of strings as a value.

In ARM/Bicep, the addressPrefixes property accepts an array of CIDR blocks. This is what enables multiple prefixes. You can still use addressPrefix for single values, but mixing the two in the same resource definition isn’t allowed.

param location string = resourceGroup().location @description('VNet name') param vnetName string = 'vnet2' @description('Vnet Address space') param vnetAddressPrefix string = '10.0.0.0/8' @description('First Subnet Prefix') param subnetPrefix1 string = '10.0.0.0/24' @description('First Subnet Prefix') param subnetPrefix2 string = '10.0.1.0/24' @description('Subnet1 Name') param subnet1Name string = 'sub1' resource vnet 'Microsoft.Network/virtualNetworks@2024-07-01' = { name: vnetName location: location properties: { addressSpace: { addressPrefixes: [ vnetAddressPrefix ] } } } resource subnet1 'Microsoft.Network/virtualNetworks/subnets@2024-07-01' = { parent: vnet name: subnet1Name properties: { addressPrefixes: [ subnetPrefix1 subnetPrefix2 ] } } 

Restrictions for Multiple-Prefix Subnets

• No subnet delegation (except VPN/ExpressRoute gateways)
• No VNet injection for container services
• Primarily supports IaaS workloads (VM, VMSS)

Best Practice: Plan for growth by using addressPrefixes from the start in Bicep/ARM Template. Even if you only need one prefix today, defining it as an array future-proofs your network configuration.