Azure Virtual Network Manager

About Azure Virtual Network Manager

Azure Virtual Network Manager is Microsoft's centralized service for managing Azure virtual networks at scale. It is designed for organizations that have moved beyond a handful of manually managed virtual networks and need consistent connectivity, security, routing, IP address management, and network troubleshooting across subscriptions, management groups, regions, and supported tenant scopes. Instead of configuring every virtual network separately, platform teams can place networks into logical groups and deploy approved network configurations across those groups from one management plane.

What does Azure Virtual Network Manager manage?

Azure Virtual Network Manager manages groups of Azure virtual networks rather than replacing the virtual networks themselves. A network manager has a defined management scope, such as selected subscriptions or management groups. Within that scope, administrators create network groups and add virtual networks manually or through Azure Policy conditions.

Microsoft currently supports connectivity, security admin, and routing configurations. Connectivity configurations can create mesh or hub-and-spoke topologies. Security admin configurations apply centrally governed network security rules across selected groups. Routing configurations let platform teams define and deploy user-defined routes at scale. The service also includes centralized IP address management and reachability verification capabilities.

How do network groups and connectivity configurations work?

Network groups are the organizational layer used to target configurations. Teams can add specific virtual networks manually or use Azure Policy to make membership dynamic based on conditions such as tags, subscriptions, or resource groups. This is useful when new application networks are created frequently and should inherit the right connectivity automatically.

Connectivity configurations support mesh and hub-and-spoke designs. Microsoft documents regional mesh connectivity and an optional global mesh mode for cross-region communication. Hub-and-spoke configurations can establish spoke-to-hub connectivity and can optionally enable direct connectivity between spokes in the same network group. This reduces the need to create and maintain large numbers of individual peering relationships by hand.

How do security admin rules differ from network security groups?

Security admin rules provide an organization-level control layer that is evaluated before network security group rules. This allows a central networking or security team to establish rules that local workload teams cannot bypass with their own NSG configuration. A deny security admin rule can block traffic before NSG evaluation.

This is useful for organization-wide requirements such as blocking risky ports, enforcing known traffic restrictions, or applying common baselines across many subscriptions. It does not remove the need for network security groups. NSGs still provide workload-level filtering, while security admin rules are better suited to centrally enforced guardrails.

What are the current scale limits?

Microsoft currently documents several important scale limits. A connected group can include up to 250 virtual networks by default and can be expanded to 1,000 through a request process. A hub-and-spoke configuration can include up to 1,000 virtual networks peered to the hub. A connected group can include up to 2,000 private endpoints.

For security admin rules, Microsoft currently documents up to 20,000 IP prefixes combined per Azure Virtual Network Manager resource and up to 100 admin rules. User-defined routing configurations support up to 1,000 user-defined routes per route table. Policy application also has a documented scope constraint below 15,000 subscriptions. Buyers operating at large enterprise scale should compare their intended topology with the current limits before standardizing on one design.

How does Azure Virtual Network Manager pricing work?

Pricing was checked on August 28, 2026. New Azure Virtual Network Manager instances use Microsoft's virtual-network-based pricing model. Older instances can still be on the previous subscription-based model, but Microsoft says that model is scheduled to retire on February 6, 2028, after which remaining instances move to virtual-network-based pricing.

The exact charge depends on the features and virtual networks being managed, and Microsoft directs customers to the Azure pricing calculator for their billing context. Connectivity created through Virtual Network Manager can also generate normal virtual network peering data-transfer charges. Because rates vary by agreement, region, currency, and configuration, a single universal monthly price would be misleading.

How does Azure Virtual Network Manager compare with Virtual WAN and Route Server?

Azure Virtual Network Manager is primarily a centralized management and policy layer for Azure virtual networks. Azure Virtual WAN is a broader managed transit platform for branch, VPN, ExpressRoute, and multi-region hub connectivity. Azure Route Server focuses on BGP route exchange between Azure networks and network virtual appliances.

A large environment can use more than one of these services. Virtual Network Manager may govern network groups, security rules, routing configurations, and IP address space while other networking services handle specific connectivity or routing functions. Buyers should select based on the operational problem rather than treating all Azure networking services as substitutes.

What deployment and migration issues should buyers plan for?

Configurations do not take effect merely because they are created. Microsoft requires them to be deployed to the target regions that contain the intended network resources. Teams should therefore treat configuration deployment as a controlled change process, especially for security and routing rules that can affect many networks at once.

Cross-tenant support has limitations. Microsoft currently documents cross-tenant support only with static membership network groups. Organizations migrating from manually managed peerings should also test coexistence carefully. Existing manual peerings can remain during migration, but the final topology should be reviewed for unintended duplicate paths, route behavior, and security policy interactions.

Who should choose something else?

A small Azure environment with only a few virtual networks in one subscription may not need another centralized network-management layer. Manual peering, network security groups, route tables, and straightforward IP planning can be simpler and easier to operate at that scale.

Organizations whose primary problem is branch or hybrid connectivity should evaluate Azure Virtual WAN, VPN Gateway, or ExpressRoute. Teams that mainly need dynamic BGP exchange with network virtual appliances should evaluate Azure Route Server. Azure Virtual Network Manager is most useful when the hard problem is consistency across many Azure virtual networks, subscriptions, teams, or regions.