NSG vs Application Security Group in Azure: What's the Difference?
People treat these as two flavors of the same thing. They are not. One is the firewall that allows or blocks traffic. The other is a name tag you stick on your VMs so you never have to type an IP address into a rule again.
New to cloud? CAMPUX is a free, build-first course. Start here →
Here is the short version: the network security group (NSG) is the firewall, and an application security group (ASG) is a label you put on VMs so you can write cleaner rules. The NSG holds the allow and deny rules and does the actual filtering. The ASG holds nothing and filters nothing — it is a group you assign VM network interfaces to, so that an NSG rule can say "web tier can reach app tier" instead of listing ten IP addresses. If you remember one sentence, remember that one. Everything below is just the detail that makes it stick.
What an NSG does
A network security group is a set of security rules that allow or deny network traffic to and from Azure resources. Each rule has a priority, a direction (inbound or outbound), a source, a destination, a port, a protocol, and an action — allow or deny. Azure evaluates the rules in priority order and stops at the first match. You attach an NSG to a subnet, to a NIC, or both, and it filters traffic crossing that boundary.
Two things matter about how it behaves. First, an NSG is stateful. If you allow an inbound flow, the return traffic for that flow is allowed automatically — you do not write a matching outbound rule for the response. Second, every NSG ships with default rules you cannot delete. Those defaults allow traffic inside the virtual network, allow inbound from the Azure load balancer, allow outbound to the internet, and then deny everything else. Your custom rules sit at higher priority and override the defaults where you need something different.
So the NSG is where the security decision lives. It is the object an auditor looks at when they ask "what can talk to this database." Nothing else in this article changes that.
What an ASG does
An application security group does not filter anything. It is a logical grouping of virtual machine network interfaces, organized by application tier or role. You create an ASG called asg-web, another called asg-app, another called asg-db, and you assign each VM's NIC to the group that matches its job. That is the entire feature. The ASG has no rules, no ports, no allow or deny.
The payoff shows up when you write NSG rules. Instead of naming an IP address or a CIDR range as the source or destination, you name an ASG. The rule then applies to whatever NICs happen to be in that group at the moment traffic flows. Add a new web server to asg-web and it inherits every rule that references asg-web — you did not touch a single rule. Remove it and the rules stop applying to it. The ASG is a moving target that your rules point at, so the rules stay still while the servers behind them change.
An ASG is not a smaller firewall. It is a name you give a group of servers so a firewall rule can stop caring about their IP addresses.
Worked example: web tier to app tier without hard-coded IPs
Picture a standard three-tier app in one virtual network. Web servers take traffic from the internet. App servers accept traffic only from the web tier. Database servers accept traffic only from the app tier. This is the exact shape ASGs were built for.
First, the grouping. You create three ASGs and assign the NICs:
asg-web— every web server NICasg-app— every application server NICasg-db— every database server NIC
Now you attach one NSG to the subnet and write rules that reference the groups. The rule that lets the web tier reach the app tier looks like this in plain terms: allow inbound TCP on port 8080, source asg-web, destination asg-app. The rule that lets the app tier reach the database: allow inbound TCP on port 1433, source asg-app, destination asg-db. Then a low-priority deny to close off anything you did not explicitly permit.
Look at what you did not write. You did not list 10.0.1.4, 10.0.1.5, 10.0.1.6 as the source of the app-tier rule. You wrote asg-web once. When the web tier scales from three servers to thirty, you add the new NICs to asg-web and the app-tier rule already covers them. The rule text never changes. That is the collapse — a list of IPs becomes one group name, and the group name maintains itself.
Three allow rules and one deny, and none of them contain an IP address. The web tier's public ingress is its own rule; the tier-to-tier rules use ASGs on both ends. Read it top to bottom the way Azure evaluates it — lowest priority number wins.
| Priority | Name | Source | Destination | Port | Action |
|---|---|---|---|---|---|
| 100 | allow-web-in | Internet | asg-web | 443 | Allow |
| 110 | allow-web-to-app | asg-web | asg-app | 8080 | Allow |
| 120 | allow-app-to-db | asg-app | asg-db | 1433 | Allow |
| 4000 | deny-all-in | Any | Any | Any | Deny |
The database accepts 1433 only from the app tier, never from the web tier or the internet, and you can read that guarantee straight off the table without decoding a subnet mask. That readability is the point people miss when they call ASGs "optional."
Why ASGs scale better than IP-based rules
The old way was to carve your tiers into separate subnets and write rules against subnet CIDR ranges, or worse, against individual IPs. Both work until they do not. IP-based rules rot the moment infrastructure moves: a VM gets rebuilt with a new address, an autoscale event adds instances you did not enumerate, someone renumbers a subnet. Every one of those changes means editing firewall rules, and editing firewall rules under pressure is how outages and holes happen.
ASGs break that coupling. The rule references a group; the group references NICs; membership is a property of the VM, not of the firewall. You manage membership where you manage the server — in the VM's network config or your infrastructure-as-code — and the security rules stay frozen. That separation is what makes the design hold up as the environment grows. It also collapses rule count: one asg-web to asg-app rule replaces what might have been a dozen per-host entries, and fewer rules means fewer places to make a mistake.
The gap: ASG limits, and why you still need an NSG
ASGs are useful, not magic. The single most important limitation is the one people trip over first: an ASG does nothing by itself. It is inert until an NSG rule names it as a source or destination. There is no "apply the ASG" step — the NSG rule is the only thing that gives an ASG any effect. If you create groups, assign NICs, and forget to write the rules, you have built a filing system that filters no traffic.
The other constraints are about scope. All NICs assigned to an ASG must live in the same virtual network, and when a single NSG rule references two ASGs — one as source, one as destination — both must be in that same VNet. You cannot span a rule across peered VNets with ASGs. A network interface can belong to multiple ASGs at once, and there are per-subscription caps on how many ASGs you can create and related limits on how they combine; the exact numbers live in the Azure networking limits doc and shift over time, so check the current figures rather than trusting a number you memorized last year.
None of this replaces the firewall. The NSG is still the object doing allow and deny, still the thing with default rules, still stateful, still what you audit. The ASG only changes how you express the source and destination of a rule. Keep the mental model clean: NSG decides, ASG labels. For where the NSG itself stops and a different tool takes over, see NSG vs Azure Firewall.
ASGs live inside the VNet, so the surrounding networking matters: VNet peering for connecting networks, private endpoints for pulling PaaS services onto your VNet, and Azure Bastion for reaching VMs without exposing RDP or SSH to the internet.
NSG vs ASG at a glance
| Network security group (NSG) | Application security group (ASG) | |
|---|---|---|
| What it is | A firewall — a set of allow/deny security rules | A label grouping VM NICs by app tier or role |
| OSI layer | Layers 3 and 4 (IP, TCP/UDP, ports) | Not a filter — it is a grouping construct, no layer of its own |
| Contains rules? | Yes — priority, direction, source, destination, port, action | No — it holds NIC memberships, nothing else |
| References IPs or groups? | References IPs, CIDR ranges, service tags, or ASGs | Is referenced by NSG rules as a source or destination |
| Used alone? | Yes — an NSG filters traffic on its own | No — inert until an NSG rule names it |
| Best for | Deciding what traffic is allowed or denied | Writing tier-to-tier rules without hard-coded IPs |
Questions people also ask
What is the difference between NSG and ASG?
A network security group (NSG) is the firewall: it holds the stateful allow and deny rules that filter traffic in and out. An application security group (ASG) is not a firewall at all — it is a label you attach to virtual machine NICs so an NSG rule can name a group of VMs instead of a list of IP addresses. The NSG does the filtering; the ASG makes the rule readable.
Can I use an ASG without an NSG?
No. An ASG does nothing on its own. It only has an effect when an NSG rule references it as a source or destination. You create the ASG, assign NICs to it, then write an NSG rule that points at it. Without that rule, the ASG is just an unused label.
What problem do Application Security Groups solve?
They remove hard-coded IP addresses from your firewall rules. Instead of listing every web server IP as the source of a rule, you put those servers in a web-tier ASG and write one rule that says web-tier can reach app-tier. When you add or remove a server, you change its ASG membership and every rule updates automatically — you never touch the rules again.
Do ASGs replace NSGs?
No. ASGs do not replace NSGs — they work inside them. The NSG is still the object that allows or denies traffic. An ASG is only a way to express the source or destination of an NSG rule as a named group of VMs rather than an IP range. You always need an NSG to do the actual filtering.
How many ASGs can a NIC belong to?
A network interface can be a member of multiple application security groups at once, up to the Azure subscription limits. All NICs in an ASG must live in the same virtual network, and both the source and destination ASGs referenced in a single NSG rule must be in that same VNet. Check the current Azure networking limits doc for the exact numbers, since they change over time.