Heavily updated all AVNM general docs

Author: andreamichaelmsft

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

@@ -5,49 +5,49 @@ author: mbender-ms
 ms.author: mbender
 ms.service: azure-virtual-network-manager
 ms.topic: concept-article
-ms.date: 05/06/2024
+ms.date: 07/11/2025
 ---
 
-# Manage Configuration Deployments in Azure Virtual Network Manager
+# Manage configuration deployments in Azure Virtual Network Manager
 
-Learn how configuration deployments in Azure Virtual Network Manager are applied to your network resources. Explore how updating a configuration deployment differs by membership type, and understand details about *Deployment status* and *Goal state model*.
+Learn how configuration deployments in Azure Virtual Network Manager are applied to your network resources. Explore how updating a configuration deployment differs by network group membership type, and understand details about [deployment status](#deployment-status-and-monitoring) and the [goal state model](#goalstate).
 
 ## How deployment works
 
-*Deployment* is the method Azure Virtual Network Manager uses to apply configurations to your virtual networks in network groups. Configurations don't take effect until they're deployed. When a deployment request is sent to Azure Virtual Network Manager, it calculates the [goal state](#goalstate) of all resources under your network manager in that region. Goal state is a combination of deployed configurations and network group membership. Network manager applies the necessary changes to your infrastructure.
+*Deployment* is the method Azure Virtual Network Manager uses to apply configurations to your network groups' virtual networks. Configurations don't take effect until they're deployed. When a deployment request is sent to Azure Virtual Network Manager, it calculates the [goal state](#goalstate) of all targeted resources under your network manager in the targeted regions. The goal state is a combination of deployed configurations and network group membership. Azure Virtual Network Manager applies the necessary changes to your resources' settings to achieve the desired goal state.
 
-When committing a deployment, you select the regions where the configuration applies. The length of time for a deployment depends on how large the configuration is. Once the virtual networks are members of a network group, deploying a configuration onto that network group takes a few minutes. This includes adding or removing group members directly, or configuring an Azure Policy resource. Safe deployment practices recommend gradually rolling out changes on a per-region basis.
+When committing a deployment, you select the regions where you want the selected configurations to apply. The time it takes for a deployment to complete depends on how large the configuration is. Once the virtual networks are members of a network group targeted by a configuration, deploying that configuration onto that network group can take a few minutes. This scenario includes adding or removing virtual networks to or from the targeted network group manually or conditionally with Azure Policy. Safe deployment practices recommend gradually rolling out changes on a per-region basis.
 
 > [!IMPORTANT]
-> Only one security configuration can be deployed to a region. However, multiple connectivity configurations can exist in a region. To deploy multiple security admin configurations to a region, you can create multiple rule collections in a security configuration, instead of creating multiple security admin configurations.
+> Only one security admin configuration can be deployed from a single network manager to a region at a time. However, multiple connectivity and routing configurations can exist in a region. To deploy multiple sets of security admin rules to a region, you can create multiple rule collections within a security admin configuration.
 
 ## Deployment latency and timing
 
-Deployment latency is the time it takes for a deployment configuration to be applied and take effect. There are two factors in how quickly the configurations are applied: 
+There are two factors in how quickly a deployment's configurations are applied and take effect: 
 
-- The base time of applying a configuration is a few minutes. 
+- The base time of applying a configuration is a few minutes.
 
-- The time to receive a notification of network group membership can vary. 
+- The time to update network group membership (and thus the members onto which active configurations are newly applied to or removed from) can vary.
 
-For manually added members, notification is immediate. For dynamic members where the scope is less than 1,000 subscriptions, notification takes a few minutes. In environments with more than 1,000 subscriptions, the notification mechanism works in a 24-hour window. Changes to network groups take effect without the need for configuration redeployment.  
+For manually added members, the network group membership immediately updates. For conditionally added members where the scope is less than 1,000 subscriptions, the network group membership can take a few minutes to update. For conditionally added members in environments with more than 1,000 subscriptions, the network group gets notified by Azure Policy in a 24-hour window; after that notification, active configurations are applied to the updated network group members in a few minutes. Changes to network group membership take effect without the need for configuration redeployment.
 
-Virtual network manager applies the configuration to the virtual networks in the network group even if your network group consists of dynamic members from more than 1,000 subscriptions. When the virtual network manager is notified of group membership, the configuration is applied in a few minutes. 
+For example, if a virtual network is newly added to a network group with an active configuration already deployed onto it in the same region as that new virtual network member, that virtual network automatically receives the configuration without manually deploying the configuration again.
 
 ## Deployment status and monitoring
 
-When you commit a configuration deployment, the API does a POST operation. Once the deployment request is made, Azure Virtual Network Manager calculates the goal state of your networks in the deployed regions and requests the underlying infrastructure to make the changes. You can see the deployment status on the *Deployment* page of the Virtual Network Manager.
+When you commit a configuration deployment, the API forms a POST operation. Once the deployment request is made, Azure Virtual Network Manager calculates the goal state of your networks in the deployed regions and requests the underlying infrastructure to make the changes. You can see the deployment status on the *Deployment* page of your Azure Virtual Network Manager instance, or network manager.
 
 :::image type="content" source="./media/tutorial-create-secured-hub-and-spoke/deployment-in-progress.png" alt-text="Screenshot of deployment in progress in deployment list.":::
 
 ## <a name = "goalstate"></a> Goal state model
 
-When you commit a deployment of configurations, you're describing the goal state of your network manager in that region. This goal state is enforced during the next deployment. For example, when you commit configurations named *Config1* and *Config2* into a region, these two configurations get applied and become the region's goal state. If you decided to commit configuration named *Config1* and *Config3* into the same region, *Config2* would then be removed, and *Config3* would be added. To remove all configurations, you would deploy a **None** configuration against the regions you no longer wish to have any configurations applied.
+When you commit a deployment of configurations, you describe the goal state of your network manager in the targeted regions. This goal state is enforced during the next deployment. For example, when you commit configurations *Config1* and *Config2* into a region, these two configurations get applied and become the region's goal state. If you decided to commit configurations *Config1* and *Config3* into the same region, *Config2* would then be removed, and *Config3* would be added. To remove all configurations, you would deploy **None** to the regions where you no longer wish to have any configurations applied.
 
 ## Configuration availability
 
-A virtual network manager instance is available in a region as long as the region is up and running. Should a region with a virtual network manager go down, the virtual network manager instance is no longer available for deploying new configurations or editing current configurations. However, the configurations that were deployed to the virtual networks in the network group are still in effect unless those virtual networks are in the region that went down.
+A network manager is available in a region as long as the region is up and running. Should a region with a network manager go down, the network manager is no longer available to submit new configuration deployments or modify existing configurations. However, the configurations that were deployed to the targeted network groups' virtual networks in the targeted regions are still in effect unless those virtual networks are in the region that went down.
 
-For example, if an Azure Virtual Network Manager instance is created in region A and programs the VNets in region B, the configurations are still in effect even if region A goes down. However, if region B goes down, the configurations are no longer in effect. Also, you can't create new configurations or edit current configurations for virtual networks in region B.
+For example, if a network manager is created in *regionA* and deployed configurations onto virtual networks in *regionB*, those configurations are still in effect even if *regionA* goes down. However, you won't be able to create new, modify existing, or deploy configurations from the network manager in *regionA*. As another example, if *regionB* goes down, those configurations are no longer in effect. In this case, further deployments to virtual networks in *regionB* won't be successful.
 
 ## Next steps
 

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

@@ -5,53 +5,62 @@ author: mbender-ms
 ms.author: mbender
 ms.service: azure-virtual-network-manager
 ms.topic: concept-article
-ms.date: 11/06/2024
+ms.date: 07/11/2025
 #CustomerIntent: As a network admin, I want understand the limitations in Azure Virtual Network Manager so that I can properly deploy it my environment.
 ms.custom:
   - build-2025
 ---
 
 # Limitations with Azure Virtual Network Manager
 
-This article provides an overview of the current limitations when you're using [Azure Virtual Network Manager](overview.md) to manage virtual networks. Understanding these limitations can help you properly deploy an Azure Virtual Network Manager instance in your environment. The article covers topics like the maximum number of virtual networks, overlapping IP spaces, and the evaluation cycle for policy compliance.
+This article provides an overview of the current limitations when you're using [Azure Virtual Network Manager](overview.md) 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
 
-* [Cross-tenant support](concept-cross-tenant.md) is available only when virtual networks are assigned to network groups with static membership.
+* Currently, [cross-tenant](concept-cross-tenant.md) virtual networks can only be [added to network groups manually](concept-network-groups.md#static-membership). Adding cross-tenant virtual networks to network groups conditionally through Azure Policy is a future capability.
 
-* Customers with more than 15,000 Azure subscriptions can apply an Azure Virtual Network Manager policy only at the [subscription and resource group scopes](concept-network-manager-scope.md). You can't apply management groups over the limit of 15,000 subscriptions. In this scenario, you would need to create assignments at a lower-level management group scope that have fewer than 15,000 subscriptions.
+* Customers with more than 15,000 Azure subscriptions can only apply an Azure Virtual Network Manager policy at the [subscription and resource group scopes](concept-network-manager-scope.md). You can't apply policies onto management groups over the limit of 15,000 subscriptions. In this scenario, you would 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 `enforcementMode` element is set to `Disabled`.
 
 * Azure Virtual Network Manager policies don't support the standard evaluation cycle for policy compliance. For more information, see [Evaluation triggers](../governance/policy/how-to/get-compliance-data.md#evaluation-triggers).
-* The move of the subscription where the Azure Virtual Network Manager instance exists to another tenant is not supported.
 
-* In the Azure China regions, currently, using tags on resource groups and subscriptions as a condition in dynamic membership is not supported.
+* The move of the subscription where the Azure Virtual Network Manager instance exists to another tenant isn't supported.
+
+* In Azure China regions, using tags on resource groups and subscriptions in Azure Policy definitions for network group membership isn't currently supported.
 
 ## Limitations for connected groups 
 
-* A virtual network can be peered up to 1000 virtual networks using Azure Virtual Network Manager's hub and spoke topology. This means that you can peer up to 1000 spoke virtual networks to a hub virtual network.
-* By default, a [connected group](concept-connectivity-configuration.md) can have up to 250 virtual networks. This is a soft limit and can be increased up to 1000 virtual networks by submitting a request using [this form](https://forms.office.com/pages/responsepage.aspx?id=v4j5cvGGr0GRqy180BHbRzeHatNxLHpJshECDnD5QidURTM2OERMQlYxWkE1UTNBMlRNUkJUNkhDTy4u&route=shorturl).
-* 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 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 a different hub-and-spoke configuration.
-  * This is a soft limit and can be adjusted by submitting a request using [this form](https://forms.office.com/r/xXxYrQt0NQ).  
-* The following BareMetal Infrastructures are not supported in connected group:
+* A virtual network can be peered with up to 1,000 virtual networks using Azure Virtual Network Manager's hub-and-spoke connectivity configuration, meaning you can peer up to 1,000 spoke virtual networks to a hub virtual network.
+
+* By default, a [connected group](concept-connectivity-configuration.md#connected-group) can have up to 250 virtual networks. This default is a soft limit and can be increased up to 1,000 virtual networks by submitting a request using [this form](https://forms.office.com/pages/responsepage.aspx?id=v4j5cvGGr0GRqy180BHbRzeHatNxLHpJshECDnD5QidURTM2OERMQlYxWkE1UTNBMlRNUkJUNkhDTy4u&route=shorturl).
+
+* By default, a virtual network can be part of up to two [connected groups](concept-connectivity-configuration.md#connected-group). 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.
+  * This default is a soft limit and can be adjusted by submitting a request using [this form](https://forms.office.com/r/xXxYrQt0NQ).
+
+* The following BareMetal Infrastructures aren't supported in connected group:
   * [Azure NetApp Files](../azure-netapp-files/index.yml)
   * [Azure VMware Solution](../azure-vmware/index.yml)
   * [Nutanix Cloud Clusters on Azure](../baremetal-infrastructure/workloads/nc2-on-azure/about-nc2-on-azure.md)
   * [Oracle Database@Azure](../oracle/oracle-db/oracle-database-what-is-new.md)
   * [Azure Payment HSM](/azure/payment-hsm/solution-design)
-* The maximum number of private endpoints per connected group is 1000.
+
+* By default, the maximum number of private endpoints per connected group is 1,000. You can increase this limit in select regions through a preview feature [enabling high-scale private endpoints in connected groups](./concept-connectivity-configuration.md#enable-high-scale-private-endpoints-connected-groups-in-azure-virtual-network-manager).
+
 * 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 VNet is peered with an external VNet that has overlapping CIDRs, these overlapping CIDRs become inaccessible within the connected group. Traffic from the peered VNet in the connected group to the overlapping CIDR is routed to the external VNet, while traffic from other VNets in the connected group to the overlapping CIDR 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](concept-security-admins.md) combined is 20,000.
-* The maximum number of admin rules in one level of Azure Virtual Network Manager is 100.
-* The service tags AzurePlatformDNS, AzurePlatformIMDS, and AzurePlatformLKM are not currently supported in security admin rules.
+
+* 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.
 
 ## Related content