This chapter covers Azure Network Security Groups (NSGs), a fundamental network security service that acts as a virtual firewall for your Azure resources. NSGs are critical for controlling inbound and outbound traffic to and from Azure virtual networks, and they appear frequently on the AZ-900 exam under objective 2.3 (Azure Architecture Services), which carries approximately 15-20% of the exam weight. Understanding NSGs is essential for securing cloud workloads and for answering scenario-based questions about traffic filtering.
Jump to a section
Imagine you own a large office building with multiple floors, each floor containing different departments. You hire a security guard (the Network Security Group) at the entrance of each floor. The guard has a rulebook: a list of allowed and denied visitors based on their badge ID (source IP), the floor they want to visit (destination IP), and what they want to do (port/protocol). For example, the guard on the finance floor only lets in people with a 'finance' badge (source IP range) and only during business hours. If a person tries to enter without a badge, the guard checks the rulebook: if no rule explicitly allows them, they are denied by default. The guard also keeps track of which floor the person is coming from (internal traffic) versus outside the building (internet traffic). Importantly, each floor's guard has its own rulebook, and rules are evaluated in order until a match is found. If a rule says 'deny all from floor 2', the guard blocks that person even if another rule later says 'allow'. This is exactly how NSGs work: they are stateful firewalls that filter traffic at the subnet or NIC level, using priority-ordered rules, with a default deny inbound and allow outbound.
What is an Azure Network Security Group (NSG)?
An Azure Network Security Group (NSG) is a cloud-scale stateful firewall that filters network traffic to and from Azure resources. It contains a set of security rules that allow or deny inbound and outbound traffic based on source/destination IP addresses, ports, and protocols. NSGs can be associated with a subnet or a virtual network interface card (NIC) of a virtual machine (VM). When associated with a subnet, the rules apply to all resources within that subnet (e.g., VMs, load balancers). When associated with a NIC, the rules apply only to that specific VM.
The Business Problem NSGs Solve
In on-premises networks, administrators use hardware firewalls or software firewalls on each server to control traffic. In Azure, resources are virtualized and can be created/deleted rapidly. Traditional hardware firewalls can't keep up with dynamic IP assignments and auto-scaling. NSGs provide a software-defined, scalable, and cost-effective way to enforce security policies without managing physical devices. They allow you to implement the principle of least privilege: only necessary traffic is allowed, and everything else is denied.
How NSGs Work - Step by Step Mechanism
Rule Creation: An NSG consists of zero or more security rules. Each rule has: Name, Priority (100-4096), Source/Destination (IP addresses, service tags, application security groups), Protocol (TCP, UDP, ICMP, Any), Direction (Inbound or Outbound), Action (Allow or Deny).
Rule Evaluation: Rules are evaluated in priority order (lowest number first). As soon as a rule matches the traffic, the action (allow/deny) is applied, and no further rules are processed. If no rule matches, the default rules apply.
Default Rules: Azure creates three default inbound rules and three default outbound rules. Inbound: DenyAllInbound (priority 65500), AllowVNetInBound (65000, allows traffic from within the virtual network), AllowAzureLoadBalancerInBound (65001, allows health probes). Outbound: AllowVNetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500). Default rules cannot be deleted but can be overridden by higher-priority custom rules.
Stateful Behavior: NSGs are stateful. If you allow inbound traffic on port 443, the return traffic is automatically allowed regardless of outbound rules. Similarly, if you allow outbound traffic, the response is allowed inbound. This simplifies rule creation.
Association: An NSG can be associated with a subnet or a NIC, but not both at the same time for the same resource? Actually, both can be applied: subnet-level NSG rules are evaluated first, then NIC-level rules. Traffic must pass both sets of rules to be allowed. This allows layered security.
Key Components
Security Rules: The core of an NSG. Each rule has a priority (unique within the NSG), source/destination (can be IP addresses, CIDR blocks, service tags like Internet, VirtualNetwork, AzureLoadBalancer, or application security groups), port ranges (e.g., 80, 443, 1-65535), protocol (TCP, UDP, ICMP, or Any), direction, and action.
Service Tags: Pre-defined labels for Azure services. Common tags: Internet (any public IP), VirtualNetwork (all VNet addresses including peered), AzureLoadBalancer (Azure's load balancer health probes), Sql (Azure SQL endpoints). Service tags simplify rule creation because they automatically update as Azure IP ranges change.
Application Security Groups (ASGs): Logical groupings of VMs that share a common function (e.g., web servers, database servers). You can use ASGs as source/destination in NSG rules instead of IP addresses. This allows you to write rules like "allow web servers to talk to database servers" without hardcoding IPs.
Effective Security Rules: When troubleshooting, you can view the effective rules for a NIC or subnet. This shows all rules that apply (from subnet and NIC NSGs) after evaluation.
Pricing
NSGs themselves are free. There is no charge for creating NSGs or rules. However, data transfer costs may apply for traffic that flows through them (standard network bandwidth charges). This makes NSGs a cost-effective security layer.
On-Premises Equivalent
In on-premises environments, a firewall appliance (e.g., Cisco ASA, Palo Alto) is typically used. NSGs are similar but are software-defined, have no hardware limits, and integrate natively with Azure. Unlike on-premises firewalls, NSGs do not support intrusion detection/prevention (IDS/IPS), deep packet inspection, or application-layer filtering. For those features, you need Azure Firewall or a third-party NVA.
Azure Portal and CLI Touchpoints
Azure Portal: Navigate to "Network Security Groups" under "All services". Create an NSG, add rules, associate with subnets/NICs via the "Subnets" or "Network interfaces" blade. You can also view effective rules by selecting a NIC and clicking "Effective security rules".
Azure CLI:
# Create an NSG
az network nsg create --resource-group MyRG --name MyNSG --location eastus
# Create a rule to allow SSH from a specific IP
az network nsg rule create --resource-group MyRG --nsg-name MyNSG --name AllowSSH --priority 100 --source-address-prefixes 203.0.113.0/24 --destination-port-ranges 22 --protocol Tcp --access Allow --direction Inbound
# Associate NSG with subnet
az network vnet subnet update --resource-group MyRG --vnet-name MyVNet --name MySubnet --network-security-group MyNSG
# Show effective rules for a NIC
az network nic show-effective-nsg --resource-group MyRG --name MyNICPowerShell:
# Create NSG
$nsg = New-AzNetworkSecurityGroup -ResourceGroupName MyRG -Location eastus -Name MyNSG
# Add rule
Add-AzNetworkSecurityRuleConfig -Name AllowSSH -NetworkSecurityGroup $nsg -Priority 100 -SourceAddressPrefix 203.0.113.0/24 -DestinationPortRange 22 -Protocol Tcp -Access Allow -Direction Inbound
# Associate with subnet
$vnet = Get-AzVirtualNetwork -ResourceGroupName MyRG -Name MyVNet
$subnet = Get-AzVirtualNetworkSubnetConfig -Name MySubnet -VirtualNetwork $vnet
$subnet.NetworkSecurityGroup = $nsg
Set-AzVirtualNetwork -VirtualNetwork $vnetIdentify Traffic Requirements
Before creating an NSG, you must determine what traffic needs to be allowed or denied. For example, a web server VM needs inbound HTTP (port 80) and HTTPS (port 443) from the internet, and outbound access to the internet for updates. A database VM should only accept traffic from the web server subnet on port 1433. Document source/destination IP ranges, ports, and protocols. This step is crucial for the principle of least privilege.
Create the NSG and Rules
In the Azure portal, go to 'Network Security Groups' and click 'Create'. Provide a name, resource group, and region. After creation, add inbound and outbound rules. Each rule requires a priority (100-4096), name, source/destination (IP, service tag, or ASG), port range, protocol (TCP, UDP, ICMP, or Any), and action (Allow/Deny). Remember that rules are evaluated in priority order. For example, to allow HTTP from anywhere, create a rule with priority 100, source 'Internet' or 'Any', destination port 80, protocol TCP, action Allow. Avoid using low priorities for broad deny rules as they can block desired traffic.
Associate the NSG with a Subnet or NIC
An NSG must be associated with at least one subnet or NIC to take effect. To associate with a subnet, go to the NSG's 'Subnets' blade, click 'Associate', select the virtual network and subnet. To associate with a NIC, go to the NIC's 'Network security group' blade. A subnet association applies rules to all resources in that subnet. A NIC association applies only to that specific VM. Both can be used simultaneously: subnet rules are evaluated first, then NIC rules. Traffic must be allowed by both to pass.
Test and Validate Connectivity
After association, test connectivity. For a VM, try to connect via SSH (port 22) or RDP (port 3389). If it fails, check the effective security rules for the NIC. In the portal, select the VM's NIC and click 'Effective security rules'. This shows all rules from subnet and NIC NSGs after evaluation. Common issues: a deny rule with higher priority blocking traffic, or missing allow rules. Use tools like `psping` or `Test-NetConnection` on Windows, or `nc` on Linux.
Monitor and Adjust Rules
NSG rules can be modified at any time. Changes apply immediately. Use Azure Monitor or NSG flow logs to analyze traffic patterns. For example, if you see denied traffic that should be allowed, adjust rules accordingly. Flow logs can be sent to a storage account, Log Analytics, or Event Hubs for analysis. Also consider using Azure Security Center's adaptive network hardening recommendations to tighten rules based on actual traffic.
Scenario 1: Multi-Tier Web Application
A company hosts a three-tier application: web servers, application servers, and database servers. The web servers must accept HTTP/HTTPS from the internet, the app servers only from the web servers, and the database servers only from the app servers on port 1433. They create three subnets: WebSubnet, AppSubnet, and DBSubnet. They create an NSG for each subnet. The WebSubnet NSG allows inbound from 'Internet' on ports 80/443. The AppSubnet NSG allows inbound from the WebSubnet IP range on a custom port (e.g., 8080). The DBSubnet NSG allows inbound from AppSubnet on port 1433. Outbound rules are set to allow only necessary traffic (e.g., web servers can reach the internet for updates, but app and DB servers cannot). This setup ensures isolation. If misconfigured (e.g., DBSubnet allows all inbound), data could be exposed.
Scenario 2: Jump Box Administration
A company uses a jump box (bastion host) to administer VMs in a private subnet. The jump box VM is in a separate subnet (JumpSubnet) with an NSG that allows RDP/SSH only from corporate IP ranges. The private subnet NSG allows RDP/SSH only from the JumpSubnet. This way, admins must first connect to the jump box, then from there to the private VMs. If the private subnet NSG accidentally allows RDP from the internet, attackers could bypass the jump box. Cost: NSGs are free, but the jump box VM incurs compute costs.
Scenario 3: Denying Traffic from a Specific Region
A global e-commerce site wants to block traffic from a specific country due to licensing issues. They create an NSG rule with priority 100 that denies inbound traffic from that country's IP range (obtained from a geo-IP database). However, IP ranges change, so they need to update rules periodically. Alternatively, they could use Azure Firewall with geo-filtering. If they forget to update, legitimate traffic from that region might be allowed or blocked incorrectly. NSG flow logs help identify such issues.
What AZ-900 Tests on NSGs (Objective 2.3)
AZ-900 expects you to understand the purpose of NSGs, how they filter traffic, and typical use cases. You will NOT be asked to create rules or write CLI commands. Focus on concepts: statefulness, priority, default rules, association with subnets vs NICs, and service tags.
Common Wrong Answers and Why Candidates Choose Them
"NSGs can block traffic at the application layer (Layer 7)." – Wrong. NSGs operate at Layers 3 and 4 (IP and TCP/UDP). For Layer 7 filtering, you need Azure Firewall or a WAF. Candidates confuse NSGs with more advanced firewalls.
"NSGs are stateless." – Wrong. NSGs are stateful. The exam may test this directly. Candidates assume all firewalls are stateless.
"Default rules allow all inbound traffic." – Wrong. Default inbound rule denies all traffic from the internet. Only traffic from within the VNet and Azure Load Balancer is allowed. Candidates forget the default deny.
"An NSG can only be associated with a subnet OR a NIC, not both." – Wrong. Both can be applied simultaneously. Traffic must pass both to be allowed. Candidates think it's one or the other.
Specific Terms and Values
Priority range: 100 to 4096 (custom rules). Default rules have priority 65000, 65001, 65500.
Default inbound rules: AllowVNetInBound (65000), AllowAzureLoadBalancerInBound (65001), DenyAllInbound (65500).
Default outbound rules: AllowVNetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500).
Service tags: VirtualNetwork, Internet, AzureLoadBalancer, Sql, Storage, etc.
Stateful: If you allow inbound, return traffic is automatically allowed.
Edge Cases and Tricky Distinctions
NSG vs Azure Firewall: NSG is a distributed, stateful firewall for basic filtering. Azure Firewall is a centralized, managed firewall with advanced features (FQDN filtering, threat intelligence). The exam may ask which to use for outbound HTTP filtering – answer is Azure Firewall.
Application Security Groups (ASGs): Not to be confused with NSGs. ASGs are logical groupings used in NSG rules. They simplify rule management.
Effective rules: When both subnet and NIC NSGs are applied, the effective rule set is the intersection (most restrictive). The exam might ask about this.
Memory Trick
For NSG rule evaluation: Priority, Source, Destination, Protocol, Action – think "PSDPA" or "Please Stop Doing That, Please!". Also remember: Default Deny Inbound, Default Allow Outbound (except for the explicit DenyAllOutbound rule at 65500, but note that AllowInternetOutBound at 65001 takes precedence, so outbound to internet is allowed by default).
NSGs are stateful firewalls that filter traffic at Layers 3 and 4.
Rules are evaluated in priority order (lowest number first); default rules have priority 65000+.
Default inbound rule denies all internet traffic; default outbound allows internet traffic.
NSGs can be associated with subnets, NICs, or both for layered security.
Service tags simplify rules for Azure services (e.g., 'Internet', 'VirtualNetwork').
Application Security Groups (ASGs) allow logical grouping of VMs for rule definitions.
NSGs are free; only data transfer costs apply.
For application-layer filtering (FQDN, HTTP headers), use Azure Firewall.
These come up on the exam all the time. Here's how to tell them apart.
Network Security Group (NSG)
Distributed, stateful firewall at subnet/NIC level
Free (no additional cost)
Filters at Layers 3-4 (IP, port, protocol)
No FQDN filtering, no IDS/IPS
Managed per subnet or NIC, no central logging by default
Azure Firewall
Centralized, managed firewall service
Costs per hour and per GB processed
Filters at Layers 3-7 (supports FQDN filtering)
Includes threat intelligence, IDS/IPS, and application rules
Centralized logging and analytics
Mistake
NSGs can filter traffic based on domain names (FQDNs).
Correct
NSGs cannot filter by FQDN; they work with IP addresses, CIDR blocks, service tags, and ASGs. For FQDN filtering, use Azure Firewall with application rules.
Mistake
NSGs are stateless, so you must create symmetric rules for inbound and outbound.
Correct
NSGs are stateful. If you allow inbound traffic, the response is automatically allowed outbound. You do not need a matching outbound rule.
Mistake
Default rules can be deleted or modified.
Correct
Default rules cannot be deleted or modified. However, you can override them by creating custom rules with higher priority (lower number).
Mistake
An NSG must be associated with both a subnet and a NIC to work.
Correct
An NSG can be associated with a subnet, a NIC, or both. It works if associated with at least one. Both associations provide layered filtering.
Mistake
NSGs can be applied across regions.
Correct
NSGs are region-specific. They can only be associated with resources in the same region as the NSG. For cross-region filtering, use Azure Firewall or VNet peering with NSGs in each region.
An NSG is a distributed, stateful firewall that filters traffic at the subnet or NIC level based on IP addresses, ports, and protocols. It is free and provides basic security. Azure Firewall is a centralized, managed firewall service that offers advanced features like FQDN filtering, threat intelligence, and application rules. It costs per hour and per GB processed. For AZ-900, remember that NSGs are for basic network filtering, while Azure Firewall is for more complex scenarios.
Yes, but indirectly. You can apply an NSG to the subnet containing the VM and a different NSG to the VM's NIC. Both sets of rules apply. Traffic must be allowed by both NSGs to reach the VM. You cannot associate multiple NSGs directly to a single NIC; each NIC can have only one NSG.
Each rule within an NSG must have a unique priority number. If you try to create a rule with a priority that already exists, Azure will reject it. You can modify existing rules, but the priority must be unique.
Create an inbound rule in the NSG associated with the VM's subnet or NIC: priority 100, source 'Internet' or a specific IP range, destination port 3389, protocol TCP, action Allow. Also ensure the VM has a public IP and that the OS firewall allows RDP.
Yes, NSGs are available in all Azure regions. They are a fundamental service and are not region-restricted.
Yes, by default VMs in the same subnet can communicate. To block it, create a deny rule with a higher priority than the default AllowVNetInBound rule. For example, create a rule with priority 100 that denies traffic from the subnet's IP range to the subnet's IP range on all ports.
The maximum number of rules per NSG is 1000 (500 inbound + 500 outbound) for Azure Resource Manager deployments. For classic deployments, it's 200. This limit is important for large environments.
You've just covered Azure Network Security Groups (NSG) — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?