This chapter covers Application Security Groups (ASGs), a crucial Azure networking feature that simplifies managing network security for groups of virtual machines. On the AZ-500 exam, ASGs appear in approximately 5-10% of questions, often in scenarios involving NSG rule management, VM grouping, and automation. Understanding ASGs is essential for the 'Implement and manage network security' objective (3.1) because they directly reduce administrative overhead and enable scalable, IP-agnostic security policies.
Jump to a section
Imagine a large office building with multiple companies. Each company has its own set of employees and servers. Instead of managing access by individual employee IDs (IP addresses), the building uses colored wristbands that indicate which floor and section each employee is allowed to access. For example, a blue wristband allows access to the finance floor, a red wristband to the marketing floor. The wristband is assigned to the employee based on their role, not their specific desk number. When an employee arrives at a door, the door reads the wristband color and decides whether to open. If the employee changes desks, they keep the same wristband because their role hasn't changed. This is exactly how Application Security Groups work in Azure: you create an ASG (wristband color), assign it to a VM's NIC (employee), and then create Network Security Group rules that reference the ASG rather than the VM's specific IP address. If the VM moves or its IP changes, the ASG rule still applies because the VM still has the same ASG assignment. This decouples security rules from IP addresses, making management much easier in dynamic environments.
What Are Application Security Groups?
Application Security Groups (ASGs) are Azure objects that allow you to group virtual machines (or other Azure resources that support ASGs) logically, based on their application function, such as 'web servers', 'application servers', or 'database servers'. Instead of writing Network Security Group (NSG) rules that reference specific source or destination IP addresses, you can reference an ASG. This means that as VMs are added, removed, or their IP addresses change, the NSG rules automatically apply to the correct set of VMs without manual updates.
ASGs are a fundamental building block for implementing a zero-trust network model within Azure, where security rules are defined based on workload identity rather than network topology.
How ASGs Work Internally
ASGs are not a separate security enforcement point; they are simply a logical grouping mechanism that NSGs use to evaluate traffic. The process works as follows:
ASG Creation and Membership: You create an ASG object in a specific Azure region and resource group. Then you assign one or more virtual machine NICs to that ASG. Each NIC can be associated with up to 20 ASGs. The assignment is done at the NIC level, not the VM level, so a single VM with multiple NICs can have different ASGs per NIC.
NSG Rule Evaluation: When an NSG processes a packet, it checks the source and destination fields in the rule. If the rule specifies an ASG (e.g., source = ASG-WebServers), the NSG performs a lookup to determine which IP addresses belong to the VMs that are members of that ASG. This lookup happens dynamically; the NSG does not cache the IP list indefinitely. The ASG membership is resolved at the time of rule evaluation.
Traffic Flow: Consider a rule that allows inbound traffic from the 'WebServers' ASG to the 'AppServers' ASG on port 443. When a packet arrives at a VM in 'AppServers', the NSG checks the source IP. It then queries the 'WebServers' ASG to see if that source IP belongs to any NIC in that ASG. If yes, the rule matches and the traffic is allowed.
IP Address Resolution: The ASG membership is essentially a list of private IP addresses (from the VNet address space) of the NICs assigned to the ASG. If a NIC has multiple IP configurations, only the primary IP configuration is considered for ASG membership (by default). However, you can also include secondary IP configurations if needed.
Key Components, Values, and Defaults
Maximum ASGs per subscription: 3000 (soft limit, can be increased by support request).
Maximum ASGs per resource group: 3000.
Maximum ASG memberships per NIC: 20.
Maximum ASGs per NSG rule: You can specify up to 1 ASG as the source and 1 ASG as the destination per rule. However, you can combine multiple ASGs using service tags or application security groups in a single rule? No, each rule can have only one source ASG and one destination ASG. To allow traffic from multiple ASGs, you need separate rules.
ASG naming: Must be unique within a resource group, 1-80 characters, alphanumeric, underscores, periods, hyphens.
ASG scope: ASGs are regional. They cannot span regions. However, they can reference VMs in different VNets within the same region, as long as the VNets are peered? Actually, ASG membership is limited to VMs in the same region, but they can be in different VNets if those VNets are peered and the VMs can communicate. The NSG that references the ASG must be associated with a subnet or NIC that is in the same region as the ASG.
Configuration and Verification Commands
ASGs can be configured via Azure Portal, PowerShell, Azure CLI, or ARM templates.
Creating an ASG (Azure CLI):
az network asg create --resource-group myRG --name WebServers --location eastusAssigning a NIC to an ASG:
az network nic ip-config update --resource-group myRG --nic-name myVMNic --name ipconfig1 --application-security-groups WebServersCreating an NSG rule that uses ASGs:
az network nsg rule create --resource-group myRG --nsg-name myNSG --name AllowWebToApp --direction Inbound --priority 100 --source-asgs WebServers --destination-asgs AppServers --destination-port-ranges 443 --protocol Tcp --access AllowVerification: To see which NICs are assigned to an ASG:
az network asg show --resource-group myRG --name WebServers --query 'networkInterfaces[]'To view effective security rules for a NIC:
az network nic show-effective-nsg --resource-group myRG --name myVMNicInteraction with Related Technologies
NSGs: ASGs are always used in conjunction with NSGs. An NSG rule can reference ASGs as source or destination. The NSG can be associated with a subnet or a NIC.
Azure Firewall: ASGs are not directly supported in Azure Firewall rules. Azure Firewall uses IP groups or FQDN tags instead.
Service Tags: ASGs complement service tags. Service tags represent Azure services (e.g., AzureLoadBalancer), while ASGs represent your own application tiers.
Virtual Network Peering: ASG membership can include VMs in peered VNets, as long as the VMs are in the same region. The NSG must be associated with a subnet or NIC in the same region as the ASG.
Azure Policy: You can use Azure Policy to enforce ASG assignments or to require that certain NSG rules use ASGs instead of IP addresses.
Performance Considerations
ASG lookups add negligible latency because the NSG resolves the membership dynamically. However, if you have thousands of ASGs or very large memberships, the NSG evaluation might take slightly longer. In practice, this is not a concern for typical deployments. There is no limit on the number of NICs per ASG.
Troubleshooting
Common issues: - Rule not matching: Ensure the NSG is associated with the correct subnet or NIC. Also, verify that the ASG membership is correctly assigned to the NIC. - ASG not in the same region: ASGs and the NSG that references them must be in the same region. - Multiple NICs: If a VM has multiple NICs, each NIC can have different ASG assignments. Ensure you are checking the correct NIC.
Best Practices
Use ASGs to group VMs by application tier rather than by IP address ranges.
Combine ASGs with service tags for rules that need to allow Azure services.
Use descriptive names for ASGs (e.g., WebServers, AppServers, DataBaseServers).
Avoid mixing ASGs and IP addresses in the same rule; it is allowed but can be confusing.
Use Azure Policy to enforce ASG usage for compliance.
Create Application Security Group
First, you create an ASG object in your Azure subscription. This is a logical container with a name and a region. The ASG does not contain any rules itself; it is simply a grouping mechanism. You specify the resource group and location. The ASG must be in the same region as the VMs and the NSGs that will reference it. You can create multiple ASGs to represent different application tiers. For example, create 'WebServers' and 'AppServers' ASGs.
Assign NICs to ASG
Next, you associate each VM's network interface (NIC) with one or more ASGs. This is done at the NIC level, not the VM level. Each NIC can be assigned up to 20 ASGs. When you assign a NIC to an ASG, the NIC's private IP address becomes part of the ASG's membership list. If the NIC has multiple IP configurations, you can choose which configuration to use for ASG membership (by default, the primary IP configuration is used). This step essentially 'tags' the VM with the application role.
Create NSG Rule Referencing ASGs
Now, you create an NSG rule that uses the ASGs as source or destination. For example, a rule that allows inbound traffic from the 'WebServers' ASG to the 'AppServers' ASG on port 443. In the rule, you specify the ASG names instead of IP addresses or CIDR ranges. The NSG rule also includes priority, protocol, direction, and access (Allow/Deny). You can have multiple rules for different combinations of ASGs. The NSG itself must be associated with a subnet or a NIC to take effect.
Associate NSG with Subnet or NIC
The NSG containing the ASG-based rules must be associated with a subnet or a NIC. If associated with a subnet, the rules apply to all VMs in that subnet. If associated with a NIC, the rules apply only to that specific NIC. Typically, you associate the NSG with the subnet that contains the destination VMs. For example, if the rule is meant to protect the AppServers, you associate the NSG with the subnet where the AppServers reside.
Traffic Evaluation by NSG
When a packet arrives at a destination NIC, the NSG evaluates its rules in priority order. For each rule that references an ASG, the NSG looks up the current IP addresses of all NICs assigned to that ASG. This lookup is dynamic and reflects any recent changes in membership. If the source or destination IP matches any IP in the ASG, the rule is considered a match. The NSG then applies the specified action (Allow or Deny). If no rule matches, the default deny rule applies.
Enterprise Scenario 1: Multi-Tier Web Application
A company deploys a three-tier web application in Azure: web servers, application servers, and database servers. They have 50 web VMs, 20 application VMs, and 10 database VMs. Initially, they used NSG rules with IP address ranges, but as VMs were added or removed, they had to constantly update the rules. This led to misconfigurations and security gaps. They switched to ASGs: created three ASGs (WebServers, AppServers, DBServers), assigned each VM's NIC to the appropriate ASG, and created NSG rules: allow inbound from Internet to WebServers on 443, allow from WebServers to AppServers on 8080, allow from AppServers to DBServers on 1433. Now, when they scale out, new VMs are automatically covered by the rules. Misconfigurations dropped by 90%. The key is that ASGs decouple security from IP addresses, which is critical in auto-scaling environments.
Enterprise Scenario 2: Compliance-Driven Micro-Segmentation
A financial institution must enforce strict network segmentation between environments (dev, test, prod) and between application tiers. They use ASGs to implement micro-segmentation. They create ASGs for each tier in each environment (e.g., Prod-Web, Prod-App, Prod-DB). NSG rules are written to allow only necessary traffic between these groups. For example, only Prod-App can talk to Prod-DB, and only Prod-Web can talk to Prod-App. They also use Azure Policy to enforce that all VMs in production must have an ASG assignment. This ensures compliance with PCI DSS requirements. In production, they have over 2000 VMs, and managing this with IP addresses would be impossible.
Scenario 3: Multi-Tenant SaaS Platform
A SaaS provider hosts multiple customers in the same VNet using separate subnets. They use ASGs to group VMs by customer and by role. For each customer, they create ASGs like CustomerA-Web, CustomerA-App. NSG rules are then created to isolate customer traffic. For example, a rule denies traffic from CustomerA-Web to CustomerB-App. This provides tenant isolation without complex IP management. The challenge is that ASGs are regional, so for global deployments they need to replicate ASGs in each region. Also, they must ensure that ASG names are unique per resource group, which they handle by using a naming convention like [Customer]-[Role]-[Region].
Common Pitfalls
ASG and NSG in different regions: The NSG and the ASG it references must be in the same region. If you try to use an ASG from East US in an NSG in West US, the rule will not work.
ASG membership not updating immediately: While ASG membership changes are reflected quickly, there can be a propagation delay of a few seconds. During that window, traffic might be incorrectly allowed or denied.
Overlapping ASG assignments: A NIC can belong to multiple ASGs. This can lead to unexpected behavior if rules conflict. For example, if a NIC is in both ASG-A and ASG-B, and there is a rule allowing traffic from ASG-A and another rule denying traffic from ASG-B, the priority determines the outcome.
Using ASGs in Azure Firewall: ASGs are not supported in Azure Firewall rules. You must use IP groups instead.
What AZ-500 Tests on ASGs
AZ-500 objective 3.1 (Implement and manage network security) includes ASGs as a key concept. The exam expects you to:
Understand the purpose of ASGs: to simplify NSG rule management by grouping VMs logically.
Know how to create and assign ASGs to NICs.
Be able to design NSG rules that use ASGs as source or destination.
Understand the relationship between ASGs and NSGs.
Know the limitations: regional scope, maximum of 20 ASGs per NIC, maximum of 3000 ASGs per subscription.
Differentiate between ASGs and service tags.
Common Wrong Answers and Why Candidates Choose Them
'ASGs can be used in Azure Firewall rules' – This is false. Azure Firewall uses IP groups, not ASGs. Candidates confuse ASGs with IP groups because both are grouping mechanisms.
'ASGs can span regions' – False. ASGs are regional. Candidates may think that because VNets can be peered across regions, ASGs can too, but that is not the case.
'You can assign an ASG to a VM directly' – False. ASGs are assigned to NICs, not VMs. Candidates might overlook this distinction.
'An NSG rule can reference multiple ASGs in a single rule' – False. Each rule can have only one source ASG and one destination ASG. To allow traffic from multiple ASGs, you need multiple rules.
Specific Numbers and Terms on the Exam
20: Maximum ASGs per NIC.
3000: Maximum ASGs per subscription (soft limit).
Regional: ASGs are regional; they cannot be used across regions.
NIC-level: ASG assignment is at the NIC level, not VM level.
Priority: NSG rules are evaluated in priority order; lower number = higher priority.
Edge Cases and Exceptions
Multiple IP configurations: By default, ASG membership uses the primary IP configuration. If you need to include secondary IPs, you must explicitly configure that.
Accelerated Networking: ASGs work with accelerated networking; no special considerations.
VM Scale Sets: ASGs can be assigned to the NICs of VMs in a scale set. However, if you assign an ASG to a scale set's NIC template, all instances get that ASG. This is a common pattern for auto-scaling.
Azure Kubernetes Service (AKS): AKS nodes can be assigned ASGs, but the pods themselves cannot directly use ASGs because they have their own IP addresses.
How to Eliminate Wrong Answers
If the question mentions 'grouping VMs by application role' and 'NSG rules', the answer likely involves ASGs.
If the scenario involves 'Azure Firewall', ASGs are not the answer; look for 'IP groups'.
If the scenario involves 'global' or 'multi-region', ASGs are not suitable; consider 'service tags' or 'custom IP ranges'.
If the question asks about 'maximum number of ASGs per NIC', the answer is 20.
If the question asks about 'assigning an ASG', the correct object is the 'NIC', not the 'VM'.
ASGs group VMs by application role and are referenced in NSG rules to simplify security management.
ASGs are assigned to NICs, not VMs; each NIC can belong to up to 20 ASGs.
ASGs are regional and cannot be used across regions or in Azure Firewall.
Each NSG rule can have only one source ASG and one destination ASG.
Maximum 3000 ASGs per subscription (soft limit).
ASG membership is dynamic; changes are reflected quickly but with a slight propagation delay.
Use Azure Policy to enforce ASG assignments for compliance.
ASGs are ideal for auto-scaling environments and micro-segmentation.
ASGs complement service tags; use both in NSG rules for comprehensive security.
Troubleshooting: ensure NSG is associated with correct subnet/NIC and that ASG and NSG are in the same region.
These come up on the exam all the time. Here's how to tell them apart.
Application Security Groups
Group VMs logically by application role (e.g., web servers).
Rules reference ASG names, not IP addresses.
Automatically adapts to IP changes and VM additions/removals.
Simplifies management in dynamic environments.
Limited to 20 ASGs per NIC and 3000 per subscription.
Network Security Groups (with IP-based rules)
Rules reference specific source/destination IP addresses or CIDR ranges.
Requires manual updates when VMs are added or IPs change.
More granular control over individual IPs.
Becomes complex and error-prone in large environments.
No inherent limit on number of IP-based rules, but performance can degrade with many rules.
Application Security Groups
Used for grouping your own VMs by application tier.
Custom defined by the user.
Regional scope.
Referenced in NSG rules as source or destination.
Cannot represent Azure services.
Service Tags
Used for grouping Azure service IP ranges (e.g., AzureLoadBalancer, Sql).
Predefined by Microsoft.
Global scope (can be used in any region).
Referenced in NSG rules as source or destination.
Cannot represent your own VMs.
Mistake
ASGs can be used to filter traffic between VMs in the same subnet without an NSG.
Correct
ASGs are not a standalone security mechanism; they are only meaningful when referenced in NSG rules. Without an NSG rule that uses the ASG, no filtering occurs.
Mistake
You can assign an ASG directly to a VM.
Correct
ASGs are assigned to the network interface (NIC) of a VM, not the VM itself. A VM with multiple NICs can have different ASGs per NIC.
Mistake
ASGs can be used across regions in a global VNet peering.
Correct
ASGs are regional objects. They cannot be referenced by NSGs in a different region, even if VNets are peered globally. The NSG and ASG must be in the same region.
Mistake
An NSG rule can have multiple source ASGs.
Correct
Each NSG rule can have exactly one source ASG and one destination ASG. To allow traffic from multiple ASGs, you must create separate rules.
Mistake
ASGs automatically update when VMs are added or removed from a scale set.
Correct
ASG membership is assigned at the NIC level. For VM scale sets, you must assign the ASG to the NIC configuration of the scale set. New instances will automatically get the ASG if the configuration includes it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, as long as all NICs are in the same region. ASGs are regional, so they can include NICs from different VNets within that region. However, the NSG that references the ASG must also be in the same region and associated with a subnet or NIC in that region.
If you delete an ASG that is referenced in an NSG rule, the rule becomes invalid and will not match any traffic. The rule remains in the NSG but is effectively ignored. It is best practice to remove or update such rules before deleting the ASG.
No, Azure Firewall does not support ASGs. Instead, you should use IP Groups to group IP addresses for Azure Firewall rules. ASGs are specifically designed for use with Network Security Groups.
Changes to ASG membership are typically reflected within a few seconds. However, there is no guaranteed maximum propagation delay. In practice, it is usually under 30 seconds. For critical environments, test the delay.
No, ASGs represent your own VMs within Azure. To allow traffic from the internet, you must use a source of 'Internet' (service tag) or specific public IP ranges. You can use an ASG as the destination in an inbound rule to allow internet traffic to reach a group of VMs.
ASGs are used with NSGs and group VMs by NIC assignment. IP Groups are used with Azure Firewall and group IP addresses (either public or private) by explicit IP address entries. ASGs are dynamic; IP Groups are static.
Yes, you can assign an ASG to the NIC configuration of a VM scale set. All instances in the scale set will then be part of that ASG. This is a common pattern for auto-scaling web tiers.
You've just covered Application Security Groups (ASGs) — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?