Subnets: Dividing the VNet
A subnet is a range of IP addresses carved out of a VNet's larger address space, and it is the boundary at which most Azure networking policy actually gets applied: Network Security Groups, route tables, service endpoints, and delegation to services like Azure App Service or Azure Container Instances are all attached at the subnet level, not the VNet level. Splitting a VNet like 10.0.0.0/16 into subnets such as 10.0.1.0/24 for web tier VMs, 10.0.2.0/24 for a database tier, and 10.0.3.0/26 for an Azure Bastion host lets you apply different security postures and routing behavior to each tier, mirroring the classic three-tier application architecture but implemented as network-level isolation rather than just application-level separation.
Cricket analogy: It's like dividing a full stadium into distinct seating blocks -- the members' pavilion, the general stand, and the media box -- where each block has its own access rules and ticket checks, even though they're all part of the same ground.
Network Security Groups (NSGs)
A Network Security Group is a stateful packet filter made up of ordered security rules that allow or deny inbound and outbound traffic based on source/destination IP or service tag, port, and protocol; each rule has a priority number from 100 to 4096, and Azure evaluates rules in ascending priority order, stopping at the first match. An NSG can be attached to a subnet (applying to every NIC within it), to an individual network interface, or both, and when both apply, a packet must be allowed by both the subnet-level NSG and the NIC-level NSG to get through -- a deny at either layer blocks the traffic. Azure also ships default rules you cannot delete (only override with higher-priority custom rules), including AllowVnetInBound, AllowAzureLoadBalancerInBound, and DenyAllInBound, which is why a brand new subnet with no custom rules already blocks unsolicited inbound internet traffic by default.
Cricket analogy: It's like the DRS (Decision Review System) evaluating an appeal through a strict, ordered checklist -- ball-tracking, edge detection, pitching -- and stopping the moment a decisive factor is found, exactly as NSG rules are evaluated in priority order until the first match.
Layering NSGs Across Subnets and NICs
A common production pattern is to apply a broad, org-wide NSG at the subnet level (e.g., deny all inbound from the internet except a specific admin jump-box range) and a narrower, workload-specific NSG at the individual NIC level (e.g., allow inbound 443 only from the load balancer's subnet). Because traffic must pass both layers, this gives you defense in depth: even if someone mistakenly opens a permissive rule on one NIC, the subnet-level NSG still constrains what can actually reach it. Azure also provides Application Security Groups (ASGs), which let you group VM NICs logically (like 'WebTier' or 'DbTier') and reference that group name directly in NSG rules instead of hardcoded IP ranges, so the rule automatically adapts as VMs are added or removed from the group.
Cricket analogy: It's like a fielding captain setting a general field placement for the bowling side (subnet-level NSG) and then a bowler making a specific tweak for one particular batsman on strike (NIC-level NSG) -- the ball still has to get past both the general field and the specific adjustment.
# Create an NSG, add a rule, and associate it with a subnet using Azure CLI
az network nsg create \
--resource-group rg-network-demo \
--name nsg-web-tier
az network nsg rule create \
--resource-group rg-network-demo \
--nsg-name nsg-web-tier \
--name Allow-HTTPS-From-LB \
--priority 100 \
--direction Inbound \
--access Allow \
--protocol Tcp \
--source-address-prefixes AzureLoadBalancer \
--destination-port-ranges 443
az network vnet subnet update \
--resource-group rg-network-demo \
--vnet-name vnet-hub \
--name snet-workload \
--network-security-group nsg-web-tierA newly created subnet with no NSG attached still allows unrestricted traffic within the VNet by default, but once you attach an NSG, remember that the built-in DenyAllInBound rule (priority 65500) blocks all internet-sourced inbound traffic unless you add a higher-priority Allow rule. Forgetting this is a common cause of 'my VM is unreachable' tickets right after NSG rollout.
Application Security Groups (ASGs) let you write NSG rules referencing logical groups like 'WebTier' instead of hardcoded IP addresses. As VMs scale in or out of the group, existing NSG rules automatically apply to the new NICs -- no rule editing required.
- Subnets divide a VNet's address space and are the level at which NSGs, route tables, and service delegation are actually applied.
- NSGs are stateful, priority-ordered rule sets (100-4096) evaluated top-down, stopping at the first matching rule.
- Default un-deletable NSG rules include AllowVnetInBound, AllowAzureLoadBalancerInBound, and DenyAllInBound at the lowest priority.
- NSGs can attach to a subnet, a NIC, or both -- traffic must pass both layers when both are present, enabling defense in depth.
- Application Security Groups let NSG rules reference logical VM groupings instead of hardcoded IPs, adapting automatically as membership changes.
- A common pattern is a broad subnet-level NSG plus a narrower NIC-level NSG per workload for layered security.
Practice what you learned
1. In what order does Azure evaluate NSG rules?
2. If an NSG is attached to both a subnet and a NIC within it, what determines whether traffic passes?
3. What does the built-in DenyAllInBound default rule accomplish?
4. What is the main benefit of an Application Security Group (ASG)?
5. At what level are Azure NSGs primarily applied to enforce network security policy?
Was this page helpful?
You May Also Like
Azure Virtual Networks
Learn how Azure Virtual Networks (VNets) provide isolated, private IP address spaces for your cloud resources, and how peering and hybrid connectivity link them together.
Azure Load Balancer Basics
Learn how Azure Load Balancer distributes Layer 4 traffic across backend pools using health probes, load balancing rules, and the Standard SKU's secure-by-default model.
Azure DNS Basics
Learn how Azure DNS hosts and resolves domain records, the standard record types, and how Alias records solve Azure-specific limitations like apex domain routing.