Explains how Azure Application Security Groups let you group VM network interfaces to simplify and control NSG rules for selective, scalable network access
Application Security Groups (ASGs) in Azure provide an application-centric, scalable way to manage network access across virtual machines (VMs). Instead of authoring and maintaining rules that reference individual IP addresses, ASGs let you group NICs (and therefore VMs) logically and reference those groups from Network Security Group (NSG) rules. This simplifies policy management, enables layered security, and makes group membership flexible — a VM can be in multiple ASGs and an ASG can be referenced by many NSGs.
Why use ASGs? Here are the core benefits:
Benefit
Description
Example
Dynamic grouping
Group NICs logically without hardcoding IPs
Add/remove VM NICs from an ASG as VMs scale
Simplified NSG rules
Reference ASGs in NSG rules instead of IP lists
One rule allowing HTTP to a “Web” ASG
Reusable policies
Reuse ASGs across multiple NSGs and subnets
Apply same ASG in different NSGs for consistent access
ASGs enable layered and reusable policies. For example, put all web servers into a Web ASG and allow only TCP/80 to that group; place database servers in a DB ASG and allow only TCP/1433 to that group.
This walkthrough demonstrates creating an ASG, associating NICs (VM1 and VM2), and updating a subnet-level NSG so only those two VMs can access Azure Storage, while a third VM in the same subnet remains blocked.
Create an ASG in the Azure portal (choose subscription, resource group, name, region). After deployment, you can reference this ASG in NSG rules and add NICs to make VMs members.
Associate a VM’s network interface (NIC) to the ASG so it becomes a logical member. Open the VM’s networking settings, select the NIC, and add the ASG.
Use the “Add application security groups” option on the NIC and pick the ASG you created.
Repeat the association for VM2’s NIC. Leave VM3 ungrouped so it does not gain the same access.
3) Update the NSG to Allow Storage Only for the ASG
Instead of permitting storage access from the entire subnet, create an NSG outbound rule that allows traffic only when the source is the ASG. Configure the new outbound rule with values like the following:
Field
Value
Source
Application Security Group (select your ASG)
Source port ranges
*
Destination
Service Tag — Storage
Destination port range
443
Action
Allow
Priority
Lower number than existing Deny (e.g., 100 if Deny is 200)
Name
AllowStorage
Be sure the rule priority places this allow rule above any broader Deny rules so it takes effect.
NSG rule ordering matters. A lower priority number has higher precedence. If a Deny rule has a lower number than your Allow, the Deny will still block traffic. Place the AllowStorage rule with a priority that precedes the Deny.
After creating the rule, confirm it appears in the NSG outbound rules list.
You can also review the NSG overview and existing rules (for context, e.g., a Deny Internet rule) before and after changes.
After the ASG membership and NSG rule are in place:
VM1 and VM2 (NICs in the ASG) can reach Azure Storage on TCP/443.
VM3 (not in the ASG) remains blocked by the subnet-level deny rule.
Example SSH + curl session showing the change (before and after the AllowStorage rule):
Copy
# SSH into VM1ssh kodekloud@172.191.36.135# Before the ASG-based allow rule:kodekloud@vm-nsg-lab-1:~$ curl https://cskodekloudaz01.blob.core.windows.net/vision/note.jpeg^Ckodekloud@vm-nsg-lab-1:~$ curl https://www.microsoft.comcurl: (28) Failed to connect to www.microsoft.com port 443: Connection timed out# After creating the NSG outbound rule that allows Storage from the ASG:kodekloud@vm-nsg-lab-1:~$ curl -I https://cskodekloudaz01.blob.core.windows.net/vision/note.jpegHTTP/1.1 200 OKContent-Length: 12345Content-Type: image/jpeg...
This verifies that a single NSG rule referencing an ASG can selectively permit storage access for a subset of VMs in the same subnet, avoiding manual IP lists and simplifying policy management.
