NSGs & Application Security Groups
Network Security Groups are Azure's built-in stateful firewall. Learn how NSG rules work, how priority determines which rule wins, how Application Security Groups simplify rule management, and how to evaluate effective security rules.
What are Network Security Groups?
An NSG is a bouncer with a guest list — it checks every packet arriving at your network and decides: let it in, or turn it away.
Think of NSG rules like airport security checkpoints. Each rule says “if the traffic matches this source, destination, port, and protocol, then allow or deny it.” Rules have a priority number — the bouncer checks from lowest number (highest priority) first and follows the first matching rule.
NSGs are stateful: if you allow an inbound request, the response is automatically allowed out. No need for a separate outbound rule for return traffic.
NSG rule anatomy
Each NSG rule has these components:
| Property | Description |
|---|---|
| Priority | 100 to 4096 — lower number means higher priority |
| Source | IP address, CIDR range, service tag, or ASG |
| Source port | Port or range (usually * for any) |
| Destination | IP address, CIDR range, service tag, or ASG |
| Destination port | Port or range (e.g., 80, 443, 3389) |
| Protocol | TCP, UDP, ICMP, or Any |
| Action | Allow or Deny |
Rules are evaluated in priority order (lowest number first). The first matching rule wins — all subsequent rules are ignored for that packet.
Default rules
Every NSG comes with three inbound and three outbound default rules that you cannot delete (but can override with higher-priority rules):
Default inbound rules:
| Priority | Name | Effect |
|---|---|---|
| 65000 | AllowVNetInBound | Allows all traffic within the VNet |
| 65001 | AllowAzureLoadBalancerInBound | Allows health probes from Azure Load Balancer |
| 65500 | DenyAllInBound | Denies all other inbound traffic |
Default outbound rules:
| Priority | Name | Effect |
|---|---|---|
| 65000 | AllowVNetOutBound | Allows all outbound traffic within the VNet |
| 65001 | AllowInternetOutBound | Allows all outbound traffic to the internet |
| 65500 | DenyAllOutBound | Denies all other outbound traffic |
Exam tip: Default deny inbound, allow outbound
By default, an NSG denies all inbound traffic from the internet but allows all outbound traffic to the internet. This is the baseline behaviour. You add rules with lower priority numbers to allow specific inbound traffic (e.g., priority 100 to allow HTTPS on port 443).
You can also add Deny rules with lower priorities to override the default Allow rules. For example, a priority 100 Deny rule for outbound internet would override the default AllowInternetOutBound (65001).
Service tags
Instead of listing IP addresses, you can use service tags — predefined labels that represent groups of Azure IP addresses:
| Service Tag | Represents |
|---|---|
| Internet | All public internet IP addresses |
| VirtualNetwork | The VNet address space, peered VNets, and on-prem (via VPN) |
| AzureLoadBalancer | Azure’s infrastructure load balancer |
| Storage | Azure Storage IP addresses |
| Sql | Azure SQL Database IP addresses |
| AzureActiveDirectory | Microsoft Entra ID IP addresses |
Service tags are maintained by Microsoft and update automatically — no need to track Azure IP range changes yourself.
Application Security Groups (ASGs)
ASGs let you group VMs logically and use those groups in NSG rules instead of listing individual IP addresses.
| Approach | Without ASGs | With ASGs |
|---|---|---|
| Rule source/destination | Individual IP addresses (10.0.1.4, 10.0.1.5, ...) | ASG name (e.g., 'WebServers') |
| Adding a new VM | Update every NSG rule with the new IP | Add the VM's NIC to the ASG — rules auto-apply |
| Readability | Hard to understand which IPs are which | Clear intent — 'Allow WebServers to reach DbServers' |
| Maintenance | Error-prone as IPs change | Zero rule changes needed |
How to use ASGs:
- Create ASGs: “WebServers”, “AppServers”, “DbServers”
- Assign VM NICs to the appropriate ASG
- Write NSG rules using ASGs as source or destination
Real-world: Meridian Financial's micro-segmentation
Meridian Financial uses ASGs to enforce strict micro-segmentation across their 200+ VMs:
- ASG: WebTier — 40 front-end VMs
- ASG: AppTier — 60 application VMs
- ASG: DbTier — 20 database VMs
NSG rules:
- Allow Internet to WebTier on port 443 (HTTPS only)
- Allow WebTier to AppTier on port 8080 (API calls)
- Allow AppTier to DbTier on port 1433 (SQL)
- Deny all other inter-tier traffic
When they add a new app server, Alex just adds the NIC to the AppTier ASG. No NSG rule changes needed.
NSG association: Subnet vs NIC
NSGs can be associated with subnets, NICs, or both:
| Association | When Traffic is Evaluated | Common Use |
|---|---|---|
| Subnet NSG | All traffic entering/leaving the subnet | Broad rules for an entire tier |
| NIC NSG | Traffic to/from a specific VM | VM-specific rules |
| Both | Traffic must pass BOTH NSGs | Defence in depth |
When both are applied:
- Inbound: Subnet NSG evaluates first, then NIC NSG. Must be allowed by BOTH.
- Outbound: NIC NSG evaluates first, then Subnet NSG. Must be allowed by BOTH.
Evaluating effective security rules
With NSGs at both subnet and NIC levels, it can be hard to know what’s actually allowed. Azure provides the Effective security rules view on a NIC, showing the combined result of all NSG rules applied to that interface.
Access it via: VM > Networking > Effective security rules (or via Network Watcher > Effective security rules)
Exam tip: Traffic must pass BOTH NSGs
If you have an NSG on the subnet allowing port 443 but the NIC-level NSG denies it, traffic is blocked. Both must allow for traffic to flow. This is the most common configuration mistake — check effective security rules to see the combined picture.
Knowledge check
Alex has two NSG rules on the same NSG. Rule A (priority 100) allows inbound TCP port 443 from the Internet. Rule B (priority 200) denies all inbound traffic from the Internet. What happens when someone tries to access port 443 from the internet?
CloudFirst Labs has an NSG on the subnet that allows port 22 (SSH). They also have a separate NSG on the VM's NIC that does NOT have a rule for port 22. Can Alex SSH into the VM?
Meridian Financial has 50 web servers that all need the same NSG rules. The web servers frequently scale in and out (IPs change). What is the best approach?
🎬 Video coming soon