Merge pull request #244723 from mbender-ms/avnm-limitations

virtual network manager - New Article - limitations.md

Author: Jill Grant

articles/virtual-network-manager/TOC.yml

@@ -29,6 +29,8 @@
     href: faq.md
   - name: Use cases
     href: concept-use-cases.md
+  - name: limitations
+    href: concept-limitations.md
   - name: Scope
     href: concept-network-manager-scope.md
   - name: Network groups

articles/virtual-network-manager/concept-connectivity-configuration.md

@@ -30,7 +30,7 @@ A mesh network is a topology in which all the virtual networks in the [network g
 
 :::image type="content" source="./media/concept-configuration-types/mesh-topology.png" alt-text="Diagram of a mesh network topology.":::
 
-### <a name="connectedgroup"></a> Connected group
+### Connected group
 
 When you create a mesh topology, a new connectivity construct is created called *Connected group*. Virtual networks in a connected group can communicate to each other just like if you were to connect virtual networks together manually. When you look at the effective routes for a network interface, you'll see a next hop type of **ConnectedGroup**. Virtual networks connected together in a connected group don't have a peering configuration listed under *Peerings* for the virtual network.
 
@@ -48,7 +48,7 @@ In this configuration, you have settings you can enable such as *direct connecti
 
 ### Direct connectivity
 
-Enabling *Direct connectivity* creates an overlay of a [*connected group*](#connectedgroup) on top of your hub and spoke topology, which contains spoke virtual networks of a given group. Direct connectivity allows a spoke VNet to talk directly to other VNets in its spoke group, but not to VNets in other spokes.
+Enabling *Direct connectivity* creates an overlay of a [*connected group*](#connected-group) on top of your hub and spoke topology, which contains spoke virtual networks of a given group. Direct connectivity allows a spoke VNet to talk directly to other VNets in its spoke group, but not to VNets in other spokes.
 
 
 For example, you create two network groups. You enable direct connectivity for the *Production* network group but not for the *Test* network group. This set up only allows virtual networks in the *Production* network group to communicate with one another but not the ones in the *Test* network group. 
@@ -75,7 +75,7 @@ Enabling direct connectivity between spokes virtual networks can be helpful when
 
 #### Global mesh
 
-Like mesh, these spoke connected groups can be configured as regional or global. Global mesh is required when you want your spoke virtual networks to communicate with each other across regions. This connectivity is limited to virtual network in the same network group. To enable connectivity for virtual networks across regions, you need to **Enable mesh connectivity across regions** for the network group. Connections created between spokes virtual networks are in a [*Connected group*](#connectedgroup). 
+Like mesh, these spoke connected groups can be configured as regional or global. Global mesh is required when you want your spoke virtual networks to communicate with each other across regions. This connectivity is limited to virtual network in the same network group. To enable connectivity for virtual networks across regions, you need to **Enable mesh connectivity across regions** for the network group. Connections created between spokes virtual networks are in a [*Connected group*](#connected-group). 
 
 #### Use hub as a gateway
 

articles/virtual-network-manager/concept-limitations.md

@@ -0,0 +1,59 @@
+---
+title: 'Limitations with Azure Virtual Network Manager'
+description: Learn about current limitations when using Azure Virtual Network Manager to manage virtual networks.
+author: mbender-ms
+ms.author: mbender
+ms.service: virtual-network-manager
+ms.topic: conceptual
+ms.date: 07/18/2023
+ms.custom: template-concept
+#CustomerIntent: As a network administration, I want undertand the limitations in Azure Virtual Network Manager so that I can properly deploy a virtual manager in my environment.
+---
+
+# Limitations with Azure Virtual Network Manager
+
+This article provides an overview of the current limitations when using [Azure Virtual Network Manager](overview.md) to manage virtual networks. As a network administrator, it's important to understand these limitations in order to properly deploy an Azure Virtual Network Manager features in your environment. The article covers various limitations related to Azure Virtual Network Manager, including the maximum number of virtual networks, overlapping IP spaces, and policy compliance evaluation cycle. 
+
+> [!IMPORTANT]
+> Azure Virtual Network Manager is generally available for Virtual Network Manager and hub and spoke connectivity configurations. 
+>
+> Mesh connectivity configurations and security admin rules remain in public preview.
+> This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
+> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+
+## General limitations
+
+* [Cross-tenant support](concept-cross-tenant.md) is only available when virtual networks are assigned to network groups with static membership.
+
+* Customers with more than 15,000 Azure subscriptions can apply Azure Virtual Network Policy only at the [subscription and resource group scopes](concept-network-manager-scope.md). Management groups can't be applied over the 15 k subscription limit.
+   * If this is your scenario, you would need to create assignments at lower level management group scope that have less than 15,000 subscriptions.
+
+* Virtual networks can't be added to a network group when the Azure Virtual Network Manager custom policy `enforcementMode` element is set to `Disabled`.
+
+* Azure Virtual Network Manager policies don't support the standard policy compliance evaluation cycle. For more information, see [Evaluation triggers](../governance/policy/how-to/get-compliance-data.md#evaluation-triggers).
+
+## Connected group limitations
+
+* A connected group can have up to 250 virtual networks. Virtual networks in a [mesh topology](concept-connectivity-configuration.md#mesh-network-topology) are in a [connected group](concept-connectivity-configuration.md#connected-group), therefore a mesh configuration has a limit of 250 virtual networks.
+* The current preview of connected group has a limitation where traffic from a connected group can't communicate with a private endpoint in this connected group if it has a network security group enabled on it. However, this limitation will be removed once the feature is generally available.
+* You can have network groups with or without [direct connectivity](concept-connectivity-configuration.md#direct-connectivity) enabled in the same [hub-and-spoke configuration](concept-connectivity-configuration.md#hub-and-spoke-topology), as long as the total number of virtual networks peered to the hub **doesn't exceed 500** virtual networks.
+    * If the network group peered with the hub **has direct connectivity enabled**, these virtual networks are in a *connected group*, therefore the network group has a limit of **250** virtual networks.
+    * If the network group peered with the hub **doesn't have direct connectivity enabled**, the network group can have up to the total limit for a hub-and-spoke topology.
+* A virtual network can be part of up to two connected groups. For example, a virtual network:
+
+    - Can be part of two mesh configurations.
+    - Can be part of a mesh topology and a network group that has direct connectivity enabled in a hub-and-spoke topology.
+    - Can be part of two network groups with direct connectivity enabled in the same or different hub-and-spoke configuration.
+
+* You can have virtual networks with overlapping IP spaces in the same connected group. However, communication to an overlapped IP address is dropped.
+
+## Security admin rule limitations
+
+* The maximum number of IP prefixes in all [security admin rules](concept-security-admins.md) combined is 1000. 
+
+* The maximum number of admin rules in one level of Azure Virtual Network Manager is 100. 
+
+## Related content
+
+- [Frequently asked questions](faq.md)
+