Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article provides an overview of the current limitations when you use Azure Virtual Network Manager to manage virtual networks. Understanding these limitations can help you properly deploy an Azure Virtual Network Manager instance, or network manager, in your environment. The article covers topics like the maximum number of virtual networks that a network manager can connect, how a network manager handles connected virtual networks with overlapping address space, and the evaluation cycle for policy compliance.
General limitations
Currently, you can only add cross-tenant virtual networks to network groups manually. See Static membership.
If you have more than 15,000 Azure subscriptions, you can only apply an Azure Virtual Network Manager policy at the subscription and resource group scopes. You can't apply policies onto management groups that exceed the 15,000 subscription limit. In this scenario, you need to create assignments at lower-level management group scopes that each have fewer than 15,000 subscriptions.
You can't add virtual networks to a network group when the Azure Virtual Network Manager custom policy
enforcementModeelement is set toDisabled.Azure Virtual Network Manager policies don't support the standard evaluation cycle for policy compliance. For more information, see Evaluation triggers.
Moving the subscription where the Azure Virtual Network Manager instance exists to another tenant isn't supported.
In Azure operated by 21Vianet regions, you can't currently use tags on resource groups and subscriptions in Azure Policy definitions for network group membership.
You can't move an Azure Virtual Network Manager instance from the existing subscription to another subscription.
Limitations for connected groups
You can peer a virtual network with up to 1,000 virtual networks by using Azure Virtual Network Manager's hub-and-spoke connectivity configuration. This limit means you can peer up to 1,000 spoke virtual networks to a hub virtual network.
By default, each connected group supports up to 2,000 private endpoints.
By default, each connected group supports up to 250 virtual networks.
By default, a virtual network can be part of up to two connected groups. For example, a virtual network:
- Can be part of two mesh connectivity configurations.
- Can be part of a mesh connectivity configuration and a spoke network group that has direct connectivity enabled in a hub-and-spoke connectivity configuration.
- Can be part of two spoke network groups with direct connectivity enabled in the same or different hub-and-spoke connectivity configurations.
The following BareMetal Infrastructures aren't supported in connected groups:
- Azure VMware Solution
- Nutanix Cloud Clusters on Azure
- Oracle Database@Azure
- Azure Payment HSM
You can have virtual networks with overlapping IP spaces in the same connected group. However, communication to an overlapped IP address is dropped.
When a connected group's virtual network is peered with an external virtual network that has overlapping IP address space with any member of the connected group, these overlapping address spaces become inaccessible within the connected group. Traffic from the peered virtual network in the connected group to the overlapping address space is routed to the external virtual network, while traffic from other virtual networks in the connected group to the overlapping address space is dropped.
Limitations for security admin rules
The maximum number of IP prefixes in all security admin rules combined is 20,000.
The maximum number of security admin rules in one level of Azure Virtual Network Manager is 100.
The service tags AzurePlatformDNS, AzurePlatformIMDS, and AzurePlatformLKM aren't currently supported in security admin rules.
Limitations for IP address management (IPAM)
- Currently, you can't remove address spaces managed by IPAM from virtual networks or subnets. This restriction applies only to IPAM-managed address spaces, not to other address spaces. For example, if IPv4 is managed by IPAM but IPv6 isn't, you can still remove IPv6 address spaces. You also can't remove IP address spaces from an IPAM pool.