This chapter covers service tags in Azure Network Security Groups (NSGs), a critical feature for simplifying security rule management. Service tags are essential for the AZ-500 exam because they appear in multiple question domains, especially those related to network security and access control. Approximately 15-20% of exam questions touch on NSG concepts, with service tags being a key subtopic that candidates must understand thoroughly to avoid common pitfalls.
Jump to a section
Imagine a large corporate campus with many buildings (Azure regions) and departments (services like Azure SQL, Storage, Key Vault). Each department has its own entrance (IP address range). Instead of giving every employee a list of all department addresses that change frequently, the security office issues VIP passes. Each VIP pass has a department name printed on it, like "AzureSQL" or "Storage". When an employee shows their pass at a checkpoint (Network Security Group), the guard (Azure networking) looks up the current list of valid entrances for that department. If the employee's entrance matches one on the list, they are allowed in. The guard updates the list daily or when departments move. Employees don't need to know the specific addresses—they only need the pass name. This is exactly how service tags work: they abstract IP address ranges behind a logical tag name that Azure updates automatically when ranges change. The employee is your virtual machine or subnet, the guard is the NSG, and the VIP pass is the service tag. The checkpoint rules say "Allow AzureSQL" instead of "Allow 40.74.0.0/15" because the latter changes over time. The guard's list is updated by Azure without any action from the employee or the security office.
What Are Service Tags and Why Do They Exist?
Service tags are logical groupings of IP address prefixes for specific Azure services. They are used in NSG rules to allow or deny traffic to and from Azure services without hardcoding IP ranges. The primary reason for their existence is that Azure service IP ranges change over time due to scaling, new regions, and maintenance. If you hardcode IP ranges, you risk either blocking legitimate traffic or allowing unintended traffic after a range change. Service tags solve this by abstracting the IP ranges behind a tag name that Azure updates automatically.
How Service Tags Work Internally
When you create an NSG rule with a service tag as the source or destination, Azure translates that tag into the current set of IP prefixes for the corresponding service. This translation happens at the rule evaluation time. Azure maintains a mapping of each service tag to its current IP ranges, which are published weekly via the Azure IP Ranges and Service Tags JSON file. However, actual updates can occur more frequently if needed. The NSG does not store the IP ranges; it stores only the tag reference. When a packet arrives, the NSG evaluates the rule by checking whether the packet's source or destination IP falls within any of the prefixes associated with the tag at that moment.
Key Components, Values, Defaults, and Timers
Service Tags Available: Common tags include Internet, VirtualNetwork, AzureLoadBalancer, AzureTrafficManager, Storage, Sql, AzureKeyVault, AzureActiveDirectory, AppService, ApiManagement, AzureBackup, AzureSiteRecovery, AzureMonitor, AzureCloud, AzureConnectors, AzureCognitiveSearch, AzureContainerRegistry, AzureCosmosDB, AzureDataLake, AzureEventGrid, AzureIoTHub, AzureMachineLearning, AzureMediaServices, AzureServiceBus, AzureSignalR, AzureSqlDatabase, AzureStack, BatchNodeManagement, DataFactory, EventHub, GatewayManager, HDInsight, LogicApps, MicrosoftContainerRegistry, PowerBI, ServiceFabric, StorageSyncService, WindowsAdminCenter, and region-specific tags like Storage.WestUS.
Default Values: Service tags are not applied by default; you must explicitly add them to NSG rules. There is no default NSG rule that uses a service tag except the built-in rules (AllowVnetInBound, AllowAzureLoadBalancerInBound, DenyAllInbound).
Timers: IP range updates are published weekly, but Azure may update them more frequently. The NSG does not have a specific timer; it uses the latest published data at rule evaluation time. There is no caching period for service tag IP mappings within the NSG; they are resolved dynamically.
Configuration and Verification Commands
To create an NSG rule with a service tag using Azure CLI:
az network nsg rule create \
--resource-group myResourceGroup \
--nsg-name myNSG \
--name AllowSQLInbound \
--priority 100 \
--direction Inbound \
--access Allow \
--protocol Tcp \
--source-address-prefixes VirtualNetwork \
--source-port-ranges * \
--destination-address-prefixes Sql \
--destination-port-ranges 1433To verify existing rules:
az network nsg rule list --resource-group myResourceGroup --nsg-name myNSG --output tableIn the Azure portal, when adding a rule, you can select "Service Tag" from the Source or Destination dropdown and then choose the specific tag.
Interaction with Related Technologies
Application Security Groups (ASGs): ASGs group virtual machines by application roles (e.g., Web, App, DB). Service tags group Azure service IP ranges. They can be used together: an NSG rule can have an ASG as source and a service tag as destination.
Azure Firewall: Azure Firewall also supports service tags for network rules. However, Azure Firewall uses FQDN tags for application rules, which are different from service tags. Service tags in Azure Firewall work similarly to NSGs but at a higher layer.
Virtual Network Service Endpoints: Service endpoints extend your virtual network identity to Azure services. They use service tags to restrict traffic to specific services. When you enable a service endpoint for a subnet, the route table automatically adds a route with the service tag as the next hop.
Private Link: Private Link provides private connectivity to Azure services via private IP addresses. Service tags are not used with Private Link; instead, you use private endpoints. The exam may test the difference: service tags are for IP-based rules, while Private Link uses private IPs.
Detailed Mechanism of Service Tag Resolution
When an NSG rule is evaluated, the Azure network stack performs the following steps:
The NSG receives a packet (inbound or outbound).
It iterates through the rules in priority order.
For each rule, if the source or destination is a service tag, the NSG queries the Azure IP range service for the current prefixes of that tag.
The query result is cached for a short period (typically minutes) to improve performance.
The NSG checks if the packet's IP falls within any of the returned prefixes.
If a match is found, the rule's action (allow or deny) is applied.
If no match, the next rule is evaluated.
This process ensures that even if IP ranges change, the NSG uses the most up-to-date information within the cache lifetime.
Service Tag Types: Regional vs. Global
Some service tags are global (e.g., Sql, Storage), meaning they include all IP ranges for that service across all Azure regions. Others are regional (e.g., Storage.WestUS, Sql.EastUS), which include only the IP ranges for that service in a specific region. Regional tags are useful when you want to restrict traffic to a particular region for compliance or latency reasons. The exam may test the difference: global tags are broader, regional tags are more specific.
Limitations and Considerations
Service tags are not available for all Azure services. Only services that publish their IP ranges as part of the weekly JSON file have service tags.
Service tags cannot be used for user-defined routes (UDRs). They are only for NSG rules and Azure Firewall network rules.
Service tags are not supported for outbound rules in some older NSG versions but are fully supported now.
Custom service tags are not supported. You cannot create your own service tags; you can only use the ones provided by Azure.
Service tags do not support port filtering beyond the service's standard ports. For example, the Sql tag typically includes port 1433, but you can still specify a different destination port in the rule.
Exam-Relevant Numbers and Defaults
The VirtualNetwork tag includes the virtual network's address space, connected on-premises networks, and peered VNets.
The AzureLoadBalancer tag represents the health probe traffic from Azure Load Balancer.
The Internet tag represents any IP address outside the virtual network that can be reached via the internet.
Service tag IP ranges are published at https://www.microsoft.com/en-us/download/details.aspx?id=56519.
There is no cost for using service tags; they are a free feature of NSGs.
Identify Required Azure Service
Determine which Azure service you need to allow or deny traffic to/from. For example, if your application needs to access Azure SQL Database, you would use the `Sql` service tag. This step is crucial because using the wrong tag can either block traffic or allow unintended access. Consider whether you need a global tag (e.g., `Sql`) or a regional tag (e.g., `Sql.EastUS`) based on your deployment. The exam often tests this distinction: if you only need access to a specific region, use the regional tag to minimize exposure.
Create or Modify NSG Rule
Add a new rule to the NSG or modify an existing one. Set the source or destination to the service tag. For example, to allow inbound traffic from Azure Load Balancer, set source to `AzureLoadBalancer`. The rule priority must be lower (higher number) than the default deny rules (65500). Use a priority between 100 and 4096 for custom rules. The protocol and port ranges should match the service's requirements. For instance, SQL uses TCP 1433. Common mistake: using the wrong port or protocol, which causes the rule to not match.
Associate NSG with Subnet or NIC
The NSG must be associated with either a subnet or a network interface (NIC) for the rules to take effect. Subnet-level association applies to all VMs in that subnet, while NIC-level applies only to that specific VM. Service tags work the same way regardless of association level. However, note that if both subnet and NIC have NSGs, the NIC-level rules are evaluated after subnet-level rules. The exam may test this ordering: inbound traffic is evaluated by subnet NSG first, then NIC NSG; outbound is evaluated by NIC NSG first, then subnet NSG.
Test Connectivity
Verify that traffic is allowed or denied as expected. Use tools like `psping`, `Test-NetConnection`, or Azure Network Watcher's IP flow verify. For example, to test connectivity from a VM to Azure SQL, run `Test-NetConnection sqlserver.database.windows.net -Port 1433`. If the rule is correctly configured with the service tag, the connection should succeed. If it fails, check the rule priority, direction, and whether the correct service tag is used. Also ensure that the NSG is associated with the correct subnet or NIC.
Monitor and Audit Rules
Regularly review NSG rules to ensure they still meet security requirements. Use Azure Security Center's adaptive network hardening recommendations to tighten rules. Service tags reduce the need for frequent updates, but you should still audit for unused or overly permissive rules. The exam may ask about how to identify ineffective rules: use NSG flow logs and traffic analytics. Additionally, note that service tags themselves are not auditable via logs; only the resulting traffic is logged.
Scenario 1: Multi-Tier Web Application with Azure SQL Backend
A company runs a web application on Azure VMs in a virtual network. The application tier needs to communicate with Azure SQL Database. The security team wants to restrict outbound traffic from the application subnet to only Azure SQL, not any other internet destination. They configure an NSG on the application subnet with an outbound rule that uses the Sql service tag as the destination, allowing TCP port 1433. They also add a deny-all outbound rule at a lower priority. This ensures that only traffic to Azure SQL IP ranges is allowed. Over time, Azure SQL IP ranges change due to scaling, but the service tag automatically updates, so no manual intervention is needed. The team also uses regional tags (Sql.WestUS) to restrict traffic to the region where their database is deployed, reducing the attack surface. Common issue: if the application uses Azure SQL Managed Instance, the Sql tag does not include Managed Instance IPs; they must use the Sql tag with the appropriate regional variant or add the Managed Instance's public endpoint IP manually.
Scenario 2: On-Premises to Azure Site Recovery
An enterprise uses Azure Site Recovery (ASR) for disaster recovery of on-premises Hyper-V VMs. The ASR configuration requires outbound connectivity from the on-premises network to specific Azure IP ranges. Instead of updating firewall rules whenever IP ranges change, the network team uses the AzureSiteRecovery service tag in their on-premises firewall rules (if the firewall supports service tags, e.g., Azure Firewall or a partner that integrates with Azure). Alternatively, they configure a site-to-site VPN and use NSGs on the Azure side to allow inbound traffic from the on-premises IP ranges, but they still need to allow outbound from Azure to the ASR service. They create an NSG rule with source VirtualNetwork and destination AzureSiteRecovery. This simplifies management and ensures that ASR traffic is not disrupted during IP range updates. A common misconfiguration is forgetting to also allow traffic to AzureSiteRecovery for the target region if using cross-region replication.
Scenario 3: Restricting Access to Azure Key Vault
A DevOps team uses Azure Key Vault to store secrets. They want to allow access only from their virtual network and deny all public internet access. They enable the Key Vault firewall and select "Allow trusted Microsoft services" and "Add virtual network". They also configure an NSG on the subnet containing their application VMs with an outbound rule that uses the AzureKeyVault service tag as destination, allowing TCP port 443. However, they also need to ensure that the Key Vault's firewall allows the virtual network's IP range. The service tag simplifies the NSG rule, but the Key Vault firewall still requires explicit IP ranges or virtual network service endpoints. This scenario highlights that service tags are not a substitute for service-level firewalls; they are complementary. A common mistake is assuming that adding the service tag to an NSG automatically allows access to the service; the service itself may still block the traffic.
What AZ-500 Tests on Service Tags
The AZ-500 exam objectives for network security (Objective 3.1) include implementing and managing network security groups and service tags. Specifically, you must know:
How to configure NSG rules with service tags.
The difference between service tags, application security groups, and service endpoints.
Which service tags are available and their appropriate use cases.
How service tags interact with other Azure networking features like Azure Firewall and Private Link.
Common Wrong Answers and Why Candidates Choose Them
"Service tags can be created for custom IP ranges." This is false. Many candidates think they can define their own tags for on-premises networks. In reality, only Azure-defined tags exist. Custom tags are not supported.
"Service tags replace the need for NSGs entirely." No, service tags are used within NSG rules; they do not replace NSGs. Candidates often confuse service tags with Azure Firewall or network virtual appliances.
"Using a regional service tag is less secure than a global tag." Actually, regional tags are more restrictive and thus more secure. Candidates may think global is better because it covers all regions, but that increases attack surface.
"Service tags automatically allow traffic to the service without any additional configuration on the service side." This is incorrect. For example, using the Sql tag in an NSG rule does not bypass the Azure SQL firewall. The service itself still has its own access controls.
Specific Numbers and Terms That Appear on the Exam
The VirtualNetwork tag includes peered VNets and on-premises via VPN/ExpressRoute.
The AzureLoadBalancer tag is for health probe traffic, not client traffic.
The Internet tag is for any IP outside the VNet that is reachable via internet.
Service tags are not supported for user-defined routes (UDRs).
The default NSG rules include AllowVnetInBound, AllowAzureLoadBalancerInBound, and DenyAllInbound.
Service tag IP ranges are published weekly.
Edge Cases and Exceptions
Service tags for Azure PaaS services with Private Link: When using Private Link, you do not use service tags; you use private endpoints. The exam may present a scenario where you must choose between service tags and Private Link.
Service tags in Azure Firewall: Azure Firewall supports service tags for network rules but not for application rules (which use FQDN tags).
Service tags and service endpoints: Service endpoints use service tags to restrict traffic to specific services. Enabling a service endpoint adds a route with the service tag as next hop.
Service tags for Azure DevOps: There is no AzureDevOps service tag; you must use the AzureCloud tag or specific IP ranges.
How to Eliminate Wrong Answers
If the question asks about restricting traffic to a specific Azure service, look for the service tag option. If the option says "custom IP range" or "user-defined tag", it is likely wrong.
If the scenario involves on-premises connectivity, remember that service tags only apply to Azure services, not on-premises.
If the question mentions Private Link, the answer likely involves private endpoints, not service tags.
If the question is about outbound traffic from a VM to Azure Storage, the correct tag is Storage (or regional variant). If the answer suggests VirtualNetwork, that would be too broad.
Understanding the mechanism behind service tags—dynamic IP resolution—is key to answering questions correctly. Remember that service tags are a management convenience, not a security boundary in themselves; they must be combined with proper service-level firewalls.
Service tags are logical groupings of Azure service IP prefixes that are automatically updated by Azure.
They can only be used in NSG rules and Azure Firewall network rules, not in UDRs.
Common service tags include VirtualNetwork, AzureLoadBalancer, Internet, Storage, Sql, AzureKeyVault, and region-specific variants.
Service tags do not replace service-level firewalls; they only control network traffic at the NSG level.
The 'VirtualNetwork' tag includes peered VNets and on-premises networks connected via VPN/ExpressRoute.
Regional service tags (e.g., Storage.WestUS) are more restrictive than global tags and should be used when possible to minimize attack surface.
Service tag IP ranges are published weekly, but actual updates may occur more frequently.
There is no cost for using service tags in NSG rules.
Service tags are not available for all Azure services; only those that publish IP ranges.
Custom service tags are not supported; you cannot create your own tags.
These come up on the exam all the time. Here's how to tell them apart.
Service Tags
Represent IP prefixes of Azure services.
Used in NSG rules to simplify management of Azure service IP ranges.
Cannot be customized; only Azure-defined tags exist.
Ideal for allowing traffic to/from Azure PaaS services.
No cost for using service tags.
Application Security Groups (ASGs)
Represent groups of virtual machines based on application roles.
Used in NSG rules to simplify management of VM groupings.
Customizable; you define the VMs that belong to an ASG.
Ideal for micro-segmentation within a virtual network.
No cost for using ASGs.
Mistake
Service tags can be created for custom IP ranges, such as on-premises networks.
Correct
Service tags are predefined by Azure and cannot be customized. Only Microsoft-defined tags are available. For custom IP ranges, you must use standard IP address prefixes in NSG rules.
Mistake
Using a service tag in an NSG rule automatically grants access to the corresponding Azure service without any additional configuration.
Correct
Service tags only control network traffic at the NSG level. The Azure service itself (e.g., Azure SQL, Key Vault) has its own firewall and access policies that must be configured separately to allow traffic from your virtual network.
Mistake
Service tags are static and never change.
Correct
Service tags are dynamic; Azure updates the underlying IP prefixes as needed. The updates are published weekly, but changes can occur more frequently. The NSG resolves the tag to current prefixes at rule evaluation time.
Mistake
The 'VirtualNetwork' service tag only includes the virtual network's address space.
Correct
The 'VirtualNetwork' tag includes the virtual network's address space, all peered virtual networks, and any on-premises networks connected via VPN or ExpressRoute. It is broader than just the VNet itself.
Mistake
Service tags can be used in user-defined routes (UDRs) to control traffic routing.
Correct
Service tags are only supported in NSG rules and Azure Firewall network rules. They cannot be used in UDRs. For routing, you must use explicit IP prefixes or virtual network service endpoints.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Service tags represent IP prefixes of Azure services (e.g., Azure SQL, Storage) and are used to allow or deny traffic to/from those services. Application security groups (ASGs) represent groups of virtual machines based on application roles (e.g., Web, App, DB). ASGs are used to define micro-segmentation within a virtual network. While both are used in NSG rules, service tags are for Azure services, and ASGs are for your own VMs. They can be used together in the same rule.
No, the 'Internet' service tag represents any IP address outside your virtual network that is reachable via the internet. If you want to allow all internet traffic, you can use the 'Internet' tag as the source in an inbound rule. However, this is not recommended for security reasons; you should restrict to specific IP ranges if possible.
Azure publishes the IP ranges weekly via a JSON file, but actual updates can occur more frequently if needed. The NSG resolves the tag to current prefixes at rule evaluation time, so changes are reflected quickly. There is no manual action required to update the ranges.
Yes, there are both global and regional service tags. Global tags (e.g., 'Sql') include all IP ranges for that service across all regions. Regional tags (e.g., 'Sql.EastUS') include only the IP ranges for that service in a specific region. You should use regional tags when you want to restrict traffic to a particular region.
No, service tags are predefined by Azure and cannot be customized. For on-premises IP ranges, you must use explicit IP address prefixes in your NSG rules. Alternatively, you can use Azure Firewall with IP groups to manage custom IP ranges.
A service tag is a logical grouping of IP prefixes used in NSG rules to control traffic. A service endpoint extends your virtual network identity to an Azure service, allowing you to secure the service to your VNet. When you enable a service endpoint, it automatically adds a route with the service tag as the next hop. Service endpoints also use service tags to restrict traffic to the specific service.
Yes, Azure Firewall supports service tags for network rules. However, for application rules, Azure Firewall uses FQDN tags, which are different from service tags. Service tags in Azure Firewall work similarly to NSGs but at a higher layer.
You've just covered Service Tags in Network Security Groups — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?