CIDR block for azrecloud.eastus

Hello Desmond Sindatry,

Greetings! Thanks for raising this question in the Q&A forum.

The core challenge here is that Azure does not publish a single summarized CIDR block (or a small set of supernet CIDRs) for the AzureCloud.eastus2 service tag. The 900+ individual prefixes listed in the weekly JSON file are the authoritative, canonical representation of that tag's address space, and Microsoft deliberately publishes them at this granularity because the underlying IP ranges span non-contiguous address blocks across many different Azure infrastructure components. There is no smaller set of supernets that covers exactly those ranges without also capturing large amounts of unrelated IP space.

That said, there are two recommended approaches to reduce the operational burden of maintaining this allowlist.

1. Use Azure Service Tags natively in your firewall or NSG rules. If your application is protected by Azure Firewall, a Network Security Group, or a compatible third-party firewall that supports Azure Service Tags, you can reference AzureCloud.eastus2 directly as a rule destination or source instead of maintaining individual IP entries. Azure automatically keeps the underlying prefixes up to date, so you never need to touch the rule again when IPs change. You can configure this in Azure Firewall via the portal, PowerShell, or Azure CLI as described here: Azure Firewall service tags.

Automate allowlist refresh using the Service Tag Discovery API. If your firewall sits on-premises or does not support Azure Service Tags natively, the recommended approach is to stop maintaining the list by hand and instead automate its refresh using the Service Tag Discovery REST API or the Get-AzNetworkServiceTag PowerShell cmdlet. This lets you pull the current prefixes for AzureCloud.eastus2 on a weekly schedule, diff against your existing rules, and apply only the changes. New IP ranges appear in the weekly JSON file at least one week before Azure begins using them, which gives you a safe update window. Example PowerShell to retrieve the current prefixes:

$tags = Get-AzNetworkServiceTag -Location eastus2
$eastus2 = $tags.Values | Where-Object { $_.Name -eq "AzureCloud.eastus2" }
$eastus2.Properties.AddressPrefixes

You can also retrieve the same data via the REST API:

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/eastus2/serviceTags?api-version=2023-09-01

Consider whether a broader or more specific service tag meets your actual need. If your allowlist exists to permit traffic from a particular Azure service (for example, Azure Storage, Azure SQL, Azure Monitor) rather than all Azure datacenter IPs in East US 2, you may be able to replace AzureCloud.eastus2 with the narrower, service-specific tag such as Storage.EastUS2 or Sql.EastUS2. This would reduce the number of prefixes significantly and is a better security posture than allowing the full AzureCloud range. Reference: Azure virtual network service tags overview.

Keep the JSON file download automated if manual API access is not feasible. The weekly JSON file is published at https://www.microsoft.com/en-us/download/details.aspx?id=56519. The filename rotates weekly (format ServiceTags_Public_YYYYMMDD.json), so you should retrieve the current URL programmatically from the download page rather than hardcoding it, then parse the AzureCloud.eastus2 entry from the values[] array and sync changes to your firewall.

To summarize: a single CIDR supernet for AzureCloud.eastus2 is not available and will not be published by Microsoft, since the address space is non-contiguous by design. The best path forward is to use native service tag support in your firewall if available, or automate the weekly sync using the Discovery API or JSON file.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.