Evaluate NSG Rule Precedence and Interaction
Network Security Groups (NSGs) filter network traffic using security rules that either allow or deny communication. Each rule has a Priority number ranging from 100 to 4096, where lower numbers indicate higher precedence. When traffic enters or leaves a resource, Azure evaluates rules in order and stops processing as soon as it finds a matching rule. This means a rule with priority 100 always overrides a conflicting rule with priority 200.
The interaction between different NSGs depends on the direction of traffic. For Inbound Traffic, Azure evaluates rules at the subnet level first, then at the Network Interface (NIC) level. For Outbound Traffic, the order reverses: NIC rules are processed before subnet rules. Traffic must be explicitly allowed at both levels to successfully reach its destination or exit the network.
Every NSG includes Default Security Rules that provide basic connectivity, such as allowing internal virtual network traffic and outbound internet access. These default rules have the lowest possible priority to ensure any custom rules you create will take precedence. To simplify management, you can use Augmented Security Rules, which allow grouping multiple IP addresses and ports into a single rule, using Service Tags to represent groups of Azure service IP prefixes, and utilizing Application Security Groups (ASGs) to filter traffic based on application structure rather than IP addresses.
For global governance, Security Admin Rules created in Azure Virtual Network Manager (AVNM) take precedence over standard NSG rules and are evaluated first in the hierarchy. If a security admin rule is set to "Deny" or "Always Allow," Azure terminates further evaluation, meaning local NSG rules will not be checked. This ensures high-level security policies cannot be accidentally bypassed by local administrators.
To understand the cumulative impact of multiple NSGs and admin rules, administrators should examine the Effective Security Rules for a specific NIC, which provides a consolidated list of all rules currently applied to the resource. Additionally, IP Flow Verify within Azure Network Watcher can test if a specific packet is allowed or denied, making it essential for troubleshooting complex reachability issues.
Analyze Inbound and Outbound Security Rules
NSGs manage and secure network traffic by containing security rules that control both inbound and outbound communication to and from Azure resources. Understanding how to configure and evaluate these rules is crucial for ensuring secure access to virtual networks.
Inbound Security Rules
To create an inbound security rule, navigate to your NSG in the Azure portal and select Inbound security rules, then click + Add to enter the details. Key settings include Source (typically set to Any), Source port ranges (typically * for any), Destination (select IP Addresses), Destination IP addresses/CIDR ranges (specify your virtual network subnet range), Service (select Custom), Destination port ranges (enter 22, 3389 for SSH and RDP access), Protocol (select Any), Action (select Allow), Priority (enter 1000 to ensure the rule is processed before Deny rules), and Name (such as AllowRdpSshForLabs).
Associating Subnets with NSGs
After creating the inbound security rule, associate the NSG with the virtual network subnet to apply the traffic rules. This involves selecting Subnets in your NSG, clicking + Associate, choosing your virtual network and subnet, and confirming the association by selecting OK.
Outbound Security Rules
Outbound security rules control traffic leaving your Azure resources and can be configured to allow or deny traffic based on specific criteria. Key settings include Destination (specify target IP addresses or CIDR ranges), Destination port ranges (define ports for outbound traffic), Protocol (choose TCP, UDP, or Any), Action (Allow or Deny), and Priority (set to determine the order of rule processing).
Best Practices and Compliance
When configuring NSGs, regularly review and optimize security rules to ensure they align with organizational security policies. Use web categories to streamline management and evaluate the performance impact of security configurations. By carefully analyzing and configuring inbound and outbound security rules, you can effectively manage network traffic and maintain a secure Azure environment.
Utilize Azure Network Watcher for Security Rule Validation and Troubleshooting
NSG diagnostics within Azure Network Watcher helps administrators understand how traffic moves through a virtual network. A key feature is IP flow verify, which checks if a specific packet is allowed or denied based on security and admin rules. By using a 5-tuple approach—source and destination IP, ports, and protocol—it identifies the exact rule responsible for the traffic decision, making it essential for quickly diagnosing connectivity issues between virtual machines, the internet, or on-premises environments.
To properly evaluate the impact of security configurations, administrators must examine effective security rules, which represent the aggregation of all NSG settings applied at both the subnet and network interface levels. Because rules are processed by priority (lowest number first), understanding this combined list is vital for resolving conflicts. Azure provides a clear view of these rules, allowing you to see which custom or default rules are currently active on a running virtual machine.
NSG flow logs provide visibility by recording all IP traffic flowing through an NSG at Layer 4 of the OSI model. These logs capture the traffic decision (allow or deny) and throughput information when using version 2, with data stored in Azure Storage for auditing, compliance, or security analysis. Common use cases include network monitoring to identify unknown traffic patterns, usage optimization to find "top talkers" for capacity forecasting, and compliance verification to ensure network isolation and enterprise access rules.
When troubleshooting, remember that NSGs act as a stateful firewall, though some non-default inbound TCP rules may behave in a stateless manner. To ensure accurate logging, enable NSG flow logs on all critical subnets and verify that the Microsoft.Insights resource provider is registered to avoid authorization errors. Storage considerations require the storage account to be in the same region as the NSG, use only standard storage accounts for flow logging, and configure retention with automatic deletion up to one year.
For more intuitive understanding of network data, Traffic Analytics visualizes flow logs within a Log Analytics workspace, helping identify security "hot spots" and misconfigurations that might lead to failed connections. However, NSG flow logs are scheduled for retirement in 2027, so Microsoft recommends migrating to virtual network flow logs to overcome current limitations and ensure long-term support for network monitoring.