Application Security Groups (ASG)

An Application Security Group (ASG) is a logical container that groups virtual machines (VMs) by application workload, such as 'web servers', 'application servers', or 'database servers'. Instead of writing NSG rules that reference source or destination IP addresses (like 10.0.1.0/24), you can reference an ASG name. This decouples security rules from IP addressing, making them dynamic and easier to manage as VMs are added, removed, or scaled.

Before ASGs, administrators had to maintain NSG rules based on IP addresses or subnets. This was brittle: if a VM's IP changed (e.g., due to deallocation/reallocation), or if new VMs were added, the NSG rules had to be updated. With ASGs, you define the security policy once at the ASG level. When you add a VM to an ASG, the NSG rules that reference that ASG automatically apply to that VM. This is especially useful in auto-scaling scenarios where VMs come and go.

ASGs are a virtual network (VNet) resource. They are not applied directly to VMs; instead, the VM's network interface (NIC) has a property that references one or more ASGs. Each NIC can be associated with up to 20 ASGs. When a VM is created, you specify which ASGs it belongs to (or you can add them later).

When an NSG is associated with a subnet or NIC, and it contains a rule with an ASG reference, Azure's network fabric resolves the ASG to the set of private IP addresses of all VMs whose NICs are members of that ASG. This resolution occurs in the Azure SDN (Software Defined Networking) layer. The NSG rules are then evaluated against those resolved IPs.

Critically, ASGs are scoped to a single VNet. You cannot have an ASG that includes VMs from different VNets (unless peered, but even then, the ASG membership is per NIC in the same VNet). Also, ASGs only support private IP addresses within the VNet; they cannot reference on-premises or public IPs.

1. Create an ASG: Use Azure portal, PowerShell, CLI, or ARM template.

New-AzApplicationSecurityGroup -ResourceGroupName myRG -Name webASG -Location eastus

az network asg create --resource-group myRG --name webASG --location eastus

2. Associate a NIC with an ASG: When creating a VM or updating an existing NIC.

$nic = Get-AzNetworkInterface -ResourceGroupName myRG -Name myVMNic
   $nic.IpConfigurations[0].ApplicationSecurityGroups.Add((Get-AzApplicationSecurityGroup -ResourceGroupName myRG -Name webASG))
   Set-AzNetworkInterface -NetworkInterface $nic

az network nic ip-config update --resource-group myRG --nic-name myVMNic --name ipconfig1 --application-security-groups webASG

3. Create NSG rule referencing ASG:

$nsg = Get-AzNetworkSecurityGroup -ResourceGroupName myRG -Name myNSG
   $nsg | Add-AzNetworkSecurityRuleConfig -Name AllowWebToApp -Direction Inbound -Priority 100 -Access Allow -Protocol Tcp -SourceApplicationSecurityGroupId (Get-AzApplicationSecurityGroup -ResourceGroupName myRG -Name webASG).Id -DestinationApplicationSecurityGroupId (Get-AzApplicationSecurityGroup -ResourceGroupName myRG -Name appASG).Id -SourcePortRange * -DestinationPortRange 80
   Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsg

- Check effective security rules on a VM:

az network nic show-effective-nsg --resource-group myRG --name myVMNic

This shows the resolved rules, including ASG expansions.

ASGs are resolved in the control plane. The resolution is efficient, but there are limits (e.g., 3000 NICs per ASG). In practice, for large-scale deployments, you may need to split tiers across multiple ASGs if you exceed limits. Also, changes to ASG membership are propagated quickly but not instantaneously; there might be a brief period where old rules still apply.

ASGs enable you to write security rules based on application semantics rather than IP addresses, making your network security agile and easier to maintain. They are a core part of Azure's network security model and a frequent topic on the AZ-104 exam.

A large e-commerce company runs a three-tier application on Azure: web servers, application servers, and database servers. They have hundreds of VMs across multiple availability zones. Without ASGs, they would need to maintain NSG rules that list every web server's IP as a source for the application tier. Whenever a new web server is added via auto-scaling, the NSG rules would need updating, which is error-prone and slow.

Solution: The team creates three ASGs: webASG, appASG, and dbASG. All web server NICs are added to webASG, application servers to appASG, and database servers to dbASG. They then create an NSG associated with the application tier subnet. The NSG rules are:

Now, when auto-scaling adds a new web server, its NIC is automatically added to webASG via ARM templates, and the NSG rules immediately apply. The team also configures the application load balancer to use the ASG as the backend pool? No, backend pools use NICs or IPs, not ASGs. So they still need to manage the load balancer separately.

Performance: With 500 VMs per tier, the ASG resolution works efficiently. However, they hit the 3000 NICs per ASG limit? Not yet. They monitor the number of NICs per ASG. They also ensure that the NSG rule count does not exceed 1000 (default per NSG).

What goes wrong: Initially, they accidentally associated the NSG at the NIC level instead of subnet, causing duplicate rule evaluation and confusion. They also misconfigured the rule direction; they created an outbound rule instead of inbound. The result was that traffic from web to app was blocked. They had to use az network nic show-effective-nsg to troubleshoot.

A fintech company uses Kubernetes (AKS) with a service mesh (Istio). They want to enforce network segmentation between microservices at the Azure network level for defense-in-depth. They create ASGs per microservice (e.g., auth-svc, payment-svc, notification-svc). Each AKS node pool's VMs have a NIC that is associated with the appropriate ASG. However, because AKS nodes run multiple pods, each node may need to be in multiple ASGs. But a NIC can only be in up to 20 ASGs, which may be insufficient for many microservices.

Solution: They use a different approach: they assign ASGs based on node pool purpose (e.g., frontend pool, backend pool) rather than per microservice. They then use Kubernetes network policies for granular control. This hybrid approach reduces the number of ASGs needed.

What goes wrong: They initially tried to assign ASGs to pod IPs, but ASGs are only for VM NICs, not individual pod IPs. They had to rethink their design.

A startup wants to isolate dev, test, and prod environments within a single VNet to save costs (no peering). They create ASGs: devASG, testASG, prodASG. Each VM's NIC is associated with its environment's ASG. Then they create an NSG associated with the subnet that contains all VMs. The NSG rules are:

This works because NSG rules can reference multiple ASGs. However, they must be careful about rule priorities. They set a rule with priority 100 to allow intra-ASG traffic, and a rule with priority 200 to deny inter-ASG traffic. But the deny rule must be explicit; otherwise, default deny applies. They also need to allow traffic to Azure services like Azure SQL via service tags.

Performance: With 100 VMs per environment, the NSG rules are manageable. But they hit the limit of 3000 ASG references per NSG? Not yet. They also need to ensure that the NSG does not become too complex.

What goes wrong: They forgot to add the deny rule and relied on default deny. But default deny applies at the end, so traffic between ASGs was implicitly denied. However, they wanted to log denied traffic; they had to enable NSG flow logs. Also, they mistakenly associated the NSG with the subnet but also with individual NICs, causing double evaluation and unexpected denies.