Azure Network Security Groups (NSGs) are stateful firewalls that filter network traffic to and from Azure resources in an Azure virtual network (VNet).
Let’s see them in action. Imagine you have a web application running on a virtual machine (VM) in Azure. You want to ensure that only HTTP (port 80) and HTTPS (port 443) traffic can reach your web server, and all other inbound traffic is blocked.
First, you’d create an NSG.
az network nsg create --resource-group MyResourceGroup --name MyWebAppNSG
Next, you’d associate this NSG with a subnet or a specific VM’s network interface. Let’s associate it with a subnet.
az network vnet subnet update --resource-group MyResourceGroup --vnet-name MyVNet --name MyWebAppSubnet --network-security-group MyWebAppNSG
Now, let’s define the rules. By default, NSGs have some essential rules. A crucial one is the DenyAllInbound rule with priority 65500, which blocks all inbound traffic not explicitly allowed by a higher-priority rule.
We want to allow inbound HTTP and HTTPS.
# Allow inbound HTTP traffic
az network nsg rule create --resource-group MyResourceGroup --nsg-name MyWebAppNSG --name AllowHTTPInbound --protocol Tcp --priority 100 --destination-port-range 80 --access Allow --direction Inbound
# Allow inbound HTTPS traffic
az network nsg rule create --resource-group MyResourceGroup --nsg-name MyWebAppNSG --name AllowHTTPSInbound --protocol Tcp --priority 110 --destination-port-range 443 --access Allow --direction Inbound
With these rules, any traffic arriving at a VM within MyWebAppSubnet on port 80 or 443 will be allowed. Any other inbound traffic will be dropped by the DenyAllInbound rule.
The problem NSGs solve is granular control over network traffic at the IP and port level for your Azure resources. This is fundamental for securing your applications by enforcing the principle of least privilege, ensuring that only necessary communication pathways are open. They operate at the subnet or network interface level, providing flexibility in how you segment your network traffic.
Internally, NSGs maintain a state table. When a packet arrives, the NSG checks its rules. If a packet matches an Allow rule, it’s permitted. If it matches a Deny rule, it’s dropped. For established connections, the stateful nature means that return traffic for already allowed outbound connections is automatically permitted without needing a specific inbound rule for it.
The exact levers you control are:
- Priority: Lower numbers have higher precedence. Rules are evaluated in priority order.
- Protocol: TCP, UDP, ICMP, or Any.
- Source/Destination Port Ranges: You can specify single ports (e.g., 80), ranges (e.g., 1000-2000), or
*for all. - Source/Destination IP Addresses/CIDR Blocks: You can specify individual IPs, ranges, or entire subnets. You can also use predefined tags like
VirtualNetwork,AzureLoadBalancer,Internet, orAny. - Access: Allow or Deny.
- Direction: Inbound or Outbound.
The most surprising true thing about NSGs is that you can block traffic from your own virtual network to the internet using outbound rules. For example, if you want to restrict your web servers from initiating outbound connections to anywhere except specific allowed destinations, you can create an outbound NSG rule.
# Example: Deny all outbound traffic by default
az network nsg rule create --resource-group MyResourceGroup --nsg-name MyWebAppNSG --name DenyAllOutbound --protocol Any --priority 65500 --destination-port-range '*' --destination-address-prefixes '*' --access Deny --direction Outbound
# Then, allow specific outbound traffic, e.g., to a database subnet
az network nsg rule create --resource-group MyResourceGroup --nsg-name MyWebAppNSG --name AllowOutboundToDB --protocol Tcp --priority 100 --destination-port-range 1433 --destination-address-prefixes 10.0.2.0/24 --access Allow --direction Outbound
This is often overlooked when people think about NSGs primarily as inbound security.
The next concept you’ll run into is how NSGs interact with Azure Firewall or User Defined Routes (UDRs), especially when you need more advanced traffic inspection or routing beyond simple port and IP filtering.