An Azure Network Security Group (NSG) filters inbound and outbound traffic for resources in an Azure virtual network. It contains rules that allow or deny traffic based on the source, destination, protocol, port, direction, and priority.
Understand how NSG rules are evaluated
Azure processes rules by priority. Lower numbers have higher priority, and processing stops when traffic matches a rule. Custom rules with higher priority are evaluated before Azure’s default rules. [1]
NSGs are stateful. If an outbound connection is allowed, the response traffic does not normally need a separate inbound allow rule. Rules affect new connections; existing connections can continue after a rule is removed until a new connection is attempted. [1]
1. Create the NSG
- In the Azure portal, search for Network security groups.
- Select + Create.
- Choose the subscription and resource group.
- Enter a unique NSG name.
- Choose the region.
- Select Review + create.
- After validation passes, select Create.
You need a role with permission to create and manage the NSG, such as Network Contributor or an appropriate custom role. [2]
2. Add an inbound or outbound rule
- Open the new NSG.
- Select Inbound security rules or Outbound security rules.
- Select + Add.
- Choose the source, destination, protocol, and port range.
- Choose Allow or Deny.
- Set a unique priority.
- Enter a descriptive name.
- Select Add.
Use the narrowest source and destination that meets the requirement. Service tags and application security groups can reduce the need to maintain large lists of IP addresses. [1]
3. Set priorities deliberately
Reserve lower priority numbers for the most important explicit rules and use a consistent numbering scheme. For example, leave room between rules so that future exceptions can be inserted without renumbering the entire policy. Never create two rules with the same priority and direction.
4. Associate the NSG with a subnet
- Open the NSG and select Subnets.
- Select + Associate.
- Choose the virtual network.
- Choose the subnet.
- Select OK.
Associating the NSG with a subnet applies the policy to resources in that subnet. You can also associate an NSG with an individual network interface when the rule needs to apply to a narrower set of resources. [2]
5. Review default rules
Azure creates default inbound and outbound rules in each NSG. You cannot delete these defaults, but you can override them with a custom rule that has a higher priority. Review the defaults before adding exceptions so you understand which traffic is already allowed or denied. [1]
6. Check effective security rules
Open the NSG and review its effective security rules or diagnostic settings. If traffic does not behave as expected, inspect the NSG associated with the subnet and the NSG associated with the network interface. A rule at either level can affect the final result.
7. Test with a narrow change
Test from the actual source and destination. Confirm the protocol and port, then check whether the connection is new. A rule change may not interrupt an existing flow, so start a new connection after making a test change. Remove temporary test rules when the validation is complete.
Common mistakes
- Allowing Any source when a service tag, subnet, or application security group would work.
- Using a lower-priority number than intended and overriding another rule.
- Associating the NSG with the wrong subnet or network interface.
- Assuming removing a rule immediately terminates existing connections.
- Exposing management ports broadly instead of limiting source addresses or using a secure access path.


