L8. Network Segmentation: NSGs, ASGs & Azure Virtual Network Manager
Video generating
Check back soon for the video lesson on Network Segmentation: NSGs, ASGs & Azure Virtual Network Manager
Course outlineLesson 8 of 18
A network security group is a stateful five-tuple filter that only knows IP addresses, an application security group lets it reason about workload roles instead, and Virtual Network Manager is what enforces both consistently across every VNet in the tenant at once.
Network Security Groups
A Network Security Group (NSG) filters traffic to and from Azure resources using stateful rules evaluated by priority (lower number = higher priority, evaluated first). Each rule is a five-tuple: source, source port, destination, destination port, and protocol, with an allow or deny action.
NSGs can associate with a subnet (applies to everything in it) or a network interface (NIC) (applies to a single VM), and both can be combined, with the more restrictive combined result winning. Every NSG ships with default rules you cannot delete (only override with a higher-priority custom rule): allow VNet-to-VNet traffic, allow Azure Load Balancer health probes, and deny all other inbound traffic by default.
Application Security Groups
An Application Security Group (ASG) lets you group VMs by application role (e.g., "WebTier," "AppTier," "DbTier") and reference that group directly as the source or destination in an NSG rule, instead of hardcoding IP addresses or subnet ranges. As VMs are added to or removed from the ASG, every NSG rule referencing it updates automatically, which is what makes NSG rule sets maintainable at scale: "allow AppTier to reach DbTier on 1433" stays correct as the environment grows, without ever touching the rule itself.
Azure Virtual Network Manager
Azure Virtual Network Manager (AVNM) centralizes network configuration across many VNets, even across subscriptions and management groups, through:- Network groups: a static or dynamically-membership-based (via Azure Policy conditions) collection of VNets to manage together
- Connectivity configurations: define topology across the network group, either mesh (every VNet can reach every other VNet) or hub-and-spoke (all spokes route through a central hub), applied without manually creating individual peerings
- Security admin rules: the standout security feature. These are evaluated *before* any NSG rule on the target resources and can enforce Allow, Deny, or AlwaysAllow (a rule an NSG cannot override even with a conflicting allow), giving central security teams a way to guarantee a baseline (e.g., "never allow RDP from the internet") that individual application teams cannot accidentally override with their own NSG
Security admin rules are assigned across a deployment scope, letting a central platform team enforce tenant-wide segmentation guardrails while still leaving day-to-day NSG management to individual application teams within those guardrails. Exam tip: The exam differentiates "an application team's NSG rule is being overridden by a central policy that they cannot change" (security admin rules with AlwaysAllow/Deny, evaluated before NSGs) from "a rule needs to stay correct automatically as VMs are added to a tier" (Application Security Groups).
- ✓NSG rules are stateful five-tuple filters evaluated by priority, with unremovable default rules that deny all other inbound traffic by default
- ✓Application Security Groups let NSG rules reference workload roles instead of hardcoded IPs, automatically staying correct as VMs join or leave the group
- ✓Azure Virtual Network Manager network groups can span subscriptions and management groups, with membership either static or dynamic via Azure Policy conditions
- ✓Connectivity configurations in AVNM apply mesh or hub-and-spoke topology across a network group without manual VNet peering
- ✓Security admin rules evaluate before NSG rules and support AlwaysAllow/Deny to enforce a central baseline that individual teams' NSGs cannot override
1. A rule allowing the web tier to reach the database tier on port 1433 needs to remain correct automatically as VMs are added to or removed from each tier, without editing the NSG rule itself. What should be used as the rule's source and destination?
2. A central security team needs to guarantee that RDP from the internet is never allowed across any VNet in the tenant, even if an individual application team's own NSG tries to allow it. Which Azure Virtual Network Manager feature enforces this?
3. What happens if traffic matches both a subnet-associated NSG and a NIC-associated NSG with conflicting allow/deny results?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured Cloud and AI Security Engineer learning paths, hands-on Azure and Defender for Cloud labs, and timed practice exams to make it stick before exam day.