Skip to main content
Deploy and configure Network Security Groups (NSGs) in Azure. In this lesson we’ll deep-dive into Network Security Groups (NSGs) — a core security control in Azure networking. Think of NSGs as traffic controllers for your virtual network: they allow or deny traffic to and from resources based on a set of rules. NSGs are essential for micro-segmentation, restricting lateral movement, and protecting workloads at both the subnet and network interface (NIC) levels. This module will cover:
  • What NSGs are and why they are essential for controlling network access in Azure.
  • The default inbound and outbound rules that ship with every NSG, and the rationale behind them.
  • How Azure determines the final effective set of rules when NSGs are applied at both the subnet and network interface (NIC) levels.
  • How to create custom security rules within NSGs.
  • Service tags and how they simplify rule management.
  • Application Security Groups (ASGs) and how they help group VMs for simplified rule definitions.
A slide titled "Learning Objectives" listing three points about NSGs: their role in controlling network access, default inbound/outbound rules, and how effective rules are calculated at subnet and NIC levels. The slide has a blue gradient sidebar and a © KodeKloud credit at the bottom.
We will also practice creating custom security rules and explore service tags and application security groups. By the end of this lesson, you will both understand NSGs conceptually and be confident deploying them in Azure.
Note: NSGs are stateful — when an inbound packet is allowed, the return traffic is automatically allowed regardless of explicit outbound rules, and vice versa.

​
What is an NSG?

An Azure Network Security Group (NSG) is a collection of security rules that permit or deny inbound and outbound network traffic based on factors such as source/destination IP address, port, and protocol. NSGs can be associated with:
  • Subnets — applies to all resources in the subnet.
  • Network Interfaces (NICs) — applies to a specific VM’s NIC.
Applying NSGs at both levels enables more granular control, but it also changes how Azure evaluates the final, effective ruleset (see “Effective rules” below).

​
Default NSG Rules

Every new NSG contains default rules that ensure basic connectivity and platform functionality. You can create custom rules with higher precedence (lower numeric priority) but you cannot remove the default rules — you can only override them by using lower priority numbers.
DirectionRule namePriorityAccessPurpose
InboundAllowVNetInBound65000AllowAllow all VNet traffic (intra-VNet)
InboundAllowAzureLoadBalancerInBound65001AllowAllow Azure load balancer health probes
InboundDenyAllInBound65500DenyDeny any other inbound traffic
OutboundAllowVNetOutBound65000AllowAllow all VNet traffic (intra-VNet)
OutboundAllowInternetOutBound65001AllowAllow outbound traffic to the Internet
OutboundDenyAllOutBound65500DenyDeny any other outbound traffic
Use these defaults to reason about where to place your custom rules. Custom rules with a lower numeric priority take precedence over higher-priority default rules.

​
How Azure Evaluates Effective Rules (subnet + NIC)

When an NSG is associated with both a subnet and a NIC, Azure merges the rules from both NSGs into a single effective ruleset and evaluates them by ascending priority number (lower numbers evaluated first). The first matching rule determines whether traffic is allowed or denied. Important points:
  • Rule evaluation is priority-based, not location-based. A NIC rule does not inherently override a subnet rule — the rule with the lower numeric priority wins.
  • If any rule matches with Deny, the traffic is denied (first-match-wins).
  • Stateful behavior allows return traffic for permitted flows without requiring explicit return rules.
Example scenario:
  • Subnet NSG has Deny TCP 22 from Internet at priority 100.
  • NIC NSG has Allow TCP 22 from 203.0.113.0/24 at priority 200.
  • Result: The subnet deny (priority 100) is evaluated first and blocks the traffic despite the NIC allow; the lower-numbered rule wins.

​
Custom Security Rules

Create granular security rules to allow or deny traffic between specific sources and destinations, ports, and protocols. Custom rules should be assigned priorities that reflect their intended precedence. Azure CLI examples: Create an NSG: 
az network nsg create \
  --resource-group myResourceGroup \
  --name myNSG
Add a rule to allow SSH from a specific IP range: 
az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name AllowSSHFromOffice \
  --priority 100 \
  --source-address-prefixes 203.0.113.0/24 \
  --destination-port-ranges 22 \
  --access Allow \
  --direction Inbound \
  --protocol Tcp
Associate NSG to a subnet: 
az network vnet subnet update \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --name mySubnet \
  --network-security-group myNSG
Associate NSG to a NIC: 
az network nic update \
  --resource-group myResourceGroup \
  --name myNic \
  --network-security-group myNSG

​
Service Tags and Application Security Groups (ASGs)

  • Service tags: Predefined identifiers representing ranges of IP addresses for Azure services (for example, Internet, VirtualNetwork, AzureLoadBalancer, Storage). Use service tags instead of hard-coding changing IP ranges.
  • Application Security Groups (ASGs): Logical grouping of VMs that enable you to define NSG rules by application role instead of IP address. This simplifies scaling and management — if you add a VM to an ASG, it automatically inherits rules referencing that ASG.

​
Best Practices

  • Follow the principle of least privilege: only allow required traffic and ports.
  • Use service tags and ASGs to reduce rule churn and complexity.
  • Use descriptive rule names and consistent priority ranges (for example, 100–199 for management, 200–299 for app traffic).
  • Test rules in a safe environment before applying them in production.

​
References

Watch Video