Reserved and internal-use IP addresses in Azure

When you create a subnet in an Azure Virtual Network (VNet), not all IP addresses in the CIDR range are available for your workloads. Azure reserves several addresses in every subnet for internal platform services such as routing, DNS, and infrastructure management.

IP addresses reserved by Azure

In every Azure subnet, Microsoft reserves five IP addresses:

  • The first IP address – network identifier
  • The next three IP addresses – used internally by Azure
  • The last IP address – reserved for Azure infrastructure

Example: /24 subnet in Azure

A subnet with CIDR 10.0.0.0/24 contains 256 total IP addresses.

Azure reserves:

  • 10.0.0.0
  • 10.0.0.1
  • 10.0.0.2
  • 10.0.0.3
  • 10.0.0.255

This leaves 251 usable IP addresses for virtual machines, private endpoints, and other resources.

Why Azure reserves these addresses

Azure uses the reserved IP addresses to provide core platform functionality, including:

  • Virtual network routing
  • DNS services
  • Gateway and load balancer integration
  • Internal health and management services

These addresses are not configurable and cannot be assigned to customer resources.

Practical implications for subnet planning

Because Azure reserves five addresses per subnet, small subnets can run out of usable IPs much faster than expected.

This is especially important when deploying:

  • Private Endpoints
  • Application Gateways
  • Azure Kubernetes Service (AKS)
  • Load balancers or NAT gateways

For this reason, it is often safer to size subnets larger than the theoretical minimum.

The usable IP calculator above accounts for Azure’s reserved addresses and shows how many IPs are actually available for your workloads.

Internal-use addresses in Azure

In addition to reserving IP addresses inside each subnet, Azure also uses a set of well-known internal IP addresses that are required for core platform functionality.

These addresses are not part of your subnet, but traffic to and from them is often required for virtual machines and platform services to function correctly.

When working with network security groups (NSGs), user-defined routes (UDRs), firewalls, or custom load balancer rules, it is important to avoid unintentionally blocking these addresses.

Blocking traffic to or from these addresses can cause subtle or hard-to-diagnose issues with native Azure services.

168.63.129.16 — Azure platform services

The IP address 168.63.129.16 is used by Azure for multiple critical platform functions, including:

  • Communication between the virtual machine and the Azure fabric controller
  • Azure DNS name resolution for resources that do not use a custom DNS server
  • Health probes from Azure Load Balancer to determine the health state of virtual machines
  • DHCP services used to assign and renew IP addresses
  • Guest Agent heartbeat and status reporting for virtual machines and PaaS roles

This address is required for normal VM operation and should generally be allowed in NSGs and firewall configurations.

169.254.169.254 — Azure Instance Metadata Service (IMDS)

The IP address 169.254.169.254 is used by the Azure Instance Metadata Service (IMDS).

IMDS provides information about the currently running virtual machine instance, including:

  • Instance identity and resource metadata
  • Networking configuration
  • Scheduled events
  • Managed identity tokens

Many tools, agents, and automation frameworks rely on IMDS. Blocking access to this address can break functionality related to identity, configuration, and automation.

Practical guidance

  • These addresses should not be used as destination IPs for customer workloads
  • Traffic to these addresses is typically required, not optional
  • Avoid blanket deny rules that block all outbound traffic without explicit exceptions
  • When using firewalls or custom routing, ensure these addresses remain reachable where required

For a complete and up-to-date list of Azure service IP ranges and tags, refer to Microsoft’s official documentation:

https://www.microsoft.com/en-us/download/details.aspx?id=56519

Special-purpose subnets in Azure

Some Azure services require dedicated subnets with specific names and minimum sizes. These subnets often have stricter requirements than general-purpose workloads and should be planned separately.

These requirements are service-specific and are not reflected in simple usable IP calculations.

AzureFirewallSubnet

Azure Firewall must be deployed into a dedicated subnet named AzureFirewallSubnet.

Key characteristics:

  • Must be named exactly AzureFirewallSubnet
  • Cannot contain any other resources
  • Requires a minimum subnet size (commonly /26 or larger, depending on SKU and features)
  • Consumes IP addresses internally for scaling and high availability

Because of these requirements, Azure Firewall subnets often need to be significantly larger than expected, even if only a single firewall instance is deployed.

GatewaySubnet

Azure VPN Gateways and ExpressRoute Gateways must be deployed into a subnet named GatewaySubnet.

Key characteristics:

  • Must be named exactly GatewaySubnet
  • Used exclusively for gateway resources
  • Requires sufficient IP space for:
    • Gateway instances
    • Future scaling
    • Active-active configurations

Undersizing the GatewaySubnet can limit scalability or require disruptive re-addressing later.

Practical guidance

  • Treat special-purpose subnets as infrastructure subnets, not application subnets
  • Size them conservatively to allow for growth and high availability
  • Do not reuse these subnets for other workloads
  • Always consult the latest Azure documentation for service-specific requirements

The usable IP calculator focuses on general subnet behavior. Special-purpose subnets should be planned according to the requirements of the service being deployed.