7.1 Azure Virtual Network Manager, Network Groups & User-Defined Routes

The Problem Virtual Network Manager Solves

Network security groups (NSGs) are owned by whoever owns the subnet or NIC. In a large tenant that means an application team can, deliberately or accidentally, author an NSG rule that opens TCP 3389 to the internet, and the central security team has no way to stop it except by policy audit after the fact. Azure Virtual Network Manager (AVNM) closes that gap with security admin rules — global rules that are evaluated before NSGs and that application teams cannot override.

An AVNM instance is created at a scope (a management group or a subscription). It can only manage virtual networks inside that scope; a virtual network outside the scope simply never receives the rules.

---

Network Groups: Static and Dynamic Membership

A network group is the collection of virtual networks a configuration targets.

Dynamic membership is the security win: a VNet created next month with environment=prod joins the production network group and picks up the deny rules without anyone remembering to add it.

Configurations come in two families:

• Connectivity configurations — build hub-and-spoke or mesh topologies automatically, including direct connectivity between spokes and transitive connections through the hub.
• Security admin configurations — carry the rule collections described below.

A deployment is what pushes a configuration to a region. You can deploy only one security admin configuration per region, though multiple connectivity configurations may coexist in a region. If you need more rules in a region, add more rule collections inside the single security configuration rather than trying to deploy a second configuration.

---

Security Admin Rules vs NSGs

The three actions behave differently:

• Allow — the traffic passes the admin layer and is then still evaluated by NSGs, so a team NSG can still deny it. Use for "permitted, but teams may tighten further".
• Always Allow — evaluation terminates; NSGs cannot deny the traffic. Use for control-plane or monitoring traffic that must never be broken by a team misconfiguration.
• Deny — evaluation terminates and the packet is dropped. Teams cannot re-allow it. This is the control for high-risk ports such as 22, 3389, 445, 111, 135, 161/162, and 2049.

Sources and destinations accept IP/CIDR lists or service tags (with the exception of AzurePlatformDNS, AzurePlatformIMDS, and AzurePlatformLKM). Supported protocols are TCP, UDP, ICMP, ESP, AH, and Any.

Exceptions you must remember

Security admin rules are not applied in two situations:

1. Whole virtual network skipped when it contains Azure SQL Managed Instance or Azure Databricks, because those services enforce their own network intent policy. You can set the configuration to AllowRulesOnly so at least the Allow rules apply, or request an exemption from Microsoft.
2. Individual subnets skipped when they host Azure Application Gateway, Azure Bastion, Azure Firewall, Azure Route Server, VPN Gateway, ExpressRoute Gateway, or Virtual WAN. Other subnets in the same VNet are still governed.

Deployment uses an eventual consistency model: rules land on existing and newly created resources after a short delay, not instantly. Private endpoints inside a managed virtual network are also currently outside the scope of security admin rules.

---

User-Defined Routes and Forced Tunnelling

Azure creates system routes automatically: intra-VNet traffic, peering, gateway-learned routes, and a default 0.0.0.0/0 route to the internet. A user-defined route (UDR) in a route table associated with a subnet replaces that default behaviour.

Next hop types:

Route selection follows a strict order:

1. Longest prefix match wins. A /32 route beats a /24 route beats 0.0.0.0/0, regardless of route source.
2. On an equal prefix, a UDR beats a BGP-learned route, which beats a system route.

Forced tunnelling is a 0.0.0.0/0 UDR whose next hop is the firewall or the gateway, applied to the workload subnet. Three traps appear regularly:

• Applying the 0.0.0.0/0 route to the AzureFirewallSubnet with the firewall as next hop creates a routing loop; the firewall subnet should keep its internet route.
• A /32 route for a monitoring endpoint silently bypasses your firewall, because longest prefix match outranks your default route.
• Service Endpoints override routing entirely for the enabled service, so a UDR alone will not force storage traffic through an appliance if a service endpoint is enabled on the subnet.

AVNM can also centralize route tables through routing configurations, which is the same governance idea applied to UDRs rather than to filtering rules.