Azure IP Ranges and Service Tags: What Network Engineers Need to Know

Microsoft Azure takes a fundamentally different approach to publishing its IP ranges compared to AWS and Google Cloud. Rather than a flat list of prefixes with service labels, Azure uses Service Tags — named identifiers representing groups of IP address ranges for specific Azure services. A Service Tag in a Network Security Group rule automatically updates when the underlying IP ranges change.

What Service Tags Are

A Service Tag is a label like AzureCloud, Storage.EastUS, or AzureActiveDirectory. When you add a Service Tag to an NSG rule, Azure resolves it to the current set of IP prefixes for that service at rule evaluation time. You do not need to maintain a list of IP addresses — Azure updates the resolution automatically as the address space changes.

Common Service Tags

• Internet — All public internet addresses (anything outside the VNet)
• VirtualNetwork — The current VNet and all peered VNets
• AzureCloud — All Azure datacenter IP ranges
• AzureLoadBalancer — The Azure load balancer source IP (for health probes)
• Storage or Storage.WestEurope — Azure Blob, Queue, Table, and File storage
• Sql — Azure SQL Database and SQL Managed Instance endpoints
• AzureActiveDirectory — Azure AD and related services
• AppService — Azure App Service outbound IPs

When You Need the Raw IP Ranges

Service Tags work inside Azure NSG rules and Azure Firewall policies. For external firewalls — on-premises infrastructure, third-party cloud firewalls, or network equipment that does not understand Service Tags — you need the raw IP ranges. Microsoft publishes these weekly as a downloadable JSON file. The Azure IP ranges page explains how to access and interpret this file.

Comparing to AWS and GCP Approaches

AWS publishes a single JSON endpoint with all prefixes labeled by service — simpler to parse programmatically. GCP also uses a single JSON endpoint. Azure's Service Tag system is more powerful for native Azure policy enforcement but requires an extra step when integrating with non-Azure tools. For organisations running in multiple clouds, you need separate tooling for each provider's format. A unified approach is to pull all three feeds, normalise them, and store them in your IPAM system.

Practical Recommendation

Use Service Tags for all NSG and Azure Firewall rules within Azure — they are lower maintenance and self-updating. For on-premises firewall rules governing what Azure traffic is allowed into your data centre, pull the weekly JSON feed, diff it against your previous version, and apply changes as part of a change management process. Automating this diff and the resulting firewall update is a worthwhile investment for organisations with active Azure deployments.