When you secure cloud infrastructure, you have to write precise firewall rules for the cloud services your workloads talk to. Both Microsoft Azure and Amazon Web Services publish a way to identify their service IP addresses: Azure Service Tags and AWS IP Ranges. Understanding both is the difference between network policy that stays correct on its own and policy that quietly drifts out of date.
What are Azure Service Tags?
An Azure Service Tag is a named group of IP address prefixes for a given Azure service. Microsoft maintains the abstraction so you can reference a logical name instead of tracking hundreds of individual prefixes by hand. Point a rule at the tag and it always resolves to the current set of ranges for that service.
Service Tags cover a wide range of services, including:
- AzureCloud — all Azure datacentre IP addresses
- Storage — Azure Storage service IP addresses
- Sql — Azure SQL Database IP addresses
- AzureKeyVault — Azure Key Vault IP addresses
- EventHub — Azure Event Hubs IP addresses
- ServiceBus — Azure Service Bus IP addresses
Many tags are region-specific, which gives you granular control. For example,
Storage.WestUS contains only the storage service ranges in the West US region.
What are AWS IP Ranges?
AWS takes a different approach. Rather than named tags, AWS publishes a single JSON document listing every IP range it uses across all regions and services, with metadata describing each one. You consume the document and filter it down to the ranges you care about.
The AWS IP Ranges document includes:
- Service identifiers — EC2, S3, CloudFront, Route 53, and so on
- Region information — us-east-1, eu-west-1, ap-southeast-2, and so on
- Network border groups — a subset of regions for specific services
- Create date and sync token — for tracking updates
The metadata lets you build very specific filters — for example, allow only S3 traffic from us-east-1 while leaving other services and regions out.
How they’re used
Azure Service Tags
Service Tags are used in Network Security Groups (NSGs), Azure Firewall rules, and route tables. You write a rule that references the tag instead of a list of addresses:
Source: Any
Destination: Storage.WestEurope
Port: 443
Protocol: TCP
Action: AllowThat rule automatically covers every Azure Storage range in West Europe, with no list to maintain. Service Tags also work in user-defined routes (UDRs) and virtual network service endpoints.
AWS IP Ranges
AWS IP Ranges take more work to consume but give you more flexibility. Most teams download the JSON, extract the ranges they need, and feed them into:
- Security Group rules
- Network ACL entries
- Route table entries
- Third-party firewall configurations
- Load balancer configurations
Why teams use them
Simpler management
Both systems remove the need to manually track and update IP addresses as cloud providers grow their footprint. Providers add ranges continuously, so hand-kept lists are obsolete almost as soon as they’re written.
Stronger security
Building on the official ranges keeps your rules current and complete. That reduces both the connectivity breakage and the security gaps that come from stale address lists.
Operational efficiency
Tags and ranges cut configuration complexity, reduce human error, and speed up rollout of consistent policy across environments.
Where IP-range rules beat FQDN rules
IP-range filtering and hostname (FQDN) filtering solve different problems, and the right answer is usually “both”. For traffic to a cloud provider’s own services, IP ranges have real advantages:
- No DNS dependency. IP-based rules filter at the network layer with no DNS lookup in the path, so there’s no resolver latency or availability to depend on.
- Smaller attack surface. Filtering below the application layer sidesteps DNS hijacking and cache-poisoning tricks aimed at hostname rules.
- Broad device support. Almost every firewall handles IP filtering efficiently; rich FQDN filtering is less universal.
- Consistent behaviour. IP ranges behave the same regardless of resolver configuration or caching.
For general internet egress to arbitrary SaaS endpoints, identity-aware hostname (SNI/FQDN) filtering is still the right tool — you want both in the box.
Key differences between the two approaches
Format and structure
Service Tags use human-readable names that hide the underlying complexity. AWS publishes raw range data that you process yourself. Azure is friendlier for straightforward cases; AWS gives you more room for complex filtering.
Granularity
AWS IP Ranges carry more metadata — network border groups and per-service breakdowns. Service Tags offer broader categories with regional variants but less service-level detail.
Update mechanism
Service Tags update automatically inside the Azure platform — nothing to do on your side. AWS expects you to re-download and re-process the JSON periodically to stay current.
Integration
Service Tags integrate natively with Azure networking through a name reference. AWS IP Ranges need automation to extract and apply the right addresses to your configuration.
Access methods and update frequency
Azure Service Tags
- Azure Portal — browse tags while building NSG rules
- REST API — programmatic access via Azure Resource Manager
- PowerShell / CLI — command-line automation
- JSON downloads — weekly files for offline processing
Microsoft updates tags automatically inside Azure and publishes the downloadable JSON weekly, typically on Mondays.
AWS IP Ranges
- Direct download —
https://ip-ranges.amazonaws.com/ip-ranges.json - SNS notifications — subscribe to update events
- API integration — automated download and processing
- Third-party tooling — community and commercial processors
AWS updates the document as needed — usually weekly, sometimes more often during rapid expansion. The sync token and create date let you confirm you’re on the latest data.
Best practices
Automate ingestion
Consume the ranges through automation — Azure’s native integration or an AWS processing pipeline — so policy stays effective as the underlying infrastructure changes.
Test before production
Validate range-based rules in a non-production environment first. It surfaces connectivity issues before they reach live workloads.
Monitor for change
Watch for range updates that could affect existing connections — particularly on the AWS side, where manual processing can introduce lag between an update and its rollout.
The cost catch with cloud-native firewalls
Service Tags and AWS IP Ranges integrate cleanly with the cloud-native firewalls — Azure Firewall, AWS Network Firewall — but those services price on a model that punishes traffic:
- Azure Firewall — an hourly deployment charge plus a per-GB data-processing charge on everything it inspects.
- AWS Network Firewall — a per-endpoint hourly charge plus a per-GB data-processing charge, and the per-AZ endpoint model multiplies that across availability zones.
The base charge is predictable. The per-GB data-processing tax is the line that grows with every workload you put behind it, and it’s the same whether the firewall did anything useful with the packet or not.
Managing both from one place with Enforza
Enforza’s object manager imports both Azure Service Tags and AWS IP Ranges, so you build cross-cloud network objects from the providers’ own published data in one console — no separate tooling, no hand-processing JSON.
How it works
Enforza synchronises with Microsoft’s weekly Service Tag publications and AWS’s IP Ranges document, and resolves a tag or range to its actual prefixes when you reference it in a policy. Your rules stay current without manual intervention.
Why it matters
- Cut the cloud-firewall bill 60–80%. Flat per-firewall licensing with no per-GB data-processing tax, instead of the metered model the cloud-native services use.
- One place for cross-cloud objects. Service Tags and IP Ranges side by side, applied consistently across AWS, Azure, and GCP.
- Automatic updates. Stay aligned with provider IP changes without manual re-import.
- The control you actually need. Egress, ingress, and east-west filtering, identity-aware hostname (SNI/FQDN) rules, secure NAT, and compliance — the ~98% most teams use, without the bloat (or invoice) of a six-figure platform.
Enforza is the way to replace your cloud-native firewall without going full-blown enterprise security vendor: more capability than the CSP firewall, far less cost than a mega-NGFW platform.
Conclusion
Azure Service Tags and AWS IP Ranges both exist to keep network policy correct as cloud infrastructure shifts under it. Azure favours ease of use and automatic updates; AWS favours detailed, flexible control. Whichever clouds you run, moving off hand-kept IP lists and onto the providers’ official, automated sources is a basic step toward mature cloud security — and consuming both from a single firewall, on flat pricing, is how you do it without the cloud tax.
