1.1 VNet Planning, IP Addressing & Subnet Design
Key Takeaways
- Azure automatically reserves 5 IP addresses in every subnet: .0 (Network Address), .1 (Default Gateway), .2 and .3 (Azure DNS/DHCP), and .255 (Subnet Broadcast).
- The minimum subnet size supported in Azure Virtual Networks is /29 (8 total IP addresses, yielding 3 usable host addresses), while the maximum is /8.
- Subnet delegation assigns exclusive subnet permissions to specific Azure PaaS resource providers (such as Microsoft.Web/serverFarms or Microsoft.Sql/managedInstances), preventing non-matching resources from being provisioned.
- Standard SKU Public IP addresses are static, zone-redundant by default, and enforce a secure-by-default inbound posture requiring explicit Network Security Group (NSG) allow rules.
- Specialized subnets (GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet) have strict CIDR prefix minimums (/27 for GatewaySubnet, /26 for Firewall and Bastion) and restrictive NSG/UDR constraints.
VNet Planning, IP Addressing & Subnet Design
At the core of all enterprise cloud architectures in Microsoft Azure lies the Virtual Network (VNet). A VNet is an isolated, software-defined network (SDN) construct that provides private compute workloads with secure intra-cloud communication, hybrid connectivity to on-premises datacenters, and controlled egress/ingress to the public internet.
Designing an enterprise IP addressing scheme requires understanding Azure-specific SDN behaviors, CIDR prefix mathematics, reserved address allocations, subnet delegation restrictions, and Public IP lifecycle mechanics. Miscalculations in subnet sizing or address space overlaps often lead to complex, disruptive re-addressing projects during peering or hybrid interconnect deployments.
1. Address Space Architecture: IPv4 & Dual-Stack IPv6
When provisioning an Azure Virtual Network, you define one or more address spaces using Classless Inter-Domain Routing (CIDR) notation. Azure VNets are scoped to a single Azure region and a single subscription, though multiple address spaces can be bound to a single VNet.
+-----------------------------------------------------------------------------+
| AZURE VIRTUAL NETWORK ADDRESS ARCHITECTURE |
| |
| VNet: Production-VNet (Region: East US, Scope: Subscription-Core) |
| Address Space 1: 10.100.0.0/16 (RFC 1918 Private IPv4) |
| Address Space 2: 172.16.50.0/24 (Additional Private IPv4) |
| Address Space 3: 2001:db8:abcd::/48 (Global Unicast IPv6 Dual-Stack) |
| |
| +--------------------------+ +--------------------------+ |
| | Subnet: Web-Tier | | Subnet: Database-Tier | |
| | IPv4: 10.100.1.0/24 | | IPv4: 10.100.2.0/24 | |
| | IPv6: 2001:db8:abcd:1::/64 | IPv6: 2001:db8:abcd:2::/64| |
| +--------------------------+ +--------------------------+ |
| +--------------------------+ +--------------------------+ |
| | Subnet: AzureFirewallSubnet | Subnet: GatewaySubnet | |
| | IPv4: 10.100.0.0/26 | | IPv4: 10.100.0.64/27 | |
| +--------------------------+ +--------------------------+ |
+-----------------------------------------------------------------------------+
Private IPv4 Address Allocations (RFC 1918)
Azure fully supports the private IP address ranges established by RFC 1918:
10.0.0.0/8(10.0.0.0to10.255.255.255)172.16.0.0/12(172.16.0.0to172.31.255.255)192.168.0.0/16(192.168.0.0to192.168.255.255)
In addition, Azure permits the use of RFC 6598 Carrier-Grade NAT (CGNAT) space (100.64.0.0/10) and any non-RFC 1918 public IP space as private VNet address prefixes, provided those public ranges are treated as internal private routing spaces within your cloud perimeter.
[!CAUTION] Forbidden & Blocked Address Ranges: Azure strictly prohibits assigning the following address blocks to VNet address spaces:
224.0.0.0/4(Multicast addresses)255.255.255.255/32(Broadcast address)127.0.0.0/8(Loopback addresses)168.63.129.16/32(Azure WireServer / platform infrastructure VIP)169.254.169.254/32(Instance Metadata Service - IMDS)169.254.0.0/16(Link-local addresses)
Dual-Stack IPv6 Architecture
Azure allows you to create dual-stack virtual networks supporting both IPv4 and IPv6 endpoints concurrently:
- IPv6 address spaces in Azure must use Global Unicast Addresses (GUA) allocated by Microsoft or your organization's registered IPv6 prefixes (typically
/48or/56blocks assigned to the VNet). - Subnet Prefix Sizing: Subnets created with IPv6 must be sized exactly as a
/64CIDR block. - IPv6 endpoint communication is direct end-to-end; Azure does not perform NAT64 or NAT46 at the virtual network level.
- IPv6 Network Security Groups (NSGs), user-defined routes (UDRs), and Standard Load Balancers operate independently for IPv4 and IPv6 stacks.
2. Subnet Sizing & The 5 Reserved IP Addresses
Subnets segment a VNet into distinct logical routing and security boundaries. Azure allows subnet prefix sizes ranging from /8 down to /29.
In any subnet you deploy, Azure automatically reserves the first 4 and the last 1 IP address (5 total IP addresses) for SDN infrastructure management, routing, and DNS services. These 5 addresses cannot be assigned to network interfaces (NICs) or virtual appliances.
+-----------------------------------------------------------------------------+
| AZURE 5 RESERVED IP ADDRESSES (EXAMPLE: 10.0.1.0/24) |
| |
| IP Address Reserved Role Function Description |
| ------------ ----------------------- ------------------------------ |
| 10.0.1.0 Network Address Identifies the wire network |
| 10.0.1.1 Default Gateway Subnet router virtual interface |
| 10.0.1.2 Azure DNS Primary Maps to Azure DNS resolver |
| 10.0.1.3 Azure DNS Secondary/DHCP DHCP coordination & DNS backup |
| 10.0.1.4-254 Usable Host Range 251 assignable IP addresses |
| 10.0.1.255 Subnet Broadcast Address Broadcast (dropped by SDN) |
+-----------------------------------------------------------------------------+
Usable IP Address Calculation Formula
To calculate the number of usable host IP addresses in any Azure subnet CIDR block:
| Subnet CIDR | Total IP Addresses | Azure Reserved IPs | Usable Host IPs | Common Enterprise Use Case |
|---|---|---|---|---|
| /29 | 8 | 5 | 3 | Minimum possible Azure subnet; small NVA pair |
| /28 | 16 | 5 | 11 | Azure Application Gateway (v2 small dedicated tier) |
| /27 | 32 | 5 | 27 | GatewaySubnet, RouteServerSubnet |
| /26 | 64 | 5 | 59 | AzureFirewallSubnet, AzureBastionSubnet |
| /24 | 256 | 5 | 251 | Standard application, web, and microservice tiers |
| /22 | 1,024 | 5 | 1,019 | Azure Kubernetes Service (AKS) node/pod pools |
[!IMPORTANT] Minimum Subnet Size Restriction: You cannot create a
/30,/31, or/32subnet inside an Azure Virtual Network. Attempting to provision a/30(4 total IPs) fails because subtracting the 5 reserved addresses yields a negative host count (-1).
3. Specialized & Dedicated Subnets
Several Azure native services require dedicated, specially named subnets with rigid sizing constraints and strict network security group (NSG) and user-defined route (UDR) rules.
| Specialized Subnet Name | Minimum Recommended CIDR | Mandatory Rules & Constraints |
|---|---|---|
GatewaySubnet | /27 (Minimum /29, but /27 required for VPN + ExpressRoute coexistence) | Holds VPN and ExpressRoute Gateway VMs. Never assign an NSG or UDR that routes gateway traffic away from internet/virtual network defaults, or control plane traffic will break. |
AzureFirewallSubnet | /26 (64 IPs) | Dedicated exclusively to the Azure Firewall data plane. Cannot contain VMs. No NSGs are supported on this subnet. UDRs must not point 0.0.0.0/0 to the firewall itself. |
AzureFirewallManagementSubnet | /26 (64 IPs) | Required when enabling Forced Tunneling on Azure Firewall to separate operational management traffic from customer payload egress. |
AzureBastionSubnet | /26 (Minimum /26) | Dedicated to Azure Bastion host VMs. Requires specific inbound/outbound NSG rules for management (HTTPS 443 inbound from Internet, GatewayManager inbound from Azure, 443 outbound to Azure services). |
RouteServerSubnet | /27 (32 IPs) | Dedicated to Azure Route Server BGP speaker instances. Cannot attach an NSG. |
4. Subnet Delegation Mechanics
Subnet Delegation is an Azure platform feature that grants an explicit Azure PaaS service provider permission to inject its dedicated, managed infrastructure directly into your private VNet subnet.
+-----------------------------------------------------------------------------+
| SUBNET DELEGATION WORKFLOW |
| |
| Azure Subscription Admin |
| | |
| v (Delegates Subnet: 10.100.10.0/24) |
| +-------------------------------------------------------+ |
| | Subnet: AppService-Subnet | |
| | Delegation: Microsoft.Web/serverFarms | |
| +-------------------------------------------------------+ |
| | |
| v (PaaS Service Provider Injection) |
| +-------------------------------------------------------+ |
| | Azure App Service Plan (Regional VNet Integration) | |
| | - Instantiates private NICs directly in delegated | |
| | subnet for secure outbound database access | |
| | - Blocks regular compute VMs from joining this subnet | |
| +-------------------------------------------------------+ |
+-----------------------------------------------------------------------------+
Common Delegation Service Providers:
Microsoft.Web/serverFarms: App Service Regional VNet Integration.Microsoft.ContainerInstance/containerGroups: Azure Container Instances (ACI).Microsoft.Sql/managedInstances: Azure SQL Managed Instance.Microsoft.Netapp/volumes: Azure NetApp Files volume mount endpoints.Microsoft.Databricks/workspaces: Azure Databricks compute worker clusters.
Delegation Security & Operational Rules:
- A delegated subnet can be delegated to only one service type at a time.
- Standard VMs, virtual machine scale sets, and un-delegated PaaS instances cannot place network interfaces into a delegated subnet.
- The delegated service provider injects its own Network Intent Policies (NIP), ensuring that any user-attached NSGs or UDRs do not disrupt necessary platform management and health probing communication.
5. Public IP Addresses: SKUs, Allocations & Prefix Reservation
Public IP addresses (PIPs) provide inbound reachability from the public internet and outbound source translation for workloads without a NAT Gateway or firewall.
Standard SKU vs. Legacy Basic SKU
| Feature Dimension | Standard SKU Public IP | Basic SKU Public IP (Retired) |
|---|---|---|
| Allocation Method | Static only (IP remains bound for resource lifetime) | Dynamic or Static |
| Inbound Security Model | Secure by Default: Closed to all inbound traffic until explicitly permitted by a Network Security Group (NSG). | Open by Default: Accessible on all ports unless restricted by NSG. |
| Zone Redundancy | Supports Zone-Redundant, Zonal, or No-Zone configurations across Availability Zones. | Not zone-aware (subject to datacenter failure). |
| Egress / Inbound Integration | Required for Standard Load Balancers, NAT Gateways, and Azure Firewall. | Supported only with Basic Load Balancers. |
[!WARNING] Basic SKU Public IP Retirement: Microsoft has officially retired Basic SKU Public IPs. All enterprise architectures on the AZ-700 exam must utilize Standard SKU Public IPs with explicit NSG inbound security rules.
Public IP Prefixes
A Public IP Prefix is a contiguous, dedicated block of Standard SKU public IPv4 addresses assigned to your Azure subscription (available in prefixes from /28 down to /31).
/28= 16 public IP addresses/29= 8 public IP addresses/30= 4 public IP addresses/31= 2 public IP addresses
Using Public IP Prefixes simplifies firewall allowlisting for external business partners, as you can provide a single CIDR block rather than individual disparate IP addresses.
An enterprise network architect is designing a dedicated subnet for a high-availability database cluster that requires exactly 12 database virtual machines and 2 active failover proxy appliances (14 total virtual machines). What is the smallest CIDR prefix that can be allocated in Azure to host this workload without running out of IP addresses?
A DevOps team is attempting to deploy an Azure App Service Plan with Regional VNet Integration into an existing virtual network. The deployment fails immediately with an error stating that the target subnet cannot accept the network interface injection. What is the root cause of this failure?
A network engineer replaces a decommissioned Basic SKU Public IP on a web server's network interface with a newly provisioned Standard SKU Public IP. Immediately following the change, external HTTP/HTTPS traffic to the web server fails completely, even though the web service is running locally. What is the primary reason for this connectivity outage?