NSGs and Application Security Groups

Network Security Groups (NSGs) are Azure’s built-in, stateful firewall for filtering traffic at the subnet and NIC level. They’re the first line of defence in every Azure network.

🎬 Video coming soon

NSGs and Application Security Groups

NSGs and Application Security Groups

~13:00

NSG Rule Anatomy

Every NSG rule has these properties:

Property	Description	Values
Priority	Processing order — lower number = higher priority	100 to 4096
Source	Where traffic originates	IP/CIDR, service tag, ASG, or Any
Source port range	Originating port(s)	Port number, range, or * (any)
Destination	Where traffic is going	IP/CIDR, service tag, ASG, or Any
Destination port range	Target port(s)	Port number, range, or *
Protocol	Transport protocol	TCP, UDP, ICMP, ESP, AH, or Any
Action	What to do with matching traffic	Allow or Deny

Rules are evaluated in priority order (lowest number first). Once a match is found, processing stops. If no rule matches, the default rules apply.

Default Rules

Every NSG comes with three default inbound and three default outbound rules that cannot be deleted (but can be overridden with higher-priority rules):

Default inbound rules:

Priority	Name	Source	Destination	Port	Action
65000	AllowVnetInBound	VirtualNetwork	VirtualNetwork	Any	Allow
65001	AllowAzureLoadBalancerInBound	AzureLoadBalancer	Any	Any	Allow
65500	DenyAllInBound	Any	Any	Any	Deny

Default outbound rules:

Priority	Name	Source	Destination	Port	Action
65000	AllowVnetOutBound	VirtualNetwork	VirtualNetwork	Any	Allow
65001	AllowInternetOutBound	Any	Internet	Any	Allow
65500	DenyAllOutBound	Any	Any	Any	Deny

Exam Tip: The VirtualNetwork service tag includes VNet address space, peered VNet space, on-premises ranges connected via VPN/ER, and addresses in service endpoints. It’s broader than just the local VNet.

Association Levels

NSGs can be associated at two levels:

Level	What It Protects	Scope
Subnet	All resources in the subnet	Shared rules for the entire subnet
NIC	Individual VM’s network interface	Per-VM rules (more granular)

When both are associated (common pattern):

• Inbound: Traffic must pass BOTH the subnet NSG AND the NIC NSG. Both must allow the traffic.
• Outbound: Traffic must pass the NIC NSG first, then the subnet NSG. Both must allow it.

💡 NSG Evaluation Order: Subnet + NIC

When NSGs are applied at both subnet and NIC levels, evaluation order depends on traffic direction:

Inbound traffic: Subnet NSG evaluates first, then NIC NSG. Both must allow the traffic for it to reach the VM. If the subnet NSG denies, the NIC NSG never sees it.

Outbound traffic: NIC NSG evaluates first, then subnet NSG. Both must allow the traffic for it to leave. If the NIC NSG denies, the subnet NSG never sees it.

Key exam point: It is not enough for one NSG to allow — both must allow. A deny at either level blocks the traffic. This is why best practice is to use subnet-level NSGs for broad rules and only add NIC-level NSGs when specific VMs need different treatment.

Best practice: Associate NSGs at the subnet level for broad rules (allow HTTPS, deny RDP from internet). Use NIC-level NSGs only when specific VMs need different rules from their peers.

NSG vs Azure Firewall

Feature	Network Security Group (NSG)	Azure Firewall
OSI layer	Layer 3/4 (IP, port, protocol)	Layer 3/4 plus limited Layer 7 (FQDN filtering)
Scope	Per-subnet or per-NIC	Centralised in hub VNet or VWAN hub
FQDN filtering	No — IP addresses and service tags only	Yes — filter by domain name in application rules
Threat intelligence	No	Yes — block known-malicious IPs and domains
Centralised management	Per-VNet — each team manages their own NSGs	Single firewall with policies for all spokes
IDPS	No	Yes (Premium SKU) — signature-based intrusion detection
Cost	Free	Per-hour plus per-GB processed
Best for	Workload-level micro-segmentation within a VNet	Centralised network-wide traffic control and logging

Application Security Groups (ASGs)

ASGs let you write security rules based on application roles instead of IP addresses.

🔒 Aisha’s scenario: Sentinel Banking has three tiers: web servers, API servers, and database servers. Instead of maintaining rules with individual VM IPs, she creates ASGs:

1. Create ASGs: WebServers, ApiServers, DbServers
2. Assign VMs: Each VM’s NIC is associated with its ASG
3. Write rules using ASG names:

Priority	Source	Destination	Port	Action	Meaning
100	Internet	WebServers	443	Allow	HTTPS to web tier
110	WebServers	ApiServers	8080	Allow	Web calls API
120	ApiServers	DbServers	1433	Allow	API calls database
130	Any	DbServers	Any	Deny	Block all else to DB

Benefits:

• Rules are intent-based — “WebServers can talk to ApiServers” is clearer than IP-based rules
• When you add a new web server, assign it to the WebServers ASG — no rule changes needed
• Scale without maintaining IP lists

Exam Tip — ASG Constraints:

• All NICs in an ASG must be in the same VNet (not across VNets)
• A NIC can belong to multiple ASGs
• Source and destination in the same rule can both be ASGs, but they must be in the same VNet
• You cannot use ASGs in rules across peered VNets (use IP ranges or service tags instead)

NSG for Azure Bastion

Azure Bastion has specific NSG requirements on the AzureBastionSubnet:

Required inbound rules:

Source	Port	Protocol	Purpose
Internet	443	TCP	User sessions to Bastion
GatewayManager	443	TCP	Control plane communication
AzureLoadBalancer	443	TCP	Health probes
VirtualNetwork	8080, 5701	Any	Data plane (internal)

Required outbound rules:

Destination	Port	Protocol	Purpose
VirtualNetwork	3389, 22	TCP	RDP/SSH to target VMs
AzureCloud	443	TCP	Logging and diagnostics
VirtualNetwork	8080, 5701	Any	Data plane (internal)
Internet	80	TCP	Certificate revocation checks

Exam Tip: The Bastion NSG requirements are a high-frequency exam topic. Key ports: inbound 443 from Internet (user sessions), outbound 3389/22 to VirtualNetwork (RDP/SSH to VMs), outbound 443 to AzureCloud (logging).

Key Takeaways

• NSG rules are evaluated by priority (lowest number first); first match wins
• Default rules allow VNet-to-VNet and outbound internet; deny everything else inbound
• When NSGs are on both subnet and NIC, traffic must pass both
• ASGs enable intent-based rules using application role names instead of IPs
• Bastion has specific NSG requirements — memorise the key ports

---

Test Your Knowledge

Question

In what order are NSG rules evaluated?

Click or press Enter to reveal answer

Answer

By priority number, lowest first (100 before 200). Once a matching rule is found, processing stops. If no custom rule matches, default rules at priority 65000-65500 apply.

Click to flip back

Question

What happens when an NSG is associated with both the subnet and the NIC?

Click or press Enter to reveal answer

Answer

For inbound: traffic must pass both the subnet NSG and the NIC NSG. For outbound: traffic must pass the NIC NSG first, then the subnet NSG. Both must allow the traffic for it to flow.

Click to flip back

Question

What is the key constraint for ASG membership?

Click or press Enter to reveal answer

Answer

All NICs in an ASG must be in the same VNet. ASGs cannot span across VNets. A NIC can belong to multiple ASGs, and rules can use ASGs as both source and destination.

Click to flip back

Question

What inbound traffic must the AzureBastionSubnet NSG allow?

Click or press Enter to reveal answer

Answer

Port 443 from Internet (user sessions), port 443 from GatewayManager (control plane), port 443 from AzureLoadBalancer (health probes), and ports 8080/5701 from VirtualNetwork (data plane).

Click to flip back

---

Knowledge Check

Aisha creates an NSG rule at priority 100 that denies port 443 inbound, and another at priority 200 that allows port 443 from her ASG. Which applies?

AThe Allow rule at 200 because it's more specificBThe Deny rule at 100 because it has higher priority (lower number)CBoth apply — traffic is both denied and allowedDNeither — default rules override custom rules

Check Answer

Knowledge Check

Sam adds a new web server VM and assigns its NIC to the WebServers ASG. What else does he need to do for existing NSG rules to apply?

AUpdate every NSG rule to include the new VM's IPBNothing — the VM inherits rules targeting the WebServers ASG automaticallyCCreate a new NSG for the VMDReassociate the NSG with the new VM's subnet

Check Answer

---

Next up: Flow Logs, IP Flow Verify and Network Manager Security — Diagnose NSG issues and enforce security policies with AVNM security admin rules.