This chapter covers Azure Service Tags, a critical feature for simplifying Network Security Group (NSG) rule creation in Azure. Service Tags allow you to define network access controls based on Azure services rather than individual IP address ranges, reducing management overhead and ensuring rules remain up-to-date as Azure services evolve. On the AZ-104 exam, Service Tags appear in approximately 5-10% of networking questions, often integrated with NSG rules, Azure Firewall, and routing scenarios. Mastering this topic is essential for configuring secure and maintainable network architectures in Azure.
Jump to a section
Imagine a large corporate mailroom that receives thousands of packages daily. Without a system, the mailroom staff would have to inspect each package individually to decide whether it's legitimate or spam. This is time-consuming and error-prone. Now, suppose the mailroom subscribes to a service that maintains a dynamic list of pre-approved senders, such as 'All FedEx deliveries' or 'All packages from Amazon Logistics.' Instead of checking each package manually, the mailroom simply looks at the sender field on the label and compares it to the list. If the sender matches 'FedEx,' the package is automatically routed to the recipient. If it doesn't match any approved sender, it's flagged for manual review. The key is that the list is maintained externally and updated automatically as new carriers are added or removed. The mailroom doesn't need to know every FedEx truck route or warehouse—it just trusts the tag 'FedEx' and lets the service handle the details. In Azure, Service Tags work exactly like this: they are predefined, dynamically updated labels representing groups of Azure service IP ranges. When you create a Network Security Group (NSG) rule, you can specify a Service Tag instead of a list of individual IP addresses. Azure automatically updates the tag's underlying IP ranges as services scale or change regions. This eliminates the need to manually track IP changes for services like Azure SQL Database, Azure Storage, or Azure Key Vault. The NSG rule uses the tag to permit or deny traffic to that service without you ever needing to know the actual IP prefixes. The mechanism is simple: the NSG evaluates the rule, resolves the tag to the current set of IP prefixes, and applies the rule accordingly. This is far more efficient and less error-prone than managing static IP lists, especially in dynamic cloud environments where IP ranges change frequently.
What Are Service Tags and Why Do They Exist?
Azure Service Tags are predefined, dynamically updated labels that represent groups of IP address prefixes for specific Azure services. They exist to solve a fundamental problem: Azure services like Storage, SQL Database, and Azure DevOps use a large and frequently changing set of public IP addresses. Manually tracking these IP ranges in NSG rules is impractical, error-prone, and requires constant updates. Service Tags abstract this complexity by providing a single, human-readable label that Azure automatically maintains.
For example, instead of listing all IP ranges for Azure SQL Database in the East US region (which can change weekly), you can use the Service Tag Sql.EastUS in an NSG rule. Azure resolves this tag to the current IP prefixes at the time the rule is evaluated.
How Service Tags Work Internally
Service Tags are implemented as a feature of the Azure network fabric. When you create an NSG rule with a Service Tag, the rule is stored in the NSG's rule set. When a packet arrives at the network interface or subnet associated with the NSG, the Azure network controller evaluates the rule. It performs a lookup on the Service Tag to retrieve the current set of IP prefixes for that tag. This lookup is done against a distributed, highly available service that tracks all Azure public IP allocations.
The resolution is performed per region and per service. For example, the Storage.WestUS tag resolves to all IP prefixes used by Azure Storage in the West US region. The resolution is cached for a short period (typically minutes) to optimize performance, but it is updated frequently to reflect changes.
Importantly, Service Tags can be used as source or destination in NSG rules. For inbound rules, you typically use a Service Tag as the source (e.g., allow inbound from Internet tag for web servers). For outbound rules, you use a Service Tag as the destination (e.g., allow outbound to Storage.WestUS for a VM accessing Azure Storage).
Key Components and Values
Azure provides a comprehensive set of Service Tags. The most commonly tested on the AZ-104 exam include:
`Internet`: Represents all public internet IP addresses. Equivalent to 0.0.0.0/0. Note: It does not include Azure services' public endpoints.
`VirtualNetwork`: Represents all virtual network address spaces, including connected VNets (peered), on-premises via VPN/ExpressRoute, and address spaces from any connected VNets. This is useful for allowing traffic within your network.
`AzureLoadBalancer`: Represents the Azure infrastructure load balancer's health probe traffic source. This tag is used to allow health probe traffic from the Azure load balancer to your VMs.
`AzureCloud`: Represents all Azure public IP addresses for all services in a region or globally. For example, AzureCloud.WestUS includes all Azure service IPs in West US. Use with caution as it is broad.
Service-specific tags: Storage, Sql, AppService, KeyVault, AzureActiveDirectory, AzureBackup, AzureMonitor, AzureTrafficManager, AzureSiteRecovery, AzureDevOps, CognitiveServices, EventHub, ServiceBus, ApiManagement, ContainerRegistry, DataFactory, HDInsight, MachineLearning, etc.
Each service tag can be scoped to a region by appending the region name (e.g., Storage.EastUS). Global service tags (without region) cover all regions.
Configuration and Verification
Service Tags are used in NSG rules via the Azure portal, Azure CLI, PowerShell, or ARM templates. In the portal, when adding a rule, you select 'Service Tag' from the Source or Destination dropdown, then choose the tag from a list.
Example CLI command to create an NSG rule allowing outbound HTTPS to Azure Storage in West US:
az network nsg rule create \
--resource-group myResourceGroup \
--nsg-name myNSG \
--name AllowStorageWestUS \
--direction Outbound \
--priority 100 \
--source-address-prefixes VirtualNetwork \
--source-port-ranges '*' \
--destination-address-prefixes Storage.WestUS \
--destination-port-ranges 443 \
--protocol Tcp \
--access AllowTo verify the current IP ranges for a Service Tag, you can use the following Azure CLI command (requires az network list-service-tags):
az network list-service-tags --location westus --query "values[?name=='Storage.WestUS'].properties.addressPrefixes" --output tableThis returns a list of CIDR ranges currently assigned to that tag.
Interaction with Related Technologies
Service Tags are not just limited to NSGs. They also work with:
Azure Firewall: In Azure Firewall rules, you can specify Service Tags as source or destination (e.g., allow outbound to Storage).
Route Tables: You cannot directly use Service Tags in user-defined routes (UDRs). However, you can use Service Tags in combination with Azure Firewall or NVAs to direct traffic.
Virtual Network Service Endpoints: Service Tags are complementary to Service Endpoints. Service Endpoints extend your VNet identity to Azure services, while Service Tags control access at the NSG level. They are often used together for defense in depth.
Private Endpoints: When using Private Endpoints, traffic to the service goes over the Microsoft backbone and does not traverse the internet. Service Tags for that service become irrelevant for that traffic because the destination IP is within the VNet. However, Service Tags for other services still apply.
Limitations and Considerations
Service Tags are only for Azure public cloud regions. They do not cover Azure Government or Azure China clouds (separate tag sets exist).
Service Tags cannot be used for on-premises IP ranges or third-party services.
The Internet tag does not include Azure services; use AzureCloud if you need to allow all Azure public IPs.
Service Tags are resolved at the time of rule evaluation. If a service's IP range changes, existing flows may continue until the cached resolution expires (typically a few minutes).
You cannot create custom Service Tags. For custom IP groups, use Application Security Groups (ASGs) or IP Groups.
Service Tags are not available for all Azure services. For services without a tag, you must use IP ranges from the weekly published Azure IP Ranges JSON file.
Defaults and Timers
There is no default Service Tag for all Azure services; you must explicitly choose the tag.
The IP prefix resolution cache is refreshed every 5-15 minutes internally, but this is not configurable.
When a new region is added, Service Tags for that region become available within hours.
Exam Tip
The AZ-104 exam frequently tests your ability to choose the correct Service Tag for a given scenario. For example, if a VM needs to access Azure SQL Database, you would use Sql (or Sql.<region>) as the destination in an outbound rule. If the question mentions health probes from Azure Load Balancer, use AzureLoadBalancer as the source. If the scenario involves allowing all Azure services within a region, use AzureCloud.<region> but be aware of its broad scope.
Identify Required Service Access
Determine which Azure service your resource needs to communicate with. For example, a VM in a subnet needs to upload logs to Azure Storage. The service is Azure Storage. Also determine the direction: outbound from VM to Storage. Note the region of the storage account (e.g., West US). This step is critical because choosing the wrong Service Tag (e.g., using `Storage` without region when the storage is in a specific region) may still work but is less precise and could allow traffic to storage in other regions, increasing attack surface.
Create or Update NSG Rule with Service Tag
In the NSG associated with the VM's subnet, add an outbound security rule. Set the destination to 'Service Tag' and choose the appropriate tag, e.g., `Storage.WestUS`. Set the destination port to 443 (HTTPS) for REST API calls. Set the protocol to TCP. Set the action to Allow. The priority should be lower (higher number) than any deny-all rule. For example, priority 100. This rule will be evaluated before any higher-numbered (lower priority) rules.
Rule Evaluation at Packet Level
When the VM sends a packet to the storage account's IP (e.g., 52.239.184.0/23), the Azure network controller intercepts the packet and checks the NSG rules on the subnet. It evaluates rules in priority order. When it hits the rule with `Storage.WestUS`, it resolves that tag to the current list of IP prefixes for Storage in West US. If the destination IP matches one of those prefixes, the rule applies and the packet is allowed. If not, evaluation continues to the next rule. The resolution is cached for efficiency.
Dynamic Update of IP Ranges
After the rule is created, Azure periodically updates the IP prefix list for each Service Tag. For example, if Microsoft adds a new storage cluster in West US, the `Storage.WestUS` tag's prefix list is updated within hours. The NSG rule does not need modification. However, existing TCP connections may still use the old IP until the connection terminates. New connections will use the updated list. This dynamic nature is a key advantage over static IP lists.
Verification and Troubleshooting
To verify the rule is working, you can use Azure Monitor or NSG flow logs to see allowed/denied traffic. If traffic is denied, check that the Service Tag is correct (e.g., ensure you used `Storage.WestUS` and not `Storage.EastUS`). Also verify that the rule priority is appropriate and that no higher-priority deny rule blocks the traffic. Use the CLI command `az network list-service-tags` to see the current IP ranges for the tag. If the storage account uses a private endpoint, the traffic will not use the Service Tag because the destination IP is within the VNet; in that case, the NSG rule must be adjusted accordingly.
Enterprise Scenario 1: Secure Web Application Accessing Azure SQL Database
A financial services company hosts a web application on Azure VMs in a subnet. The application needs to connect to an Azure SQL Database in the same region (East US) for data storage. The security team wants to ensure that only the application subnet can access the SQL database, and that no other internet traffic can reach it. They configure an NSG on the subnet with an outbound rule allowing traffic to Sql.EastUS on port 1433. On the SQL server side, they set firewall rules to allow only the application subnet's IP range. However, they also need to allow inbound health probe traffic from Azure Load Balancer. They add an inbound rule with source AzureLoadBalancer and destination VirtualNetwork on port 443. This setup works well because Service Tags abstract the constantly changing SQL IP ranges. At scale, with hundreds of VMs, manual IP management would be impossible. A common misconfiguration is using AzureCloud.EastUS instead of Sql.EastUS, which opens the subnet to all Azure services in the region, violating least privilege. Performance is not impacted because Service Tag resolution is fast and cached.
Enterprise Scenario 2: Hybrid Network with Azure Backup
A retail company uses Azure Backup to back up on-premises servers to a Recovery Services vault in Azure. The on-premises network connects to Azure via a Site-to-Site VPN. The Azure Backup service needs outbound internet access to Azure Backup endpoints. The company's NSG on the gateway subnet must allow outbound traffic to AzureBackup and AzureSiteRecovery Service Tags. Additionally, they need to allow traffic to Storage for backup data. They create NSG rules with these tags. A common pitfall is forgetting to include the region-specific tags (e.g., Storage.WestUS), which may cause backups to fail if the vault is in a different region. Also, the AzureBackup tag includes IPs for the backup service control plane, but the actual backup data goes to Azure Storage, so both tags are needed. At scale, with multiple vaults across regions, using global tags (without region) is simpler but less secure. The company opts for regional tags to minimize exposure.
Scenario 3: DevOps Pipeline Access to Azure DevOps
A software company uses Azure DevOps for CI/CD. Build agents run on Azure VMs in a VNet. The agents need to access Azure DevOps services (e.g., to fetch code, publish artifacts). The NSG on the agent subnet must allow outbound traffic to AzureDevOps on ports 443 and 8080 (for agent communication). They also need to allow traffic to Storage for artifact storage. They create rules with these Service Tags. A common issue is that the AzureDevOps tag only covers the control plane; for some scenarios, additional tags like AzureCloud may be needed, but the exam focuses on the specific tag. Misconfiguration leads to build failures that are hard to diagnose. Using NSG flow logs helps identify blocked traffic. They also implement Azure Firewall with Service Tags for centralized logging.
What AZ-104 Tests on Service Tags (Objective 4.1: Configure and Manage Virtual Networking)
The exam expects you to:
Identify the correct Service Tag for a given scenario (e.g., Sql for Azure SQL, Storage for Azure Storage, AzureLoadBalancer for health probes).
Understand the difference between regional and global Service Tags.
Know that Service Tags are used in NSG rules and Azure Firewall rules.
Recognize that Service Tags are dynamically updated and do not require manual intervention.
Understand that Internet tag includes all public IPs except Azure services, and VirtualNetwork includes peered and on-premises address spaces.
Common Wrong Answers and Why Candidates Choose Them
Choosing `AzureCloud` instead of a specific service tag – Candidates often select AzureCloud because it seems comprehensive. However, the exam emphasizes least privilege. If a VM needs to access only Azure SQL, the correct tag is Sql, not AzureCloud, which opens traffic to all Azure services.
Using `Internet` tag for Azure service access – The Internet tag does not include Azure service IPs. Candidates mistakenly think it covers everything. The correct tag for an Azure service is the service-specific tag.
Forgetting to specify region – Many questions include a region-specific storage account or SQL database. The correct answer often requires a regional tag like Storage.EastUS. A global tag like Storage would work but is less secure and may be considered incorrect in a least-privilege context.
Using Service Tags in route tables – Service Tags cannot be used in User-Defined Routes (UDRs). Candidates may incorrectly think they can. The exam tests this limitation.
Specific Numbers and Terms on the Exam
The AzureLoadBalancer tag is specifically for health probe traffic from the Azure load balancer infrastructure.
The VirtualNetwork tag includes address spaces from peered VNets and on-premises (via VPN/ExpressRoute).
Service Tags are available for NSGs and Azure Firewall, but not for UDRs.
The command az network list-service-tags is used to retrieve current IP ranges.
Edge Cases and Exceptions
Private Endpoints: If a resource uses a Private Endpoint, traffic to that service stays within the VNet and does not use the service's public IPs. Service Tags for that service are irrelevant; you must use the private endpoint's IP address in NSG rules.
Azure Government: Service Tags for Azure Government clouds have different names (e.g., Storage.USGovVirginia). The exam focuses on public cloud.
Service Tags for global services: Some services like Azure Active Directory (AzureActiveDirectory) are global and do not have regional variants.
How to Eliminate Wrong Answers
If the question mentions 'health probes', look for AzureLoadBalancer as source.
If the question says 'allow outbound to Azure Storage in West US', eliminate any answer that does not include Storage and WestUS.
If the question asks for the 'most secure' option, choose the specific service tag over AzureCloud.
If the question involves a route table, eliminate any answer that mentions Service Tags.
Service Tags are predefined, dynamically updated labels for Azure service IP ranges.
Use Service Tags in NSG rules to simplify rule creation and maintenance.
Common Service Tags: Internet, VirtualNetwork, AzureLoadBalancer, AzureCloud, Storage, Sql, AzureBackup, etc.
Always prefer regional Service Tags (e.g., Storage.EastUS) for least privilege over global tags.
Service Tags cannot be used in route tables (UDRs).
The 'Internet' tag does not include Azure services; use service-specific tags or AzureCloud.
Service Tags are resolved at rule evaluation time; IP changes are automatically reflected.
For on-premises or third-party IPs, you must use explicit IP ranges or IP Groups.
These come up on the exam all the time. Here's how to tell them apart.
Service Tags
Predefined by Microsoft for Azure services.
Dynamically updated with IP ranges of Azure services.
Used in NSG rules as source/destination address prefixes.
Cannot be customised; only Microsoft-defined tags exist.
Ideal for allowing traffic to Azure PaaS services (e.g., Storage, SQL).
Application Security Groups (ASGs)
User-defined groups of VMs based on application roles.
Static membership defined by you; IPs do not change automatically.
Used in NSG rules as source/destination (not address prefixes, but as group of NICs).
Fully customisable; you create and manage ASGs.
Ideal for micro-segmentation within your VNet (e.g., web tier to app tier).
Mistake
Service Tags can be used in User-Defined Routes (UDRs).
Correct
Service Tags are only supported in Network Security Group (NSG) rules and Azure Firewall rules. They cannot be used as address prefixes in route tables. For UDRs, you must specify explicit IP prefixes or use Virtual Network Gateway routes.
Mistake
The 'Internet' Service Tag includes all Azure services' public endpoints.
Correct
The 'Internet' tag represents all public IP addresses except those owned by Azure services. To allow traffic to Azure services, you must use the service-specific tag (e.g., 'Storage', 'Sql') or 'AzureCloud' which includes all Azure public IPs.
Mistake
Service Tags are static and rarely change.
Correct
Service Tags are dynamically updated by Azure as IP ranges change. Azure publishes weekly updates to the IP ranges JSON file, but the tags themselves are updated more frequently in the backend. You do not need to manually update NSG rules when IPs change.
Mistake
Using a regional Service Tag (e.g., 'Storage.EastUS') is less secure than a global tag.
Correct
Regional Service Tags are more secure because they restrict traffic to a specific region, reducing the attack surface. Global tags (e.g., 'Storage') include all regions, which may allow unintended access to resources in other regions.
Mistake
Service Tags can be created customly by users.
Correct
Service Tags are predefined by Microsoft and cannot be created or modified by users. For custom groupings of IP addresses, use Application Security Groups (ASGs) or IP Groups.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Service Tags are Microsoft-managed labels for Azure service IP ranges, used to allow or deny traffic to/from Azure services. Application Security Groups (ASGs) are user-defined groups of VM NICs, used to apply security rules based on application roles (e.g., web servers, database servers). Service Tags are for external Azure services; ASGs are for internal segmentation within your VNet.
Yes. For example, to allow health probes from Azure Load Balancer, set the source to 'AzureLoadBalancer' Service Tag. Similarly, you can allow inbound traffic from the internet using the 'Internet' tag, but note that this does not include Azure services.
Azure updates Service Tags dynamically as IP ranges change. The underlying IP prefix data is published weekly in the Azure IP Ranges JSON file, but the Service Tag resolution in NSGs is updated more frequently (typically within hours of a change). You do not need to modify NSG rules when IPs change.
Possible reasons: (1) The rule priority is too low (higher number) and a deny rule with higher priority blocks traffic. (2) The Service Tag is regional and the service is in a different region. (3) The service is accessed via a private endpoint; in that case, the destination IP is within the VNet and the Service Tag does not apply. (4) The NSG is not associated with the correct subnet or NIC.
Yes. Azure Firewall supports Service Tags in both network and application rules. You can specify a Service Tag as the destination address in a network rule (e.g., allow outbound to 'Storage'). This simplifies firewall rule management.
The 'VirtualNetwork' tag represents all virtual network address spaces within the same VNet, including peered VNets, and on-premises networks connected via VPN or ExpressRoute. It is useful for allowing traffic within your entire network topology without specifying individual CIDR blocks.
Use the Azure CLI command: `az network list-service-tags --location <region> --query "values[?name=='<ServiceTagName>'].properties.addressPrefixes" --output table`. Replace `<region>` and `<ServiceTagName>` with appropriate values.
You've just covered Service Tags in NSG Rules — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?