Application Security Group (ASG)
What it is
An Application Security Group (ASG) is a logical label for VM network interfaces in one VNet. It lets an NSG rule refer to a role such as WebServers or DatabaseServers, rather than maintaining a list of individual IP addresses.
Why it exists
IP lists are brittle: a new VM or address change means another rule update. An ASG separates what the VM does from which address it has, so the NSG rule can remain stable as membership changes.
Key ideas
- An ASG contains VM network interfaces, not subnets and not people.
- An NSG rule can use an ASG as a source or destination. It is still the NSG rule—not the ASG—that allows or denies the flow.
- A NIC can belong to multiple ASGs, up to Azure limits. All NICs in one ASG must be in the same VNet.
- If an ASG is both source and destination in an NSG rule, the source and destination ASGs must be in the same VNet.
Northwind example
Northwind places the web VM NICs in AsgWeb, application VM NICs in AsgApp, and database VM NICs in AsgDb. Its NSG allows HTTPS from AsgWeb to AsgApp, and the database port only from AsgApp to AsgDb. Adding a new app VM means adding its NIC to AsgApp; the existing NSG rules apply without rewriting IP lists.
Rule example
priority 100 source: Source=ASG WebServers dest=ASG AppServers allow TCP 443
priority 200 source: Source=ASG AppServers dest=ASG AppServers deny all (isolate tier)How it fits
NICs tagged into Web and DB ASGs; an NSG associated with the subnet references them:
Diagrams courtesy of Microsoft Learn / Azure docs: virtual-network/application-security-groups
Exam notes
- ASG = NIC membership by role; it is not an NSG replacement.
- NSG’s “source/destination” can be an ASG, a service tag, or an IP/CIDR.
- Grouping by application tier is the canonical use case; rules become portable across IP changes.