Update reliability guide

Author: johndowns

articles/reliability/reliability-virtual-network.md

@@ -4,113 +4,121 @@ description: Find out about reliability in Azure Virtual Network, including avai
 author: asudbring
 ms.author: allensu
 ms.topic: reliability-article
-ms.custom: subject-reliability, references_regions
+ms.custom: subject-reliability
 ms.service: azure-virtual-network
 ms.date: 05/20/2025
-#Customer intent: As an engineer responsible for business continuity, I want to understand who need to understand the details of how Azure Virtual Network works from a reliability perspective and plan disaster recovery strategies in alignment with the exact processes that Azure services follow during different kinds of situations. 
-
+#Customer intent: As an engineer responsible for business continuity, I want to understand who need to understand the details of how Azure Virtual Network works from a reliability perspective and plan disaster recovery strategies in alignment with the exact processes that Azure services follow during different kinds of situations.
 ---
 
 # Reliability in Azure Virtual Network
 
 This article describes reliability support in Azure Virtual Network, covering intra-regional resiliency via [availability zones](#availability-zone-support) and [multi-region deployments](#multi-region-support).
 
-Resiliency is a shared responsibility between you and Microsoft and so this article also covers ways for you to create a resilient solution that meets your needs.
+[!INCLUDE [Shared responsibility description](includes/reliability-shared-responsibility-include.md)]
 
-A Virtual Network is a logical representation of your network in the cloud. It allows you to define your own private IP address space and segment the network into subnets. Virtual networks serve as a trust boundary to host your compute resources such as Azure Virtual Machines and load balancers. A virtual network allows direct private IP communication between the resources hosted in it. You can link a virtual network to an on-premises network through a VPN Gateway, or ExpressRoute.
+A virtual network is a logical representation of your network in the cloud. It allows you to define your own private IP address space and segment the network into subnets. Virtual networks serve as a trust boundary to host your compute resources such as Azure Virtual Machines and load balancers. A virtual network allows direct private IP communication between the resources hosted in it. You can link a virtual network to an on-premises network through a VPN Gateway or ExpressRoute, to enable hybrid cloud scenarios and to securely extend your datacenter into Azure.
 
 ## Production deployment recommendations
 
-A virtual network is created within the scope of a region. You can create virtual networks with the same address space in two different regions, but because they have the same address space, you can't connect them together.
+As you build your virtual network in Azure, it's important to keep in mind the following universal design principles that help to improve the reliability of your solution:
+
+* Ensure address spaces don't overlap. Make sure your virtual network address space (CIDR block) doesn't overlap with your organization's other network ranges.
+* Your subnets shouldn't cover the entire address space of the virtual network. Plan ahead and reserve some address space for the future.
+* Use a few large virtual networks instead of multiple small ones to reduce management overhead.
+* Secure your virtual networks by assigning Network Security Groups (NSGs) to the subnets beneath them.
+
+To learn more about how to design your Azure virtual network with reliablity principles in mind, as well as other important best practices, see [Architecture best practices for Azure Virtual Network](/azure/well-architected/service-guides/virtual-network).
 
-Use virtual networks to:
+## Reliability architecture overview
 
-* Create a dedicated, private, cloud-only virtual network. Sometimes you don't require a cross-premises configuration for your solution. When you create a virtual network, your services and virtual machines (VMs) within your virtual network can communicate directly and securely with each other in the cloud. You can still configure endpoint connections for the VMs and services that require internet communication, as part of your solution.
+A virtual network is one of several core networking components in Azure. When you create virtual networks, you typically create a set of resources that collectively define your networking configuration, including:
 
-* Securely extend your datacenter. With virtual networks, you can build traditional site-to-site (S2S) VPNs to securely scale your datacenter capacity. S2S VPNs use IPsec to provide a secure connection between your corporate VPN gateway and Azure.
+- Network security groups (NSGs) and application security groups (ASGs), which restrict communication between parts of your network.
+- User-defined routes, which control how traffic flows.
+- Load balancers, which distribute traffic within your network.
+- Public IP addresses, which provide connectivity to and from the internet.
+- Network interface cards (NICs), which provide network connectivity to Azure virtual machines.
+- Private endpoints, which provide private connectivity to Azure services and to resources outside of your own virtual network.
 
-* Enable hybrid cloud scenarios. You can securely connect cloud-based applications to any type of on-premises system, including mainframes and Unix systems.
+You might also deploy *appliances*, including ExpressRoute gateways, VPN gateways, and firewalls. Appliances provide services to support your networking needs, such as connecting to on-premises environments or providing sophisticated controls on traffic flow.
 
-## Reliability architecture overview
+Finally, you deploy your own components, like virtual machines that run applications or databases, as well as other Azure services that provide virtual network integration.
 
-Virtual networks and subnets span all availability zones in a region. You don't need to divide them by availability zones to accommodate zonal resources. For example, if you configure a zonal VM, you don't have to take into consideration the virtual network when selecting the availability zone for the VM. The same is true for other zonal resources.
+> [!IMPORTANT]
+> This guide focuses on Azure virtual networks, which are just one component in your network architecture.
+>
+> From a reliability perspective, it's important that you consider each component in your solution individually as well as how they behave together. Many core Azure networking services provide high resiliency by default, but you might need to consider how other network appliances, virtual machines, and other components can support your reliability needs. Review the reliability guides for each Azure service you use to understand how that service supports reliability.
+
+To learn more about networking in Azure, see [Networking architecture design](/azure/architecture/networking/).
 
 ## Transient faults
 
 [!INCLUDE [Transient fault description](includes/reliability-transient-fault-description-include.md)]
 
-When a transient fault occurs, resources within an Azure Virtual Network automatically retry communication attempts. This built-in resiliency ensures that temporary disruptions, such as brief network interruptions or service unavailability, do not result in permanent failures. By leveraging retry logic, resources can recover from transient issues without requiring manual intervention, helping to maintain connectivity and application reliability.
+Virtual networks themselves aren't typically affected by transient faults themselves. However, transient faults might affect resources deployed within a virtual network. Review the reliability guide for each resource you use to understand their transient fault handling behaviors.
 
 ## Availability zone support
 
-[!INCLUDE [AZ support description](includes/reliability-availability-zone-description-include.md)] 
-
-A virtual network deployed in a region is spanned across availability zones within that region. User intervention isn't required to enable this support.
+[!INCLUDE [AZ support description](includes/reliability-availability-zone-description-include.md)]
 
-### Region support 
+A virtual network deployed in a region spans all availability zones within that region. Similarly, subnets within each virtual network span all availability zones within the region. User intervention isn't required to enable this support.
 
-Azure Virtual Network is available in all Azure regions. Azure Virtual Networks are limited to a single region when deployed.
+You don't need to divide your virtual networks or subnets by availability zones to accommodate zonal resources. For example, if you configure a zonal VM, you don't have to take into consideration the virtual network when selecting the availability zone for the VM. The same is true for other zonal resources.
 
-### Considerations 
+### Region support
 
-If an outage occurs for an entire region, the virtual network and the resources in the affected region remain inaccessible during the time of the service disruption.
+Zone-redundant virtual networks can be deployed in [any region that supports availability zones](./regions-list.md).
 
 ### Cost
 
-Region zone redundancy for Azure Virtual Networks doesn't incur a charge.
-
-### Configure availability zone support 
+Zone redundancy for Azure Virtual Networks doesn't incur a charge.
 
-Zone redundancy is configured automatically when a virtual network is deployed in a region.
+### Configure availability zone support
 
-### Capacity planning and management 
+Zone redundancy is configured automatically when a virtual network is deployed in a region that supports availability zones.
 
-As you build your network in Azure, it's important to keep in mind the following universal design principles:
-
-* Ensure address spaces don't overlap. Make sure your virtual network address space (CIDR block) doesn't overlap with your organization's other network ranges.
+### Zone-down experience
 
-* Your subnets shouldn't cover the entire address space of the virtual network. Plan ahead and reserve some address space for the future.
+Azure virtual networks are designed to be resilient to zone failures. When a zone becomes unavailable, Azure Virtual Network automatically reroutes virtual network requests to the remaining zones. This process is seamless and doesn't require any action from you.
 
-* Use a few large virtual networks instead of multiple small ones to reduce management overhead.
+However, any resources within the virtual network need to be considered individually, because each resource might have a different set of behaviors during the loss of an availability zone. Consult the reliability guide for each resource you use to understand their availability zone support and behavior when a zone is unavailable.
 
-* Secure your virtual networks by assigning Network Security Groups (NSGs) to the subnets beneath them.
+### Failback
 
-### Zone-down experience
+When the zone recovers, Microsoft initiates a failback process to ensure that virtual networks continue to work in the recovered zone. The failback process is automatic and doesn't require any action from you.
 
-Azure virtual networks are designed to be resilient to zone failures. When a zone becomes unavailable, Azure Virtual Network automatically reroutes traffic to the remaining zones. This process is seamless and doesn't require any action from you.
+However, you should verify the failback behaviors of any resources you deploy within the virtual network.
 
-* Any active requests are dropped and should be retried by the client.
+### Testing for zone failures
 
-* A zone failure isn't expected to cause any data loss.
+The Azure Virtual Network platform manages traffic routing, failover, and failback for virtual networks across availability zones. You don't need to initiate anything. Because this feature is fully managed, you don't need to validate availability zone failure processes.
 
-* A zone failure isn't expected to cause downtime to your resources.
+## Multi-region support
 
-### Failback
+Azure Virtual Network is a single-region service. If the region becomes unavailable, your virtual network is also unavailable.
 
-When the zone recovers, Microsoft initiates a failback process. The failback process is automatic and doesn't require any action from you.
+### Alternative multi-region approaches
 
-### Testing for zone failures 
+You can create virtual networks in multiple regions, and you can optionally *peer* them together to connect them.
 
-The Azure Virtual Network platform manages traffic routing, failover, and failback for the virtual network. You don't need to initiate anything. Because this feature is fully managed, you don't need to validate availability zone failure processes.
+By creating virtual networks and other resources in multiple regions, you can be resilient to regional outages. However, you need to consider many factors, including:
 
-## Multi-region support
+- **Traffic routing:** If you host internet-facing services in the virtual network, you need to decide how to route incoming traffic among your regions and components. Services like Azure Traffic Manager and Azure Front Door enable you to route internet traffic based on rules you specify.
 
-Azure Virtual Network is a single-region service. You can create virtual networks in multiple regions, but they are separate resources.
+- **Failover:** If an Azure region is unavailable, you typically need to *fail over* by processing traffic in healthy regions. Azure Traffic Manager and Azure Front Door provide failover capabilities for internet applications.      
 
-### Region-down experience 
- 
-The virtual network and the resources in the affected region remains inaccessible during the time of the service disruption.
+- **Management:** Each virtual network is a separate resource and needs to be configured and managed independently from other virtual networks.
 
-### Alternative multi-region approaches 
+- **IP address space:** You need to decide how to allocate IP addresses when you create multiple virtual networks. You can create multiple virtual networks using the same private IP address space in different regions. However, you can't peer (connect) two virtual networks with the same address space to your on-premises network, as it would cause routing issues. If you plan to create a multi-network design, IP address planning is an important consideration.
 
-You can create two virtual networks using the same private IP address space and resources in two different regions ahead of time. If you're hosting internet-facing services in the virtual network, you could have set up Traffic Manager to geo-route traffic to the region that is active. However, you can't connect two virtual networks with the same address space to your on-premises network, as it would cause routing issues. At the time of a disaster and loss of a virtual network in one region, you can connect the other virtual network in the available region, with the matching address space to your on-premises network.
+Virtual networks are fairly lightweight resources. You can invoke Azure APIs to create a virtual network with the same address space in a different region. However, to recreate the same environment that was present in the affected region, you must redeploy the virtual machines and other resources. If you have on-premises connectivity, such as in a hybrid deployment, you have to deploy a new VPN Gateway, and connect to your on-premises network.
 
-Virtual networks are fairly lightweight resources. You can invoke Azure APIs to create a virtual network with the same address space in a different region. To recreate the same environment that was present in the affected region, redeploy the virtual machines and other resources. If you have on-premises connectivity, such as in a hybrid deployment, you have to deploy a new VPN Gateway, and connect to your on-premises network.
+For an example of a multi-region networking architecture for web applications, see [Multi-region load balancing with Traffic Manager, Azure Firewall, and Application Gateway](/azure/architecture/high-availability/reference-architecture-traffic-manager-application-gateway).
 
 ## Service-level agreement
 
-There isn't a defined SLA for Azure Virtual Network due to the nature of the service. However, the SLA for the resources that are deployed in a virtual network is defined in the SLA for that resource.
+There isn't a defined SLA for Azure Virtual Network due to the nature of the service.
 
 ## Related content
 
-[What are availability zones?](/azure/reliability/availability-zones-overview)
+[What are availability zones?](/azure/reliability/availability-zones-overview)