Network Security Group Association Overview
Network Security Groups (NSGs) are a fundamental component of network security in Azure. They enable you to filter network traffic to and from Azure resources in an Azure virtual network, a subnets, and individual network interfaces. This document provides a comprehensive overview of how NSGs are associated with various Azure resources and the implications of these associations.
On this page:
What are Network Security Groups?
An NSG is a collection of security rules that allow or deny network traffic. NSGs can contain security rules that allow or deny inbound network traffic to, or outbound network traffic from, various Azure resources. When you create an NSG, you can define custom rules, or use the default rules that are automatically created.
Each NSG contains:
- Inbound security rules: Define how traffic is allowed or denied to resources within the NSG.
- Outbound security rules: Define how traffic is allowed or denied from resources in the NSG to other resources.
- Association: The target resource to which the NSG is applied.
Types of NSG Association
NSGs can be associated with Azure resources at two primary levels:
Subnet Association
When an NSG is associated with a subnet, its security rules are applied to all network interfaces (NICs) within that subnet. This is a powerful way to enforce consistent security policies across multiple resources that share the same network segment.
Key characteristics:
- Applies to all NICs in the subnet.
- Rules are evaluated for both inbound and outbound traffic flowing to or from the subnet.
- A subnet can only be associated with one NSG at a time.

Diagram illustrating NSG association with a subnet.
Network Interface (NIC) Association
An NSG can also be directly associated with a Network Interface (NIC) of a virtual machine or other Azure resource. This allows for more granular control, enabling you to apply specific security rules to an individual resource.
Key characteristics:
- Applies only to the specific NIC it is associated with.
- Rules are evaluated for traffic entering and leaving the NIC.
- A NIC can only be associated with one NSG at a time.

Diagram illustrating NSG association with a Network Interface.
Precedence and Evaluation
When traffic flows through a subnet or to/from a NIC that has an NSG associated, Azure evaluates the security rules within the NSG. The order of evaluation is critical:
- Association Level: Rules applied directly to a NIC are evaluated before rules applied to the subnet.
- Direction: Rules are evaluated based on traffic direction (inbound or outbound).
- Priority: Rules within each direction are processed in order of their priority number, starting with the lowest number (highest priority).
- Allow or Deny: The first rule that matches the traffic characteristics determines whether the traffic is allowed or denied.
- Default Rules: If no custom rule matches, the implicit default rules are applied.
For example, if an NSG is associated with both a NIC and its subnet, and a rule on the NIC's NSG allows inbound SSH traffic (TCP port 22) but a rule on the subnet's NSG denies it, the traffic will be denied because the NIC association is evaluated first and its deny rule takes precedence for that specific NIC.
Best Practices
- Leverage Subnet Associations: For consistent security, associate NSGs with subnets whenever possible. This simplifies management and ensures uniform policies.
- Use NIC Associations Sparingly: Reserve NIC-level associations for specific exceptions or requirements for individual virtual machines.
- Organize Rules by Priority: Group similar rules together and use priority numbers logically. Start with broad rules and then refine with more specific ones.
- Deny Explicitly: While there are default deny rules, explicitly define deny rules for traffic you want to block, making your security posture clearer.
- Use Service Tags: Utilize Azure-defined service tags (e.g., `Internet`, `AzureLoadBalancer`, `VirtualNetwork`) to simplify rule management and ensure broad coverage.
- Regular Audits: Periodically review your NSG rules to ensure they align with your current security requirements and remove any unused or redundant rules.
Examples
Example 1: Associating NSG with a Subnet
Apply an NSG named WebSubnetNSG
to the subnet containing your web servers to allow inbound HTTP (port 80) and HTTPS (port 443) traffic from the internet, and deny all other inbound traffic.
Example 2: Associating NSG with a NIC
Apply a more restrictive NSG named VMNSG
directly to a specific VM's NIC, allowing only RDP (port 3389) from a specific management IP address.