Azure IP Address Limitations and Reserved Ranges: Subnet IPs, IMDS and VNet Rules

Azure IP address limitations and reserved ranges#

Azure virtual networks block multicast, broadcast and several special-purpose IPv4 ranges. Each Azure subnet also reserves five addresses. Understanding these rules prevents deployment failures, undersized subnets, DNS problems and health-probe outages.

Ranges that cannot be added to a VNet#

• 224.0.0.0/4 — multicast
• 255.255.255.255/32 — limited broadcast
• 127.0.0.0/8 — loopback
• 169.254.0.0/16 — link-local addresses
• 168.63.129.16/32 — Azure platform virtual IP

For private address space, use RFC 1918 ranges such as 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Azure also supports RFC 6598 shared address space. Plan ranges carefully to avoid overlap with on-premises networks and peered VNets.

Five addresses reserved in every Azure subnet#

Azure reserves the first four addresses and the last address in every subnet. For 192.168.1.0/24, the reservations are:

• 192.168.1.0 — network address
• 192.168.1.1 — Azure default gateway
• 192.168.1.2 and 192.168.1.3 — Azure DNS mapping
• 192.168.1.255 — subnet broadcast address

A /29 subnet contains eight total addresses but only three usable addresses after Azure reservations. Include this overhead when planning capacity.

Special Azure infrastructure addresses#

168.63.129.16#

This fixed Microsoft-owned virtual IP supports Azure DNS, DHCP, platform health probes and host communication. Do not block required outbound communication to it in the guest operating-system firewall.

169.254.169.254#

This link-local address hosts the Azure Instance Metadata Service inside a virtual machine. Access it directly without a proxy. Applications and agents can use it to obtain instance metadata and managed-identity tokens.

Multicast and broadcast limitations#

Azure VNets do not provide traditional Layer 2 multicast or broadcast. Use unicast designs, Azure Load Balancer, message brokers or a supported specialist solution when an application depends on multicast behavior.

Address-planning best practices#

• Allocate sufficiently large RFC 1918 ranges and retain unassigned space for growth.
• Avoid very small subnets unless the usable-address calculation has been verified.
• Reserve non-overlapping ranges for peering, VPN and ExpressRoute connectivity.
• Document address ownership and expected growth before connecting networks.
• Account for platform-reserved addresses when sizing every subnet.

Common problems and corrections#

• VNet creation rejects a range: choose an allowed CIDR block and verify it does not overlap connected networks.
• DNS or health probes fail: check the guest firewall and required access to 168.63.129.16.
• Metadata requests fail: connect directly to 169.254.169.254 and bypass configured proxies.
• A subnet runs out of addresses: include Azure's five reservations and service-specific requirements in capacity calculations.

Verify address space with Azure CLI#

Frequently asked questions#

Can a VNet use public address ranges?#

Azure supports various address spaces, but private RFC 1918 or RFC 6598 ranges are usually safer for enterprise networks because they reduce routing ambiguity and ownership conflicts.

Why does a VM communicate with 168.63.129.16?#

It is an Azure platform virtual IP used for essential infrastructure services. Only the Azure platform can originate traffic from it, and required outbound communication should remain available.

Official references#

Azure Virtual Network FAQ

Azure virtual network IP addresses

Azure Instance Metadata Service