Skip to main content
Network Security Groups (NSGs) in Azure control inbound and outbound network traffic to Azure resources using a set of rules. This guide explains when to use NSGs, the core concepts and rule evaluation order, and a hands-on demonstration showing how subnet- and NIC-level NSGs interact.

​
Azure Firewall vs NSG — when to use each

  • Azure Firewall is best for centralized, large-scale policy management, logging, and Layer 7 (application) filtering such as FQDN or URL-based rules.
  • NSGs are best for Layer 4 filtering (IP protocol, port, source/destination address prefixes) applied to subnets, NICs, or individual VMs.
  • You can (and often should) use both: Azure Firewall for broad, centralized policies and NSGs for subnet- or NIC-level exceptions and microsegmentation. Even if the firewall allows traffic, NSGs can still block it at the subnet or NIC level.
NSGs operate at OSI Layer 4 (transport layer). They do not inspect Layer 7 (application) payloads — use Azure Firewall or application-aware appliances for L7 filtering.
Table — quick comparison

​
Core NSG concepts

  • Filtering: NSGs allow or deny traffic based on source/destination IPs, protocols, and ports.
  • Rule set and priority: Each rule has a numeric priority. Lower numbers are evaluated before higher numbers (priority 100 is evaluated before 400). User-created priorities range from 100–4096. Azure default rules use high numeric values (65,000+). Defaults cannot be removed but can be overridden by user rules with a higher priority (lower numeric value).
  • Association: NSGs can be associated with subnets or network interfaces (NICs), and a single NSG can be attached to multiple resources.
  • Evaluation: Subnet- and NIC-level NSG rules are evaluated independently. For traffic to succeed, all NSGs that apply to the traffic path must allow it.
A presentation slide titled "Explore Network Security Groups (NSG)" showing four colorful tiles/icons labeled Service, Priority, Port Range, and Action, each with a matching symbol. The slide also includes a small copyright notice for KodeKloud.

​
NSG rule attributes (brief)

  • Service: Use predefined or custom services (e.g., HTTP, HTTPS, SSH, RDP) which map to ports.
  • Port range: Single ports, comma-separated lists, or ranges (e.g., 80, 80,443, 1024-65535).
  • Priority: Numeric priority for evaluation order (user range 100–4096, defaults are 65,000+).
  • Action: Allow or Deny.

​
How subnet vs NIC evaluation works (summary)

  • Inbound traffic from the internet → Subnet NSG evaluated first (if present) → then NIC NSG.
  • Outbound traffic initiated from a VM → NIC NSG evaluated first → then Subnet NSG.
  • A deny in any evaluated NSG blocks the traffic. A traffic path is allowed only if all evaluated NSGs permit it.

​
Demonstration setup and walkthrough

The demo uses a PowerShell script (nsg-prep-infra.ps1) that creates the resource group, virtual networks, and four VMs (workload-a-vm-1/2 and workload-b-vm-1/2). Confirm your subscription context before running the script. Example PowerShell session (trimmed):
After deployment, the VMs appear in the Azure portal with public IPs and associated NICs.
A screenshot of the Microsoft Azure portal showing the "Virtual machines" list with five VMs (adVM and several workload VMs) and columns for subscription, resource group, location, status, OS and public IP. Most entries show Linux VMs in a Running state while one (adVM) is Stopped (deallocated) and running Windows.

​
Checking the NSG attached to a VM

  • The prep script attached an NSG to each VM NIC that permits SSH (port 22) so you can connect.
  • Default NSG rules (AllowVNetInBound, AllowAzureLoadBalancerInBound, DenyAllInBound, etc.) appear in every NSG and cannot be removed. User rules can override these defaults by using a lower numeric priority.
Default NSG rules cannot be deleted. To change behaviour, create user rules with a higher priority (lower numeric value) — e.g., priority 100 overrides default rules in the 65,000+ range.

​
Install a web server on workload-a-vm-1

SSH example (from your client):
On the VM (bash):
The web server is responding on the VM, but port 80 is not yet open externally.

​
Opening port 80 with an NSG inbound rule

From the VM’s Networking blade, add an inbound security rule:
  • Source: Any
  • Service: HTTP
  • Action: Allow
  • Priority: 100 (or another appropriate value)
  • Name: Allow-HTTP
After adding the rule, opening the VM’s public IP in a browser should show the “From VM-A-1” page.

​
Testing cross-subnet connectivity and overriding default allow rules

By default, Azure allows VNet traffic (via default AllowVNetInBound/OutBound rules). You can create a user deny rule that blocks traffic from a specific source CIDR and has a higher priority (lower numeric value) than default rules. Example — before deny rule (from workload-b-vm-1):
After creating a deny rule on the target NSG that blocks source 192.168.2.0/24 with priority 100:
This shows a user-created deny rule with higher priority can block traffic that default rules would otherwise allow.
A screenshot of the Microsoft Azure portal showing the Virtual Machines blade with the Networking settings for "workload-a-vm-1." It displays the VM's network interface, IP addresses and listed outbound port/security group rules.

​
Creating an NSG and associating it with a subnet

Steps:
  1. Create a new NSG (example name: block-ssh-nsg).
  2. Add an inbound rule to Deny SSH (TCP port 22) from Any.
  3. Associate the NSG with a subnet (for example, subnet B).
Important: For inbound traffic, subnet-level NSG rules are evaluated before NIC-level rules. If the subnet NSG denies SSH, NIC-level allow rules are never evaluated and SSH will be blocked.
Screenshot of the Microsoft Azure portal showing the "Network security groups" page. It lists five NSGs (win-iis-01-nsg, workload-a-vm-1, workload-a-vm-2, workload-b-vm-1, workload-b-vm-2) with a filter/toolbar across the top.
Create NSG and deploy (portal confirmation):
A screenshot of the Microsoft Azure portal on the "Create network security group" page showing validation passed and review details (subscription, resource group, region and name: block-ssh-nsg). A deployment notification is visible in the top-right corner.
After deployment, add the deny rule and associate the NSG with the target subnet.
A screenshot of the Microsoft Azure portal showing the deployment overview for "Microsoft.NetworkSecurityGroup-20230929123037." It displays a green check with the message "Your deployment is complete" and deployment details plus a "Go to resource" button.

​
Verify SSH is blocked by the subnet NSG

Attempting to SSH to any VM in the subnet after the subnet-level deny:
This confirms the subnet NSG blocked SSH before the NIC-level rule could allow it.

​
Viewing inbound rules (default + custom)

You can view the combined default and custom inbound rules in the NSG’s Inbound Security Rules blade.
A screenshot of the Microsoft Azure portal showing a Network Security Group named "block-ssh-nsg" and its Inbound security rules. The list displays default rules (AllowVnetInBound, AllowAzureLoadBalancer..., DenyAllInBound) with priorities, ports, sources/destinations, and Allow/Deny actions.

​
Augmented NSG rules

Augmented NSG rules let you consolidate multiple ports and IP ranges into a single rule to simplify management:
  • Multiple ports: comma-separated (e.g., 22,80,443)
  • Port ranges: hyphen (e.g., 10000-20000)
  • Multiple IP ranges: comma-separated CIDRs (e.g., 192.168.1.0/24,192.168.3.0/24)
This reduces the number of individual rules you must manage while preserving clear intent.

​
Wrap-up and best practices

  • NSGs provide efficient Layer 4 controls for Azure resources at subnet and NIC scopes.
  • Use subnet NSGs for common, per-subnet rules and NIC NSGs for per-VM overrides.
  • A deny at any evaluated level blocks traffic; traffic is allowed only if all evaluated NSGs permit it.
  • For application-aware filtering, centralized logging, and policy at scale, combine NSGs with Azure Firewall or rely on Azure Firewall alone where appropriate.
  • Use Application Security Groups (ASGs) to group VMs logically and reference those groups in NSG rules for cleaner, scalable policies.

Watch Video