6.1.2. Application Security Groups

ASGs enable grouping VMs logically for security rules, regardless of IP address.

Without ASGs:

Rule: Allow 10.0.1.5, 10.0.1.6, 10.0.1.7 → 10.0.2.10, 10.0.2.11 on port 443

With ASGs:

Rule: Allow WebServers → DatabaseServers on port 443

Benefits:

• IP-independent rules (VMs can change IPs)
• Self-documenting (names describe purpose)
• Scale without rule modification

Creating ASG-based Rules:

1. Create ASG (e.g., "WebServers", "DatabaseServers")
2. Associate VM NICs with ASGs
3. Reference ASGs in NSG rules

The constraint that catches people: an application security group and the network interfaces in it must all live in the same virtual network, and when a rule names an ASG as both source and destination, both groups must belong to that same virtual network too. ASGs are therefore a way to organise rules within a VNet — they do not reach across a peering.

Why this scales where addresses do not. A rule written against addresses has to be edited every time a VM is rebuilt, re-addressed or added. A rule written against ASGs never changes: joining the group is what grants the access, so provisioning a new web server is a NIC association rather than a firewall change. That also makes the rule readable — WebServers → DatabaseServers on 1433 states the intent, where a list of addresses only states the implementation.

💡 First Principle: ASGs move the membership decision out of the rule and onto the workload. The rule then describes policy, and stays still while the estate moves.