Merge pull request #302499 from andreamichaelmsft/andrea-branch-1

[Azure Doc-a-thon] Heavy updates to AVNM overview page & ASG overview page

Author: denrea

articles/virtual-network-manager/overview.md

@@ -5,41 +5,57 @@ services: virtual-network-manager
 author: mbender-ms
 ms.service: azure-virtual-network-manager
 ms.topic: overview
-ms.date: 03/22/2024
+ms.date: 07/09/2025
 ms.author: mbender
 ms.custom: references_regions
 #Customer intent: As an IT administrator, I want to learn about Azure Virtual Network Manager and what I can use it for.
 ---
 
 # What is Azure Virtual Network Manager?
 
-Azure Virtual Network Manager is a management service that enables you to group, configure, deploy, and manage virtual networks globally across subscriptions. With Virtual Network Manager, you can define network groups to identify and logically segment your virtual networks. Then you can determine the connectivity and security configurations you want and apply them across all the selected virtual networks in network groups at once.
+Azure Virtual Network Manager is a centralized management service that enables you to group, configure, deploy, and manage virtual networks globally across subscriptions and tenants. As organizations scale their cloud infrastructure, managing multiple virtual networks across different regions and subscriptions becomes increasingly complex. Azure Virtual Network Manager addresses this challenge by providing a unified pane of glass for network administration.
+
+With Virtual Network Manager, you can define network groups to identify and logically segment your virtual networks. Then you can determine the connectivity, security, and routing configurations you want and apply them across all the selected virtual networks in network groups at once, ensuring consistent network policies across your entire infrastructure. You can also leverage Virtual Network Manager's capabilities to manage your organization's IP address space and democratize simple network connectivity troubleshooting.
 
 ## How does Azure Virtual Network Manager work?
 
-:::image type="content" source="./media/overview/management-group.png" alt-text="Diagram of management group in Virtual Network Manager.":::
+:::image type="content" source="./media/overview/management-group.png" alt-text="Diagram of management group, subscription, and virtual network hierarchy in Virtual Network Manager.":::
+
+During the creation process, you define the scope for what your Azure Virtual Network Manager instance, or *network manager*, manages. Your network manager only has the delegated access for resource visibility, configuration deployment, and IP address management within this scope boundary. You can define a scope directly over a list of subscriptions. You may also use [management groups](../governance/management-groups/overview.md) to define your scope. Management groups provide hierarchical organization to your subscriptions. After defining your network manager's scope, you can deploy configuration types including *Connectivity*, *Security admin*, and *Routing* across grouped network resources within this scope. You can also use the network manager to manage your organization's IP address space and troubleshoot reachability issues across the Azure network resources within your network manager's scope.
 
-During the creation process, you define the scope for what your Azure Virtual Network Manager manages. Your Network Manager only has the delegated access to apply configurations within this scope boundary. Defining a scope can be done directly on a list of subscriptions. However, we recommend you use [management groups](../governance/management-groups/overview.md) to define your scope. Management groups provide hierarchical organization to your subscriptions. After defining the scope, you deploy configuration types including *Connectivity* and the *SecurityAdmin rules* for your Virtual Network Manager.
+After you deploy the network manager, you create a *network group*, which serves as a logical container of networking resources to apply configurations at scale. You can manually select individual virtual networks to be added to your network group, or you can use Azure Policy to define conditions that govern your group membership dynamically. For more information about Azure Policy initiatives, see [Network groups and Azure Policy](concept-network-groups.md#network-groups-and-azure-policy).
 
-After you deploy the Virtual Network Manager instance, you create a *network group*, which serves as a logical container of networking resources to apply configurations at scale. You can manually select individual virtual networks to be added to your network group, known as static membership. Or you can use Azure Policy to define conditions that govern your group membership dynamically, or dynamic membership. For more information about Azure Policy initiatives, see [Azure Virtual Network Manager and Azure Policy](concept-network-groups.md#network-groups-and-azure-policy).  
+Next, you create configurations applied to those network groups based on your topology and security needs. A [connectivity configuration](concept-connectivity-configuration.md) enables you to create a mesh or a hub-and-spoke network topology using your network groups. A [security admin configuration](concept-security-admins.md) allows you to define a collection of security admin rules that you can apply onto one or more network groups, programming those rules across your virtual networks globally. A [routing configuration](concept-user-defined-route.md) lets you describe and orchestrate [user-defined routes](../virtual-network/virtual-networks-udr-overview.md) at scale to control traffic flow according to your desired routing behavior. 
 
-Next, you create connectivity and/or security configurations applied to those network groups based on your topology and security needs. A [connectivity configuration](concept-connectivity-configuration.md) enables you to create a mesh or a hub-and-spoke network topology. A [security configuration](concept-security-admins.md) allows you to define a collection of rules that you can apply to one or more network groups at the global level. Once you create your desired network groups and configurations, you can deploy the configurations to any region of your choosing.
+Once you create your desired network groups and configurations, you can deploy the configurations to any region of your choosing. **Configurations do not take effect until they are deployed to regions containing your target network resources.**
 
-Azure Virtual Network Manager can be deployed and managed through the [Azure portal](./create-virtual-network-manager-portal.md), [Azure CLI](./create-virtual-network-manager-cli.md), [Azure PowerShell](./create-virtual-network-manager-powershell.md), or [Terraform](./create-virtual-network-manager-terraform.md).
+Azure Virtual Network Manager can be deployed and managed through the [Azure portal](./create-virtual-network-manager-portal.md), [Azure CLI](./create-virtual-network-manager-cli.md), [Azure PowerShell](./create-virtual-network-manager-powershell.md), [Bicep](./create-virtual-network-manager-bicep.md), or [Terraform](./create-virtual-network-manager-terraform.md).
 
 ## Key benefits
 
-- Centrally manage connectivity and security policies globally across regions and subscriptions.
+- **Centralized management**: Manage connectivity and security policies globally across regions and subscriptions from a single pane of glass, reducing administrative overhead and ensuring consistency.
+
+- **Simplified hub-and-spoke connectivity**: Enable direct connectivity between spoke virtual networks in a hub-and-spoke configuration without the complexity of managing a mesh network or manually configuring additional peerings.
+
+- **Enterprise-grade reliability**: Azure Virtual Network Manager is a highly scalable and highly available service with redundancy and replication across the globe.
+
+- **Advanced security controls**: Create network security rules that are evaluated before network security group rules, providing granular control over traffic flow with global enforcement capabilities.
+
+- **Optimized performance**: Low latency and high bandwidth between resources in different virtual networks using virtual network peering.
+
+- **Flexible deployment**: Roll out network changes through a specific region sequence and frequency of your choosing for controlled and safe network updates and rollbacks.
+
+- **Cost optimization**: Reduce operational costs by automating network management tasks and eliminating the need for complex custom scripting solutions.
 
-- Enable direct connectivity between spokes in a hub-and-spoke configuration without the complexity of managing a mesh network.
+- **Centralized IP address management**: Manage your organization's IP address space by automatically allocating non-overlapping IP address space from IP address pools to prevent address space conflicts across on-premises and multicloud environments.
 
-- Highly scalable and highly available service with redundancy and replication across the globe.
+- **Reachability verification**: Validate Azure network policies and troubleshoot connectivity issues by analyzing reachability paths between Azure resources and identifying Azure policies and configurations disallowing network traffic.
 
-- Ability to create network security rules that override network security group rules.
+## Use cases
 
-- Low latency and high bandwidth between resources in different virtual networks using virtual network peering.
+Learn more about [common use cases](concept-use-cases.md) for Azure Virtual Network Manager.
 
-- Roll out network changes through a specific region sequence and frequency of your choosing.
+## Regions
 
 For current information on the regions where Azure Virtual Network Manager is available, see [Azure Virtual Network Manager regions](https://azure.microsoft.com/explore/global-infrastructure/products-by-region/?products=virtual-network-manager).
 
@@ -50,12 +66,12 @@ New Azure Virtual Network Manager instances charge solely on the virtual network
 
 Azure Virtual Network Manager instances created before the release of the virtual network-based pricing continue to charge on the subscription-based pricing described in the pricing page. If you prefer for your Azure Virtual Network Manager instance to instead charge on the virtual network-based pricing, follow these steps to switch its pricing model through Azure Feature Exposure Control (AFEC).
 
-1. In the Azure Portal, search for "Preview features".
-2. On the "Preview Features" page, ensure the subscription selected is the subscription that contains your Azure Virtual Network Manager instance. Filter the features by "Network manager".
-3. Select the feature named "Network manager billing by virtual networks" and register. The Azure Virtual Network Manager instance in the registered subscription now charges on the virtual network-based pricing.
+1. In the Azure portal, search for **Preview features**.
+2. On the **Preview Features** page, ensure the subscription selected is the subscription that contains your Azure Virtual Network Manager instance. Filter the features by *Network manager*.
+3. Select the feature named **Network manager billing by virtual networks** and register. The Azure Virtual Network Manager instance in the registered subscription now charges on the virtual network-based pricing.
 
 > [!NOTE]
-> This virtual network-based pricing is [generally available](https://azure.microsoft.com/updates/?id=480669). Its enablement mechanism is available through AFEC because the previous subscription-based pricing is not yet retired and for ease of setup.
+> This virtual network-based pricing is [generally available](https://azure.microsoft.com/updates/?id=480669). Its enablement mechanism is available through AFEC for ease of setup and because the previous subscription-based pricing is not yet retired. The subscription-based pricing announced its retirement to pre-existing Azure Virtual Network Manager customers on February 6, 2025, and will be fully retired in February 6, 2028. Any Azure Virtual Network Manager instances still using the subscription-based pricing after February 6, 2028, will be automatically switched to the virtual network-based pricing.
  
 ## FAQs  
 For FAQs, see [Azure Virtual Network Manager FAQs](faq.md).
@@ -69,4 +85,4 @@ For SLA, see [SLA for Azure Virtual Network Manager](https://www.microsoft.com/l
 ## Next steps
 
 > [!div class="nextstepaction"]
-> [Create an Azure Virtual Network Manager instance using the Azure portal](create-virtual-network-manager-portal.md).
+> [Create an Azure Virtual Network Manager instance in the Azure portal](create-virtual-network-manager-portal.md).

articles/virtual-network/application-security-groups.md

@@ -5,7 +5,7 @@ description: Learn about the use of application security groups.
 author: asudbring
 ms.service: azure-virtual-network
 ms.topic: concept-article
-ms.date: 03/31/2025
+ms.date: 07/09/2025
 ms.author: allensu
 # Customer intent: As a network administrator, I want to configure application security groups for my virtual machines, so that I can easily manage network security policies and reduce the complexity of maintaining explicit IP addresses.
 ---
@@ -16,7 +16,7 @@ Application security groups enable you to configure network security as a natura
 
 :::image type="content" source="./media/security-groups/application-security-groups.png" alt-text="Diagram of Application security groups.":::
 
-In the previous picture, *NIC1* and *NIC2* are members of the *AsgWeb* application security group. *NIC3* is a member of the *AsgLogic* application security group. *NIC4* is a member of the *AsgDb* application security group. Though each network interface (NIC) in this example is a member of only one application security group, a network interface can be a member of multiple application security groups, up to the [Azure limits](../azure-resource-manager/management/azure-subscription-service-limits.md?toc=%2fazure%2fvirtual-network%2ftoc.json#azure-resource-manager-virtual-networking-limits). None of the network interfaces have an associated network security group. *NSG1* is associated to both subnets and contains the following rules:
+In the previous picture, *NIC1* and *NIC2* are members of the *AsgWeb* application security group. *NIC3* is a member of the *AsgLogic* application security group. *NIC4* is a member of the *AsgDb* application security group. Although each network interface (NIC) in this example is a member of only one application security group, a network interface can be a member of multiple application security groups, up to the [Azure limits](../azure-resource-manager/management/azure-subscription-service-limits.md?toc=%2fazure%2fvirtual-network%2ftoc.json#azure-resource-manager-virtual-networking-limits). None of the network interfaces have an associated network security group. *NSG1* is associated to both subnets and contains the following rules:
 
 ## Allow-HTTP-Inbound-Internet
 
@@ -28,7 +28,7 @@ This rule is needed to allow traffic from the internet to the web servers. Becau
 
 ## Deny-Database-All
 
-Because the **AllowVNetInBound** default security rule allows all communication between resources in the same virtual network, this rule is needed to deny traffic from all resources.
+Because the **AllowVNetInBound** default security rule allows all communication between resources in the same virtual network, you need this rule to deny traffic from all resources.
 
 |Priority|Source|Source ports| Destination | Destination ports | Protocol | Access |
 |---|---|---|---|---|---|---|
@@ -42,20 +42,23 @@ This rule allows traffic from the *AsgLogic* application security group to the *
 |---|---|---|---|---|---|---|
 | 110 | AsgLogic | * | AsgDb | 1433 | TCP | Allow |
 
-Network interfaces that are members of the application security group apply the rules that specify it as the source or destination. The rules don't affect other network interfaces. If the network interface isn't a member of an application security group, the rule isn't applied to the network interface, even though the network security group is associated to the subnet.
+Network interfaces that are members of the application security group apply the network security group rules that specify it as the source or destination. The network security group rules don't affect other network interfaces. If the network interface isn't a member of an application security group, the rule doesn't apply to the network interface, even though the network security group is associated to the subnet.
+
+
+## Constraints
 
 Application security groups have the following constraints:
 
 - There are limits to the number of application security groups you can have in a subscription, and other limits related to application security groups. For details, see [Azure limits](../azure-resource-manager/management/azure-subscription-service-limits.md?toc=%2fazure%2fvirtual-network%2ftoc.json#azure-resource-manager-virtual-networking-limits).
 
-- All network interfaces assigned to an application security group have to exist in the same virtual network that the first network interface assigned to the application security group is in. For example, if the first network interface assigned to an application security group named *AsgWeb* is in the virtual network named *VNet1*, then all subsequent network interfaces assigned to *ASGWeb* must exist in *VNet1*. You can't add network interfaces from different virtual networks to the same application security group.
+- All network interfaces assigned to an application security group must exist in the same virtual network that the first network interface assigned to the application security group is in. For example, if the first network interface assigned to an application security group named *AsgWeb* is in the virtual network named *VNet1*, then all subsequent network interfaces assigned to *ASGWeb* must exist in *VNet1*. You can't add network interfaces from different virtual networks to the same application security group.
 
-- If you specify an application security group as the source and destination in a security rule, the network interfaces in both application security groups must exist in the same virtual network. 
+- If you specify an application security group as the source and destination in a network security group rule, the network interfaces in both application security groups must exist in the same virtual network. 
 
-    - An example would be if *AsgLogic* had network interfaces from *VNet1* and *AsgDb* had network interfaces from *VNet2*. In this case, it would be impossible to assign *AsgLogic* as the source and *AsgDb* as the destination in a rule. All network interfaces for both the source and destination application security groups need to exist in the same virtual network.
+    - For example, *AsgLogic* contains network interfaces from *VNet1* and *AsgDb* contains network interfaces from *VNet2*. In this case, it would be impossible to assign *AsgLogic* as the source and *AsgDb* as the destination in the same network security group rule. All network interfaces for both the source and destination application security groups must exist in the same virtual network.
 
 > [!TIP]  
-> To minimize the number of security rules you need, plan out the application security groups you require. Create rules using service tags or application security groups, rather than individual IP addresses or ranges of IP addresses, whenever possible.
+> To minimize the number of security rules you need, plan out your required application security groups. Create rules using service tags or application security groups, rather than individual IP addresses or ranges of IP addresses, when possible.
 
 ## Next steps