How does Azure NSG rule priority evaluation work?

Azure evaluates NSG rules in ascending priority order (100 is evaluated before 200). The first matching rule determines whether traffic is allowed or denied — subsequent rules are not evaluated. Azure reserves priorities 65000-65500 for default rules (AllowVnetInbound, AllowAzureLoadBalancerInbound, DenyAllInbound). User-defined rules must use priorities between 100 and 4096. This priority-based evaluation means rule ordering matters significantly for security.

What is the difference between Azure NSGs and AWS Security Groups?

Azure NSGs support both allow and deny rules with explicit priority ordering, while AWS Security Groups only support allow rules with implicit deny. NSGs can be applied to both subnets and individual NICs (with cumulative evaluation), while AWS Security Groups attach only to instances. NSGs are stateful like Security Groups, but Azure also has stateless options through Azure Firewall or UDR-based appliances.

Can NSGs reference Azure service tags in rules?

Yes. Service tags like Internet, VirtualNetwork, AzureLoadBalancer, and service-specific tags like Storage, Sql, and AzureActiveDirectory represent groups of IP address prefixes managed by Microsoft. Using service tags instead of hard-coded IP ranges ensures your rules automatically stay current as Azure updates its IP ranges. The linter checks whether your rules use service tags appropriately.

Azure NSG Rule Linter

IAM & SecurityAzure

Analyze Azure Network Security Group rules for security issues and best practices.

Last verified: April 2026

Azure NSG Rules (JSON)

Raw Output

Output will appear here...

About This Tool

Azure Network Security Groups (NSGs) filter traffic to and from Azure resources within a virtual network using priority-based rules that are evaluated in order from lowest to highest number. Unlike AWS security groups, NSGs support both allow and deny rules, and rule priority conflicts can produce unexpected behavior where a lower-priority allow is overridden by a higher-priority deny or vice versa. This linter analyzes your NSG rules for common security issues including unrestricted inbound access from the Internet service tag, overly broad port ranges, conflicting rules at different priorities, and missing deny-all rules at the end of your rule set.

Real-World Scenario

After a security assessment flags your Azure environment, you need to audit 34 NSGs across 3 subscriptions. Running them through the linter reveals 7 rules allowing RDP from the Internet service tag — leftover from when the team was troubleshooting a connectivity issue three months ago. It also catches a priority conflict where rule 200 (Allow SSH from VNet) is overridden by rule 150 (Deny all inbound from VNet) that someone added without realizing the priority implications.

When to Use This Tool

•Auditing NSG configurations against Azure CIS Benchmark requirements before compliance assessments
•Detecting rules that allow inbound SSH (22) or RDP (3389) from the Internet service tag, which violates most security baselines
•Identifying priority conflicts where a permissive low-priority rule is unintentionally overridden by a restrictive high-priority rule
•Validating that NSG rule sets include explicit deny-all rules at the highest priority numbers to establish a default-deny posture

Pro Tips

TIP

NSG rules applied at the subnet level and NIC level are evaluated cumulatively — both must allow the traffic. A common gotcha is adding a permissive subnet NSG but forgetting that the NIC-level NSG still blocks the traffic. Always check both levels when troubleshooting connectivity issues.

TIP

Unlike AWS Security Groups, Azure NSG priority numbers determine which rule wins. Leave gaps between priorities (use 100, 200, 300 instead of 100, 101, 102) so you can insert exception rules later without renumbering. Teams that use sequential priorities inevitably need a painful reordering when a new rule needs to go between two existing ones.

TIP

Application Security Groups (ASGs) are Azure's answer to managing NSG rules at scale. Instead of maintaining IP-based rules that break when VMs scale or get new IPs, assign VMs to ASGs and reference those groups in NSG rules. The linter flags IP-based rules that could be simplified with ASGs.

How It Works Under the Hood

The linter parses each NSG rule and evaluates it against a severity-weighted rule set. It checks source and destination addresses against risky patterns (Internet service tag, 0.0.0.0/0, *), validates port ranges for sensitive services (SSH/22, RDP/3389, database ports), detects priority conflicts where a higher-priority deny overrides a lower-priority allow (or vice versa), and verifies that a deny-all rule exists at the end of the rule chain. Each finding includes the rule priority, direction, and a specific remediation recommendation.

Frequently Asked Questions

How does Azure NSG rule priority evaluation work?: Azure evaluates NSG rules in ascending priority order (100 is evaluated before 200). The first matching rule determines whether traffic is allowed or denied — subsequent rules are not evaluated. Azure reserves priorities 65000-65500 for default rules (AllowVnetInbound, AllowAzureLoadBalancerInbound, DenyAllInbound). User-defined rules must use priorities between 100 and 4096. This priority-based evaluation means rule ordering matters significantly for security.
What is the difference between Azure NSGs and AWS Security Groups?: Azure NSGs support both allow and deny rules with explicit priority ordering, while AWS Security Groups only support allow rules with implicit deny. NSGs can be applied to both subnets and individual NICs (with cumulative evaluation), while AWS Security Groups attach only to instances. NSGs are stateful like Security Groups, but Azure also has stateless options through Azure Firewall or UDR-based appliances.
Can NSGs reference Azure service tags in rules?: Yes. Service tags like Internet, VirtualNetwork, AzureLoadBalancer, and service-specific tags like Storage, Sql, and AzureActiveDirectory represent groups of IP address prefixes managed by Microsoft. Using service tags instead of hard-coded IP ranges ensures your rules automatically stay current as Azure updates its IP ranges. The linter checks whether your rules use service tags appropriately.

Featured In

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.