Skip to main content
Application Security Groups (ASGs) in Azure let you define fine-grained network policies around application workloads instead of hard‑coding IP addresses. By grouping virtual machines (or their network interfaces) that share the same security posture, ASGs simplify Network Security Group (NSG) rule authoring and maintenance. This is especially useful in dynamic environments where instances are frequently added or removed. How ASGs work
  • Create logical groups representing application tiers (for example: web, logic, db).
  • Attach an ASG to a VM’s network interface (NIC) from the VM Networking blade.
  • Reference the ASG by name in NSG inbound/outbound rules as the Source or Destination.
Example architecture: VM1 and VM2 are front-end web servers grouped under ASG “web”; VM3 is the logic tier under ASG “logic”; VM4 is the database tier under ASG “db”. Using ASGs lets you write NSG rules that refer to those group names instead of individual IPs, reducing complexity and improving manageability.
A cloud network diagram showing an Azure virtual network with subnets, VMs grouped into Application Security Groups (ASG Web, ASG Logic, ASG Db) and associated NSGs. It uses icons (green checks and red Xs) to show allowed HTTP/TCP traffic (port 80 and port 1433) and blocked connections.
Common use cases Key networking behavior to remember
  • NSGs can be applied at the subnet level and/or NIC level. Azure evaluates both sets of rules together. A higher-priority deny will block traffic even if another rule allows it.
  • ASG membership is managed from the VM/NIC blade (you attach the ASG to the NIC). The Application Security Groups resource page is used to create ASG objects but not to attach NICs.
ASGs represent groups of NICs for use in NSG rules. After attaching an ASG to a VM’s NIC, you can select that ASG as the source or destination when adding NSG rules in the portal. Check a VM’s “Effective security rules” to see how subnet and NIC NSGs combine in practice.
Inspecting effective rules Open a VM blade (for example Workload A — VM1) → Networking → Effective security rules to view the combined result of subnet- and NIC-level NSGs. If a subnet-level NSG denies SSH while a NIC-level NSG allows it, the deny will still take effect because NSG evaluation honors priorities.
A screenshot of the Microsoft Azure portal showing the "workload-b-vm-1 | Effective security rules" page with associated network security groups. The main pane lists inbound and outbound NSG rules (e.g., DenyAnySSHInbound, AllowVnetInBound) with priorities, ports, protocols, and Allow/Deny status.
Creating and assigning ASGs (portal workflow)
  1. Create Application Security Group resources:
    • In the Azure portal, go to Application Security Groups and create ASGs (for example BVMs and NonWebBVMs) in the desired resource group and region.
  2. Attach ASGs to VMs (NICs):
    • Go to Virtual Machines → select a VM → Networking → Application security groups.
    • Select the ASG(s) to attach to that VM’s NIC and save. This action makes the NIC a member of the ASG.
    • Note: Manage membership from the VM/NIC blade; the ASG blade is only for creating ASG objects.
Referencing ASGs in NSG rules When you add an NSG inbound or outbound rule, choose Source or Destination = Application security group, then select the ASG. You can also pick a predefined service (e.g., HTTP) or provide a custom port (for example 80 or 8080).
Screenshot of the Microsoft Azure portal showing the Virtual machines > workload-a-vm-1 Networking page with inbound port rules. A right-hand pane overlays the "Add inbound security rule" dialog where destination, port (8080), protocol and action options are being configured.
Demonstration behavior and rule priority
  • In the demo, BVM1 (member of ASG BVMs) successfully curls VM1 (IP 192.168.1.4) because an NSG rule allows traffic from the BVMs ASG.
  • Removing a VM from an ASG immediately excludes it from ASG-based NSG rules. However, other allow rules (for example default AllowVnetInBound) may still permit traffic. To actively block the VM immediately after removing it from an ASG, create a higher-priority deny rule that targets the VM (NIC or subnet).
Example shell session (simplified):
Removing a VM from an ASG does not automatically block traffic if other NSG rules allow it. Because NSG rules are priority-based, add a higher-priority deny rule targeting the specific VM/NIC/subnet if you need to prevent access immediately.
Benefits of using ASGs with NSGs Summary Application Security Groups let you define network policies against logical groups of resources, reducing operational overhead as your environment scales. Use ASGs to simplify NSG rules, control tier-to-tier access, and keep your security model aligned with application roles. Further reading and references With that, we have completed Application Security Groups. Service endpoints are a related topic and are covered separately.

Watch Video