Lesson 15 — Network Security Groups & Application Security Groups

Domain 4 — Networking AZ-104: 15–20% ~30 min Prereq: Lesson 14 — Virtual Networks

Why You Need to Understand This

Network Security Groups are the primary traffic-filtering mechanism for IaaS workloads in Azure. Every production VM should have NSG rules controlling what can reach it and what it can reach — full stop. Misconfigured NSGs are the most common root cause of "my application can't connect" tickets and, at the other extreme, "our database was exposed to the internet" incidents.

On the AZ-104 exam, NSG questions are consistently among the highest-yield networking topics. You must understand rule evaluation order, the stateful nature of NSGs, service tags, the ASG model, and how to troubleshoot using effective security rules and IP flow verify. All of these appear regularly in scenario questions.

NSG Fundamentals

An NSG (Network Security Group) is a stateful, Layer 4 packet filter. It contains a list of inbound security rules and a list of outbound security rules. Each rule either allows or denies traffic matching the specified criteria. NSGs operate at the network layer — they see IP headers and TCP/UDP port numbers, not application-layer content.

Where NSGs can be attached

  • Subnet: the NSG applies to all resources (VMs, private endpoints, etc.) in the subnet. All traffic entering or leaving the subnet is evaluated against the NSG's rules.
  • NIC (Network Interface Card): the NSG applies to a single VM's network interface. Provides per-VM granularity within a shared subnet.
  • Both can be applied simultaneously to the same VM — inbound traffic passes through the subnet NSG first, then the NIC NSG. Outbound traffic passes through the NIC NSG first, then the subnet NSG.
NSG is stateful This is the single most important fact about NSGs. If an inbound rule allows TCP port 443, the corresponding outbound return traffic for that established connection is automatically allowed without any explicit outbound rule. You do not need to create a matching outbound allow rule for TCP 443. This is fundamentally different from stateless firewalls.

Security Rule Properties

Every NSG rule has these configurable properties:

PropertyValuesNotes
Priority100 – 4096Lower number = higher priority. Rules are evaluated in ascending priority order; first match wins.
NameString (unique per NSG)Descriptive names improve operational clarity: Allow-HTTPS-From-Internet
SourceAny, IP/CIDR, Service Tag, ASGWhere traffic originates
Source port rangePort number, range, or *Usually * for inbound (client ports are ephemeral); specific ports for outbound
DestinationAny, IP/CIDR, Service Tag, ASGWhere traffic is going
Destination port rangePort number, range (80,443), or *The service port the rule is protecting
ProtocolTCP, UDP, ICMP, ESP, AH, AnyUse TCP for web traffic, ICMP for ping rules
ActionAllow / DenyWhat happens to matching traffic
First match wins — order matters NSG rules are evaluated from lowest priority number (highest priority) to highest number. The first rule that matches the traffic determines the outcome. Rules after the match are not evaluated. This means you can create a low-priority (high number) Deny-All rule and punch specific Allow rules above it at lower priority numbers.

Default Rules (Always Present)

Every NSG is created with a fixed set of default rules that cannot be deleted. They sit at very high priority numbers (65000+) and represent the minimum baseline behaviour. You can override them by creating your own rules with lower priority numbers.

Inbound default rules

Rule namePrioritySourceDestinationAction
AllowVnetInBound65000VirtualNetworkVirtualNetworkAllow
AllowAzureLoadBalancerInBound65001AzureLoadBalancerAnyAllow
DenyAllInBound65500AnyAnyDeny

Outbound default rules

Rule namePrioritySourceDestinationAction
AllowVnetOutBound65000VirtualNetworkVirtualNetworkAllow
AllowInternetOutBound65001AnyInternetAllow
DenyAllOutBound65500AnyAnyDeny
AllowAzureLoadBalancerInBound is critical If you add a DenyAllInBound rule above priority 65001 (e.g. at priority 100) to lock down a subnet, you also block Azure Load Balancer health probes. Health probes originate from 168.63.129.16, which is represented by the AzureLoadBalancer service tag. If health probes are blocked, the backend VM appears unhealthy and the Load Balancer stops sending it traffic — even if your application is running perfectly. Always include an explicit Allow rule for AzureLoadBalancer if you are locking down a load-balanced subnet.

NSG Attachment & Rule Evaluation

Understanding the order in which NSGs are evaluated is essential for troubleshooting connectivity and passing exam scenario questions.

Inbound traffic path (e.g. internet → VM)

Internet source → Subnet NSG evaluated first (inbound rules) → If allowed: NIC NSG evaluated second (inbound rules) → If allowed: traffic reaches VM application

Outbound traffic path (e.g. VM → internet)

VM application sends traffic → NIC NSG evaluated first (outbound rules) → If allowed: Subnet NSG evaluated second (outbound rules) → If allowed: traffic leaves to destination
Both NSGs must allow the traffic When a subnet NSG and NIC NSG are both applied, a Deny in either NSG blocks the traffic — regardless of what the other NSG says. The effective result is the most restrictive combination. A common troubleshooting mistake is fixing the subnet NSG and forgetting to also fix the NIC NSG, or vice versa.

Effective security rules

When a VM has both a subnet NSG and a NIC NSG, seeing the actual combined ruleset can be difficult. Use Effective security rules — found in the VM's NIC blade under Support + troubleshooting → Effective security rules. This view shows the fully merged, prioritised inbound and outbound rule set that Azure is actually enforcing on that NIC.

Service Tags

Service tags are named groups of IP address prefixes managed and updated by Microsoft. Instead of maintaining static IP address lists in your NSG rules, you reference a service tag — Microsoft keeps the underlying IP ranges current as Azure services grow and change infrastructure.

Key service tags to memorise

Service tagRepresentsCommon use
VirtualNetworkAll VNet address space + peered VNets + on-prem connected rangesAllow intra-VNet communication (default rule)
InternetAll public IP addresses not within VirtualNetworkAllow/deny internet access
AzureLoadBalancerAzure health probe source (168.63.129.16)Allow load balancer health probes
StorageAzure Storage service IP rangesAllow outbound to Storage without enumerating IPs
SqlAzure SQL Database and Azure Synapse IP rangesAllow outbound to SQL service endpoints
AzureMonitorLog Analytics, Application Insights endpointsAllow diagnostic data outbound from VMs
AppServiceApp Service and Function App inbound IP rangesRestrict inbound to App Service outbound IPs
EventHubAzure Event Hubs service IP rangesAllow outbound to Event Hub
KeyVaultAzure Key Vault service IP rangesAllow outbound to Key Vault
Why service tags matter operationally Azure regularly adds new datacenter capacity, which means new IP ranges for Azure services. If you hard-code IP ranges in NSG rules instead of using service tags, those rules silently break when Microsoft adds new IPs. Service tags are automatically updated — using them is not just convenient, it is operationally correct. Use them for any Azure-managed service.

Application Security Groups (ASGs)

Application Security Groups let you define security rules based on application role rather than IP address. Instead of writing rules like "allow 10.20.1.4 and 10.20.1.5 and 10.20.1.6 to reach 10.20.2.4 on port 8080", you write "allow asg-webservers to reach asg-appservers on port 8080".

How ASGs work

  1. Create an ASG resource (e.g. asg-webservers, asg-appservers, asg-dbservers).
  2. Assign VM NICs to ASGs — a NIC can belong to multiple ASGs.
  3. Reference ASGs as source or destination in NSG rules instead of IP addresses.
  4. When a VM is added to or removed from an ASG, the NSG rules automatically apply or cease to apply — no rule editing required.

Example NSG rules using ASGs

Rule 100 Inbound Allow:
  Source: asg-webservers   Destination: asg-appservers   Port: 8080  Protocol: TCP

Rule 110 Inbound Allow:
  Source: asg-appservers   Destination: asg-dbservers    Port: 1433  Protocol: TCP

Rule 4000 Inbound Deny:
  Source: *                Destination: asg-dbservers    Port: *     Protocol: *

With these rules, web servers can reach app servers, app servers can reach the database — and nothing else can reach the database directly. When you scale out by adding new web VMs, you assign their NICs to asg-webservers and rule 100 immediately applies. Zero rule changes required.

ASG cross-VNet limitation The source and destination ASGs referenced in the same NSG rule must be in the same VNet. You cannot write a single NSG rule that spans ASGs from two different VNets, even if those VNets are peered. This is a common gotcha in multi-VNet architectures — use IP ranges or service tags for cross-VNet rules.

ASG vs IP-based rules — when to use each

ScenarioUse ASGsUse IP/CIDR
VM-to-VM within same VNetYes — role-based, scale-friendlyWorks but brittle to IP changes
On-premises to AzureNot applicableYes — use on-prem CIDR ranges
Cross-VNet (peered)Not supported across VNetsYes — use the remote VNet CIDR
Azure service (Storage, SQL)Not applicableUse Service Tags instead
Dynamic VM fleets (VMSS, auto-scale)Yes — new instances auto-inherit rulesImpractical — IPs change constantly

NSG Flow Logs & Traffic Analytics

NSG Flow Logs capture metadata about every accepted and denied flow through an NSG. This is not packet capture — it is flow-level telemetry (source IP, destination IP, source port, destination port, protocol, direction, action).

Flow log versions

  • Version 1: basic flow information — 5-tuple + direction + action.
  • Version 2: adds bytes transferred and packets per flow, enabling bandwidth analysis and anomaly detection.

Storage and processing

  • Flow logs are written as JSON to a Storage Account you specify. Each log entry represents a flow within a 1-minute aggregation window.
  • Traffic Analytics processes flow logs through a Log Analytics Workspace to produce visual dashboards, geographic traffic maps, threat detection, and top-talker analysis. It ingests and aggregates flow data at configurable intervals (every 10 minutes or every 60 minutes).
Enable flow logs on all production NSGs NSG flow logs are the primary evidence source for network incident response. Without them, you cannot answer "what traffic was hitting that VM before it was compromised?" or "is our compliance boundary actually being enforced?". The cost is low — primarily storage for the JSON blobs. Enable version 2 flow logs and Traffic Analytics on every production NSG.

Troubleshooting NSG Issues

NSG troubleshooting has a standard toolkit in Azure. Know all three tools for the exam.

Tool 1 — IP Flow Verify (Network Watcher)

Tests whether a hypothetical flow would be allowed or denied by the NSGs on a VM's NIC. You specify: VM, NIC, direction (inbound/outbound), source IP, destination IP, protocol, and port. Azure evaluates all NSGs and returns the first matching rule and its action (allow/deny).

Use when: "I need to know if TCP 443 from 1.2.3.4 to my VM would be allowed right now, without actually sending traffic."

Tool 2 — Effective Security Rules

Shows the merged, sorted list of all NSG rules actually applied to a specific NIC — combining rules from both the subnet NSG and the NIC NSG in a single view, sorted by priority. Available in the NIC blade under Support + troubleshooting.

Use when: "Traffic is being blocked and I can't figure out which rule is doing it."

Tool 3 — NSG Flow Logs + Traffic Analytics

Provides historical analysis of what traffic actually flowed (and was denied) through an NSG. Unlike IP Flow Verify (which is hypothetical), flow logs show real traffic from the past.

Use when: "An incident occurred 3 hours ago and I need to know what traffic was allowed or denied."

Connection Monitor is separate Connection Monitor (also in Network Watcher) continuously tests end-to-end connectivity between endpoints and alerts on failures. It is not the same as IP Flow Verify. IP Flow Verify is a one-time, on-demand test against the NSG ruleset only. Connection Monitor tests actual network reachability end to end, including DNS, routing, and application-level responses.

AZ-104 Exam Traps

Trap 1 — NSGs are stateful Allowing inbound TCP 443 automatically allows return traffic. You do NOT need an outbound allow rule for TCP 443. If an exam question asks "what additional rule do you need to add for the response traffic to flow?", the answer is NONE — the NSG handles this automatically. Stateless firewalls (old on-prem ACLs) require both directions; NSGs do not.
Trap 2 — Load Balancer health probes need AzureLoadBalancer tag If your VMs behind a Standard Load Balancer appear unhealthy despite the application running, check for an NSG rule that blocks the AzureLoadBalancer service tag. Health probes come from 168.63.129.16 — if this is blocked, the VM appears down to the Load Balancer. The fix is to add an Allow rule for source AzureLoadBalancer above any DenyAll rule.
Trap 3 — Both NSGs must allow for traffic to flow With a subnet NSG and NIC NSG both applied, traffic must pass BOTH. A common exam scenario: subnet NSG allows HTTP, but NIC NSG has a DenyAll — the traffic is blocked. The answer is always to fix the blocking NSG (whichever one denies the traffic), not to remove one NSG entirely.
Trap 4 — ASG members must be in the same VNet Source and destination ASGs in a single NSG rule must be in the same VNet. If the question describes VMs in different VNets, ASGs cannot be used for cross-VNet rules — use IP ranges or service tags.

Check Your Understanding

Click any option to see immediate feedback. Answers reflect real Azure behaviour.

1. An NSG allows inbound TCP on port 443 from the Internet. There is no outbound rule for TCP 443. Will HTTPS responses from the VM reach external clients?

NSGs are stateful — this is one of the most tested facts on AZ-104. When an inbound allow rule permits an initial packet, the NSG creates a connection state entry. Return traffic for that established connection is automatically allowed by the stateful tracking mechanism, regardless of outbound rules. You never need to add an explicit outbound allow rule for return traffic. Option C is tempting but wrong — AllowInternetOutBound allows new outbound connections, not return traffic from inbound connections.

2. VMs behind a Standard Load Balancer are marked unhealthy in the Load Balancer's backend health view, even though the application is responding normally. What is the most likely NSG-related cause?

Azure Load Balancer health probes originate from the IP address 168.63.129.16, represented by the AzureLoadBalancer service tag. If an NSG on the subnet or NIC has a DenyAll rule or any deny rule that blocks this source IP, health probes cannot reach the VMs. The Load Balancer marks the backend as unhealthy and stops sending real traffic to it. The fix is to add an explicit inbound Allow rule for the AzureLoadBalancer service tag at a priority lower than the blocking deny rule.

3. A VM has a subnet NSG (allows TCP 80) and a NIC NSG (has no rule for TCP 80, only a DenyAllInBound at priority 4000). Inbound HTTP traffic arrives. What happens?

When both a subnet NSG and NIC NSG are applied, inbound traffic must pass both NSGs. The subnet NSG is evaluated first (allows TCP 80), then the NIC NSG is evaluated. The NIC NSG has no specific Allow rule for TCP 80, so evaluation continues to the DenyAllInBound default rule at priority 4000 (which beats the 65500 DenyAllInBound). The traffic is denied. Option C is wrong because AllowVnetInBound (priority 65000) would only fire if no earlier rule matched — but DenyAllInBound at 4000 fires first.

4. Your team manages a fleet of web VMs and app VMs. You want NSG rules to allow web VMs to reach app VMs on port 8080, with no rule changes required when VMs are added or replaced. What is the optimal approach?

Application Security Groups are designed exactly for this scenario. Create asg-webservers and asg-appservers, then write one NSG rule: Allow source=asg-webservers, destination=asg-appservers, port=8080, TCP. When new web VMs are provisioned, assign their NICs to asg-webservers — the rule immediately applies without any modification. Option B works but lacks precision — it allows any VM in the /24 range to reach the app tier, not just web servers.

5. You need to audit which traffic was blocked by an NSG on a production VM during a security incident that occurred 2 hours ago. Which tool provides this information?

NSG Flow Logs are the correct answer for historical traffic analysis. They log every accepted and denied flow through the NSG as JSON blobs in a Storage Account, with timestamps, allowing you to reconstruct what happened during a past incident. IP Flow Verify is a real-time, hypothetical test — it tells you what would happen now, not what happened in the past. Effective security rules show the current rule configuration, not historical traffic. Flow logs (especially with Traffic Analytics) are essential for incident response.

6. You want to allow outbound traffic from VMs in a subnet to Azure Storage without maintaining a static list of Azure Storage IP ranges that might change. What should you use as the destination in the NSG rule?

The Storage service tag represents all Azure Storage service IP ranges and is automatically updated by Microsoft when those ranges change. Using it means your NSG rule remains correct even as Microsoft adds new Storage infrastructure. Hard-coding IP ranges (option A) creates operational burden and fails silently when Microsoft adds new IPs that aren't in your list. The Internet tag (option D) is too broad — it would also allow access to non-Azure internet destinations.
Primary source for this lesson Network Security Groups — Overview (Microsoft Learn)

Read the full overview article and the linked Application Security Groups article. The Microsoft documentation on effective security rules and how both subnet and NIC NSGs are evaluated is particularly important for exam scenarios.

Questions for your teacher (the AI agent)
This lesson covered NSG fundamentals, default rules, ASGs, flow logs, and troubleshooting. Go deeper on:
  • Walk me through the complete NSG rule evaluation sequence when a packet arrives at a VM with both a subnet NSG and a NIC NSG — include the exact order of evaluation for inbound vs outbound.
  • How do I design NSG rules for a three-tier application (web, app, data) using ASGs, minimising the number of rules while maximising security?
  • Explain how Traffic Analytics works internally — what does it do with flow log JSON blobs and what queries does it run in Log Analytics?
  • When should I use NSG service endpoints vs Private Endpoints for securing access to Azure Storage, and how does the NSG rule change?
Coming up: Lesson 16 — VNet Peering, Service Endpoints & Private Endpoints You can now build and secure a VNet. The next lesson covers how to connect VNets to each other (peering), how to secure access to Azure PaaS services (service endpoints vs private endpoints), and the DNS configuration that makes private endpoints work. This is one of the highest-density networking topics on AZ-104.