Skip to main content
In this lesson we’ll cover how to create and evaluate Azure Network Security Group (NSG) rules. You’ll learn the key NSG rule components, how rules are evaluated when NSGs are applied to subnets and NICs, and how service tags simplify managing rules for Azure services.

​
Key NSG rule components

ComponentWhat it controlsExample / Notes
ServicePredefined service that auto-fills protocol and port(s)SSH → TCP/22, HTTPS → TCP/443
Custom service / portsUse when you need nonstandard portsPort 8080 or ranges like 1000-2000
Port rangesSingle port, range, or comma-separated mix22, 1000-2000, 22,1000-2000,8080 (augmented security rules)
PriorityNumeric value; lower number = higher precedencePriority 100 evaluates before 200
Source / DestinationAny, IP/CIDR, Service Tag, or Application Security Group (ASG)Any, 10.0.1.0/24, Storage, VirtualNetwork
ActionAllow or DenyDetermines whether matching traffic is permitted
A slide titled "Creating NSG rules" showing the Azure "Add inbound security rule" form with fields filled (Source: Any, Destination: Any, Destination port: 8080, Protocol: Any, Action: Allow, Priority: 100). Blue labels point to the Source and Destination fields and the example rule name is "AllowAnyCustom8080Inbound."
Action determines whether traffic matching the rule is permitted or blocked. Service tags let you reference groups of IP ranges for Azure services (for example VirtualNetwork, Internet, Storage, AzureLoadBalancer) instead of maintaining explicit IP lists. Azure maintains the underlying IP ranges for service tags so you don’t have to. Now we’ll walk through a portal demo showing NSG creation, NSG associations, creating rules, checking effective rules, and using service tags.

​
Demo setup: three Linux VMs (no NSGs attached)

I have three Linux VMs in a small lab. None of them have NSGs attached initially.
A Microsoft Azure portal screenshot showing the Compute infrastructure > Virtual machines page. Three running Linux VMs (vm-nsg-lab-1, vm-nsg-lab-2, vm-nsg-lab-3) are listed with their resource group, East US location, sizes, and public IP addresses.
Because there are no NSGs attached, there is no NSG-level filtering. Inbound connectivity depends on whether the VM has a public IP and whether the guest OS firewall allows the traffic. If no inbound rule exists (and the OS firewall blocks the port), attempts to connect may time out: 
# Attempt to SSH to the VM's public IP (no inbound NSG rule yet)
ssh kodeloud@172.191.36.135
# (connection attempt times out or hangs)

​
Create an NSG and inspect default rules

Create an NSG (for example nsg-lab-01) in the same region as your VMs and open its Rules page. NSGs include default system rules with high numeric priorities such as 65000, 65001, and 65500.
A screenshot of the Microsoft Azure portal showing a Network Security Group overview (nsg-lab-01) with Essentials info and a table of inbound and outbound security rules. The rule list shows priorities, sources/destinations and actions (e.g., AllowVNetInbound, AllowAzureLoadBalancerInbound, DenyAll) with Allow/Deny icons.
Default inbound rules typically include:
Default inbound rulePurpose
AllowVNetInboundAllows traffic from within the same virtual network
AllowAzureLoadBalancerInboundAllows Azure load balancer probe traffic
DenyAllInboundDenies all other inbound traffic by default
Default outbound rules usually allow VNet and Internet outbound, so new VMs can reach the internet until outbound rules are changed.

​
Associate NSG to a subnet (or NIC)

You can associate NSGs to a subnet (affects all NICs in the subnet) or directly to a NIC (affects a single VM). In this demo we associate the NSG to the subnet containing the VMs.
Screenshot of the Microsoft Azure portal showing the Subnets view for an NSG with one subnet named "subnet-nsg-lab." The subnet is 10.0.1.0/24, tied to virtual network "vnet-az700-nsg," and a toast notification confirms the NSG was successfully saved.
Even with the NSG associated to the subnet, inbound SSH from the internet is blocked until you add an inbound rule to allow it. Add an inbound security rule with these settings:
  • Source: Any (or restrict to My IP)
  • Source port range: *
  • Destination: Any (or specify subnet/NIC)
  • Service: SSH (auto-fills TCP/22)
  • Action: Allow
  • Priority: 100 (lower = higher precedence)
  • Name: AllowAnySSHInbound
The portal will show a caution icon if a rule allows Any source to SSH, since that exposes the VM to the internet — limit it in production.
A screenshot of the Microsoft Azure portal showing inbound security rules for a network security group (nsg-lab-01), listing rules such as AllowAnySSHInbound (TCP port 22 Allow), AllowVnetInBound, AllowAzureLoadBalancerInbound, and a DenyAllInBound rule.
Now you can SSH to any VM in that subnet because the subnet-level rule permits port 22: 
# Connect to a VM in the subnet after adding the allow rule
ssh kodekloud@172.191.36.135
# Accept host key and enter password when prompted
Note that a subnet-level rule affects all VMs in the subnet.

​
Effective security rules and precedence

  • NSGs can be applied to the subnet and/or the NIC.
  • The VM’s effective rules are the combination of the subnet NSG and the NIC NSG.
  • Evaluation happens by priority: lower numeric priorities are evaluated first. If an earlier rule matches and denies traffic, it will block the flow even if another NSG (at the other level) would allow it.
To demonstrate, create a second NSG and attach it to the NIC of vm-nsg-lab-3 while SSH remains allowed at the subnet level. Inspect the VM’s Networking pane and view the effective security rules.
A screenshot of the Microsoft Azure portal showing the Network settings page for a virtual machine named "vm-nsg-lab-3." It displays the VM's network interface, public and private IP addresses, network security group, and related networking options.
If the NIC-level NSG contains a Deny rule for SSH while the subnet NSG allows SSH, the NIC-level deny will block SSH to that particular VM. Use the portal’s Effective Security Rules view to identify which rule (and which NSG) is allowing or blocking traffic.
A screenshot of the Microsoft Azure portal showing the "vm-nsg-lab-3" virtual machine Network settings page with details like the network interface, public and private IP addresses, and security group. The left pane lists virtual machines and navigation items such as Bastion, Networking, and Settings.

​
Service tags: allow Storage while blocking general Internet

Service tags simplify allowing or blocking traffic to Azure services. In this scenario we will restrict outbound Internet access but permit outbound traffic to Azure Storage using the Storage service tag. Open your storage account and confirm it’s accessible via public endpoints.
Screenshot of the Microsoft Azure portal open to the storage account "cskodekloudaz01" Networking page, showing Public network access enabled from all networks. The left pane lists storage account resources like Containers, File shares, Queues, and the Networking menu.
Open a blob container and pick a file to download (example: a small image in the vision container).
A screenshot of the Microsoft Azure portal showing a storage container named "vision" with a list of three blobs (FAQ_DOC.docx, book_reviews.json, note.jpeg) and their last modified times, access tier, blob type, and sizes. The container view includes toolbar options like Add Directory, Upload, Change access level, and filters.
From a VM that currently has outbound Internet access, you can verify the blob is reachable with curl: 
# From a VM with outbound Internet allowed
curl -I https://cskodekloudaz01.blob.core.windows.net/vision/note.jpeg
# or download:
curl -o note.jpeg https://cskodekloudaz01.blob.core.windows.net/vision/note.jpeg
Next, modify the NSG outbound rules for the VM/subnet:
  1. Add a Deny outbound rule with destination service tag = Internet, all ports, and a relatively high precedence (for example priority 200) to block general Internet access.
  2. Remember that default Allow outbound rules may exist at higher numeric priorities (lower precedence). Your Deny at 200 will be evaluated before those defaults.
After adding the Deny Internet outbound rule, general outbound connectivity fails: 
# This should now fail due to the Deny Internet outbound rule
curl https://www.microsoft.com
# No response or connection times out
To allow only Storage while keeping the rest of the Internet blocked, create an Allow outbound rule that targets the Storage service tag and the appropriate ports (usually 443 for HTTPS). Specify needed ports as comma-separated values (for example 443,80) or ranges.
A screenshot of the Microsoft Azure portal showing VM network settings and a Network Security Group "Add outbound security rule" pane. The rule is configured with Destination service tag "Storage" and destination port ranges "443,80".
Add the Allow rule for Storage with a higher precedence (lower numeric priority, for example 100) than the Deny Internet rule. After adding the rule, you should be able to download blobs from your storage account while general Internet access remains blocked: 
# Downloading blob should succeed because Storage outbound is allowed
curl -o note.jpeg https://cskodekloudaz01.blob.core.windows.net/vision/note.jpeg

# General internet remains blocked
curl https://www.microsoft.com
# This will fail or time out
You can also use explicit IP addresses or CIDR ranges as destinations. Azure accepts comma-separated entries like 10.1.1.0/24,10.1.2.0/24 when you need to allow specific internal ranges.
When NSGs are applied at both subnet and NIC levels, evaluation uses the combined set of rules. A Deny at either level can block traffic even if the other level has an Allow. Always verify effective security rules in the portal and design priorities so intended Allows are evaluated before Denys.
Service tags reduce operational overhead by removing the need to maintain large IP lists for Azure services. They are especially useful when you want to allow access to a specific Azure service (for example Storage) while blocking broader Internet access.

​
References and further reading

I hope this lesson clarifies how to create NSG rules, how priority and effective rule evaluation work, and how service tags help simplify NSG management.

Watch Video