7.5 NSGs, ASGs, and Effective Security Rules

NSG rule mechanics

A network security group, or NSG, contains inbound and outbound security rules. Each rule has a priority, direction, access action, protocol, source, source port, destination, destination port, and optional service tag or application security group. Lower priority numbers are evaluated first. When a rule matches, processing stops for that direction.

NSGs can be associated with a subnet, a network interface, or both. When both apply to a VM NIC, the effective result includes both scopes. For inbound traffic, the subnet NSG and NIC NSG must both allow the traffic. For outbound traffic, both scopes can also affect the flow. A deny at either relevant scope can block traffic.

Basic rule example:

Default rules matter

Default NSG rules are exam-relevant. They allow inbound traffic from the virtual network, allow inbound traffic from Azure load balancer probes, and deny other inbound traffic. They allow outbound traffic to the virtual network and internet, then deny other outbound traffic. The practical result is that VMs in the same VNet can often communicate privately unless you add rules to restrict them, while unsolicited inbound internet traffic is denied unless you allow it.

Do not assume that placing VMs in separate subnets automatically blocks them. If the NSGs allow VNet traffic through defaults, private communication may still work. To create tier isolation, add explicit rules with priorities that allow only required flows and deny broad VNet traffic where needed. Be careful not to block required health probes, management flows, or platform dependencies.

Application Security Groups

Application Security Groups, or ASGs, let you group VM NICs by application role. Instead of writing rules for individual IP addresses, you can write rules such as asg-web to asg-app on TCP 8080. This makes scale-out and replacement easier because new NICs can join the ASG without rewriting every NSG rule.

ASGs are especially useful in three-tier designs:

Internet -> Load balancer or App Gateway -> web VMs (asg-web)
web VMs (asg-web) -> app VMs (asg-app) on 8080
app VMs (asg-app) -> db VMs (asg-db) on 1433

ASGs are not a global identity system for every Azure resource. They apply to NIC-based VMs in a virtual network context. If the scenario targets PaaS access such as Storage or SQL private endpoints, NSGs may affect private endpoint NIC traffic depending on configuration, but ASGs themselves are not the same as RBAC, private DNS, or firewall rules on the service.

Effective security rules

Effective security rules are the best way to understand what Azure applies to a NIC. Portal path: Network interface > Effective security rules. This view combines subnet-level NSGs, NIC-level NSGs, default rules, and augmented rules into a readable result. It does not replace guest OS firewall checks, but it answers the Azure NSG question.

Network Watcher IP flow verify is even more direct. You provide a VM, direction, protocol, local IP and port, remote IP and port, and it returns allow or deny plus the rule responsible. This is the tool to use when a question says identify whether traffic is allowed by NSG rules.

CLI examples:

az network nic list-effective-nsg \
  --resource-group rg-network \
  --name nic-web-01 \
  --output table

az network watcher test-ip-flow \
  --resource-group rg-network \
  --vm vm-web-01 \
  --direction Inbound \
  --protocol TCP \
  --local 10.41.1.4 443 \
  --remote 203.0.113.10 50000

Effective-rule troubleshooting workflow

Use this order when connectivity fails:

1. Confirm the destination IP and port are correct.
2. Confirm routing with effective routes or next hop.
3. Check effective security rules on the destination NIC for inbound traffic.
4. Check effective security rules on the source NIC for outbound traffic if outbound rules are customized.
5. Use IP flow verify to identify the exact NSG rule.
6. Check Azure Firewall, load balancer health, application gateway backend health, or NVA policy if the path includes them.
7. Check the VM guest firewall and application listener.

This order prevents a common mistake: editing NSG rules when the packet never reaches the subnet because a UDR points to the wrong next hop. It also prevents blaming Azure when Windows Firewall, Linux firewalld, or the application binding blocks the port.

Rule design patterns

Use service tags for Azure platform ranges and common sources when they match the requirement. For example, Internet, VirtualNetwork, AzureLoadBalancer, and service-specific tags can simplify rules. Use ASGs for your own VM application roles. Use explicit IP prefixes for known external partner networks when the requirement is strict allowlisting.

Avoid overly broad rules such as allowing Any source to Any destination on Any port unless the scenario is a temporary lab and the requirement permits it. For production-like exam scenarios, least privilege is the safer answer. Use lower priority numbers for specific allows, then a deliberate deny for broad lateral movement if required.

Scenario traps

A public IP does not bypass an NSG. A route table does not allow a blocked port. An NSG allow rule does not make an application listen. A subnet boundary alone does not isolate tiers. These are the four most common NSG traps.

Another trap is priority ordering. If priority 100 denies TCP 443 from Internet to a subnet, a later priority 200 allow for TCP 443 will not matter. The deny matched first. To fix the rule set, change priority, scope, source, destination, or remove the conflicting rule.

Finally, remember load balancer health probes. Blocking AzureLoadBalancer probe traffic can make backends appear unhealthy even when the application works locally. If a public load balancer stops sending traffic after NSG hardening, inspect probe ports and the default or explicit rules that allow the probe source.