Merge pull request #6008 from MicrosoftDocs/main

11/21/2024 AM Publish

docs/ready/azure-best-practices/connectivity-to-other-providers-oci.md

@@ -26,7 +26,7 @@ This section provides different connectivity approaches to integrate an Azure la
 
 - While you can use [ExpressRoute Global Reach](/azure/expressroute/expressroute-global-reach) to enable communication from on-premises to OCI via ExpressRoute circuits, it might incur more bandwidth costs that you can calculate by using the [Azure pricing calculator](https://azure.microsoft.com/pricing/calculator/). It's important to consider any extra costs when you migrate large amounts of data from on-premises to Oracle by using ExpressRoute circuits.
 
-- In Azure regions that support [Availability Zones](/azure/availability-zones/az-overview#availability-zones), placing your Azure workloads in one zone or the other can have a small effect on latency. Design your application to balance availability and performances requirements.
+- In Azure regions that support [availability zones](/azure/reliability/availability-zones-overview), placing your Azure workloads in one zone or the other can have a small effect on latency. Design your application to balance availability and performances requirements.
 
 - Interconnectivity between Azure and OCI is only available for [specific regions](/azure/virtual-machines/workloads/oracle/oracle-oci-overview#region-availability).
 

docs/ready/azure-setup-guide/regions.md

@@ -19,7 +19,7 @@ To learn more about how Azure regions work, see [What are Azure regions and avai
 
 ### Availability zones
 
-Many Azure regions include availability zones, which are physically separate locations within a region. By using availability zones, you can achieve higher availability and resilience in your deployments. For more information about availability zones, and for a list of Azure regions and services that support availability zones, see [Availability zone service and regional support](/azure/reliability/availability-zones-service-support).
+Many Azure regions include availability zones, which are physically separate locations within a region. By using availability zones, you can achieve higher availability and resilience in your deployments. For more information about availability zones, see [Availability zone service support](/azure/reliability/availability-zones-service-support) and [Availability zone region support](/azure/reliability/availability-zones-region-support).
 
 ### Paired regions
 
@@ -162,7 +162,7 @@ Newer Azure regions have no regional pair. They achieve high availability by usi
 
 When you use these regions, you can use locally redundant storage (LRS) or zone-redundant storage (ZRS). Regions without a pair don't support GRS. Services like Backup that have a dependency on Storage might also require that you use ZRS or LRS storage. When possible, it's a good practice to use ZRS to improve your resiliency within your region.
 
-To prepare for the rare event that an entire Azure region is unavailable, you need to plan for cross-region disaster recovery. At a minimum, it's a good practice to deploy your infrastructure by using automation approaches, and to back up your data across regions. If a full-region outage occurs, you can manually redeploy your resources and restore your backups. For some scenarios, you might need to consider other alternatives to reduce your potential recovery time and data loss. For more information, see [Availability zone service and regional support](/azure/reliability/availability-zones-service-support#azure-services-with-availability-zone-support) and [Azure Resiliency – Business Continuity and Disaster Recovery](https://azure.microsoft.com/mediahandler/files/resourcefiles/resilience-in-azure-whitepaper/resiliency-whitepaper-2022.pdf).
+To prepare for the rare event that an entire Azure region is unavailable, you need to plan for cross-region disaster recovery. At a minimum, it's a good practice to deploy your infrastructure by using automation approaches, and to back up your data across regions. If a full-region outage occurs, you can manually redeploy your resources and restore your backups. For some scenarios, you might need to consider other alternatives to reduce your potential recovery time and data loss. For more information, see [Availability zone service support](/azure/reliability/availability-zones-service-support), [Availability zone region support](/azure/reliability/availability-zones-region-support), and [Azure Resiliency – Business Continuity and Disaster Recovery](https://azure.microsoft.com/mediahandler/files/resourcefiles/resilience-in-azure-whitepaper/resiliency-whitepaper-2022.pdf).
 
 Consider your data resiliency needs. Regardless of where your data is located, you can move, copy, or access your data from any location globally.
 

docs/ready/considerations/regions.md

@@ -55,7 +55,7 @@ You should consider a multi-region strategy, either from the start of your cloud
 | Identity | If you deployed Active Directory Domain Services or Microsoft Entra Domain Services into your *Identity* subscription or spoke, expand the service into the new Azure region. |
 
 > [!NOTE]
-> You should also use [availability zones](/azure/reliability/availability-zones-overview) for high availability within a region. Check whether your regions and services support [availability zones](/azure/reliability/availability-zones-service-support).
+> You should also use [availability zones](/azure/reliability/availability-zones-overview) for high availability within a region. Check whether your [Azure regions support availability zones](/azure/reliability/availability-zones-region-support), and [how the services you use support availability zones](/azure/reliability/availability-zones-service-support).
 
 Microsoft Cloud for Sovereignty has guidelines for restricting services and regions. You can use these guidelines to enforce service configuration to help customers achieve their [data residency](/industry/sovereignty/data-residency) needs.
 

docs/ready/landing-zone/design-area/identity-access-active-directory-hybrid-identity.md

@@ -80,7 +80,7 @@ To implement Microsoft directory services, familiarize administrators with the f
 
 - [Domain Services](/entra/identity/domain-services/overview) is an Azure-managed service that you can use to create a new managed Active Directory domain that's hosted in Azure. The domain can have a trust relationship with existing domains and can synchronize identities from Microsoft Entra ID. Administrators don't have direct access to the domain controllers and aren't responsible for patching and other maintenance operations.
 
-- When you deploy Domain Services or integrate on-premises environments into Azure, use locations with [availability zones](/azure/availability-zones/az-overview) for increased availability when possible. Also consider deploying across multiple Azure regions for increased resiliency.
+- When you deploy Domain Services or integrate on-premises environments into Azure, use [regions with availability zones](/azure/reliability/availability-zones-region-support) for increased availability when possible. Also consider deploying across multiple Azure regions for increased resiliency.
 
 After you configure AD DS or Domain Services, you can use the same method as on-premises computers to domain join Azure VMs and file shares. For more information, see [Compare Microsoft directory-based services](/entra/identity/domain-services/compare-identity-solutions).
 

docs/relocate/evaluate.md

@@ -102,7 +102,7 @@ If automated discovery approaches aren't enough, you can conduct a manual assess
 
 Not every region in Azure offers the same services, so you must make sure the services your workload needs to run are available in the target region. It might seem late in the process to make this determination, but you need the discovery details to ensure supportability. To determine region supportability for your workload, see the [products and services available in each Azure region](https://azure.microsoft.com/explore/global-infrastructure/products-by-region).
 
-Know if the target region is a paired region or not and if it supports availability zones. Region pairing and availability zones don't affect the relocation effort, but they do affect your business continuity and disaster recovery (BCDR) strategy in the target region. For more information, see [Azure geographies](https://azure.microsoft.com/explore/global-infrastructure/geographies/#geographies) and [Availability zones](/azure/reliability/availability-zones-service-support#azure-regions-with-availability-zone-support).
+Know if the target region is a paired region or not and if it supports availability zones. Region pairing and availability zones don't affect the relocation effort, but they do affect your business continuity and disaster recovery (BCDR) strategy in the target region. For more information, see [Azure geographies](https://azure.microsoft.com/explore/global-infrastructure/geographies/#geographies) and [Availability zones](/azure/reliability/availability-zones-overview).
 
 ## Categorize workload services
 

docs/scenarios/azure-virtual-desktop/eslz-business-continuity-and-disaster-recovery.md

@@ -58,7 +58,7 @@ For host pool VM resiliency, consider these factors:
    -  Standard HDD Managed Disks - 95%   
 - The default resiliency option for Azure Virtual Desktop host pool deployment is to use availability zones. 
 
-- Through [availability zones](/azure/availability-zones/az-overview), VMs in the host pool are distributed across different datacenters. VMs are still in the same region, and they have higher resiliency and a higher formal 99.99 percent high-availability [SLA](https://azure.microsoft.com/support/legal/sla/virtual-machines). Your capacity planning should include sufficient extra compute capacity to ensure that Azure Virtual Desktop continues to operate, even if a single availability zone is lost.
+- Through [availability zones](/azure/reliability/availability-zones-overview), VMs in the host pool are distributed across different datacenters. VMs are still in the same region, and they have higher resiliency and a higher formal 99.99 percent high-availability [SLA](https://azure.microsoft.com/support/legal/sla/virtual-machines). Your capacity planning should include sufficient extra compute capacity to ensure that Azure Virtual Desktop continues to operate, even if a single availability zone is lost.
 
 > [!TIP]
 >

docs/scenarios/azure-virtual-desktop/landing-zone-citrix/citrix-business-continuity-disaster-recovery.md

@@ -44,9 +44,9 @@ The following lists aren't inclusive. They contain key highlights. For more info
 
 | Azure feature or service| What is it? | Why is it important? |
 |----|----|----|
-| [Regions](/azure/availability-zones/az-overview) | A set of datacenters that's deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network. | Your [selection of an Azure region](https://azure.microsoft.com/global-infrastructure/geographies/) should be based on proximity to existing datacenters, users, or required back-end data. You also need to be aware of which services are available in the regions you choose. For Citrix deployments, organizations often start with a single region. However, you should consider using two or more regions in the long term for geographic redundancy in a BCDR strategy. |
+| [Regions](/azure/reliability/overview) | A set of datacenters that's deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network. | Your [selection of an Azure region](https://azure.microsoft.com/global-infrastructure/geographies/) should be based on proximity to existing datacenters, users, or required back-end data. You also need to be aware of which services are available in the regions you choose. For Citrix deployments, organizations often start with a single region. However, you should consider using two or more regions in the long term for geographic redundancy in a BCDR strategy. |
 | [Azure ExpressRoute](/azure/expressroute/expressroute-faqs) | An Azure service that you can use to create private connections between Microsoft datacenters and infrastructure that's on your premises or in a colocation facility. | ExpressRoute is an essential infrastructure component for bridging a Microsoft datacenter and your organization's datacenter or colocation facility. It's often a prerequisite for an enterprise-scale Citrix deployment. <br> ExpressRoute is a shared service. You should conduct bandwidth capacity planning to determine overall bandwidth needs for the enterprise. If you don't have enough available bandwidth, the user experience or access to key services in the datacenter can be affected. Additionally, Independent Computing Architecture (ICA) performance is affected if sessions cross ExpressRoute to get to the datacenter. |
- | [Availability zones](/azure/availability-zones/az-region) | Unique physical locations within a region. Each zone is made up of one or more datacenters that's equipped with independent power, cooling, and networking. | Availability zones provide a [high SLA](https://azure.microsoft.com/support/legal/sla/virtual-machines/v1_9). You should use them for all applicable Citrix infrastructure and [machine catalogs](https://docs.citrix.com/en-us/citrix-daas/install-configure/resource-location/azure-resource-manager.html#provision-machines-into-specified-availability-zones) to provide datacenter redundancy within a region. Not all regions support availability zones, so you should plan accordingly. To ensure that you create a resilient and zone-redundant solution from the start, take advantage of built-in [Azure initiatives](/azure/governance/policy/samples/built-in-initiatives#resilience). |
+ | [Availability zones](/azure/reliability/availability-zones-overview) | Unique physical locations within a region. Each zone is made up of one or more datacenters that's equipped with independent power, cooling, and networking. | Availability zones provide a [high SLA](https://azure.microsoft.com/support/legal/sla/virtual-machines/v1_9). You should use them for all applicable Citrix infrastructure and [machine catalogs](https://docs.citrix.com/en-us/citrix-daas/install-configure/resource-location/azure-resource-manager.html#provision-machines-into-specified-availability-zones) to provide datacenter redundancy within a region. Not all regions support availability zones, so you should plan accordingly. To ensure that you create a resilient and zone-redundant solution from the start, take advantage of built-in [Azure initiatives](/azure/governance/policy/samples/built-in-initiatives#resilience). |
 | [Availability sets](/azure/virtual-machines/availability-set-overview) | A set of VMs that are spread across several fault domains. A *fault domain* is a group of VMs that share a common power source and network switch.  | Availability sets provide a [high SLA](https://azure.microsoft.com/support/legal/sla/virtual-machines/v1_9). You should use them for Citrix infrastructure only if availability zones aren't available in the region. Availability sets only provide hardware redundancy (like hypervisor anti-affinity rules). Therefore, you should use a multiregion strategy to provide datacenter and geographic redundancy if your chosen regions don't have availability zones. |
 | [Managed disks](/azure/virtual-machines/managed-disks-overview) | Disks that are managed by Azure and automatically placed in different storage scale units to limit the effects of hardware failure. | You should use managed disks for all Citrix infrastructure and Virtual Delivery Agents (VDAs). We don't recommend the use of unmanaged disks. For information about SLAs for single-instance virtual machines, like a user's VDI or a published application server, see [SLA for Virtual Machines](https://azure.microsoft.com/support/legal/sla/virtual-machines/v1_9). <br> Each type of disk provides different performance and has different associated costs. We recommend Premium  for Citrix infrastructure machines. When determining the disk type for VDAs, factor in cost, performance, and availability needs.|
 | [Azure Backup](/azure/backup/backup-overview) | A service that provides cost-effective solutions for backing up your data and recovering it from the Azure cloud. | We recommend Azure Backup for Citrix infrastructure, master image VMs, and persistent desktops. |

docs/scenarios/azure-vmware/eslz-business-continuity-and-disaster-recovery.md

@@ -128,7 +128,7 @@ Whether you have an on-premises or Azure VMware Solution, you should consider va
 
 - Set up smoke tests or disaster recovery drills at least once a year to ensure recovery plans work as expected. The orchestration capabilities of the chosen disaster recovery tool determine the level of effort that's involved with running these drills.
 
-- Use [geopolitical regional pairs](/azure/availability-zones/cross-region-replication-azure) as the secondary disaster recovery environment. Some of the benefits of regional pairs are prioritized region recovery, sequential updates, physical isolation, and data residency.
+- Use [geopolitical regional pairs](/azure/reliability/cross-region-replication-azure) as the secondary disaster recovery environment. Some of the benefits of regional pairs are prioritized region recovery, sequential updates, physical isolation, and data residency.
 
 - Keep address spaces different to avoid overlapping IP addresses between the two sites. For example, you can use `192.168.0.0/16` for region 1 and `10.0.0.0/16` for region 2.
 

docs/scenarios/sap/eslz-business-continuity-and-disaster-recovery.md

@@ -211,7 +211,7 @@ Most organizations use both regions for operating SAP systems. Organizations tha
 
 When you choose a disaster recovery region, be sure to have ExpressRoute connectivity to that region. If you have multiple ExpressRoute circuits connecting to Azure, at least one of those circuits must connect to the primary Azure region. The others should connect to the disaster recovery region. This type of architecture connects you to the Azure network in a different geographic or geopolitical area and helps protect your connection if a catastrophe affects one of the Azure regions.
 
-Some organizations use a combination high availability and disaster recovery architecture, which groups high availability with disaster recovery in the same Azure region. But grouping high availability with disaster recovery isn't ideal. [Azure availability zones](/azure/availability-zones/az-overview) support this architecture. The distance between availability zones within one Azure region isn't as large as the distance between two Azure regions, so a natural disaster could jeopardize the application services in the region where it occurs. You also need to consider the latency between SAP application servers and database servers. According to [SAP note 1100926](https://launchpad.support.sap.com/#/notes/1100926), a roundtrip time of less than or equal to 0.3 ms is a good value, and a time of less than or equal to 0.7 ms is a moderate value. So for zones with high latencies, have operational procedures to ensure that SAP application servers and database servers always run in the same zone. Organizations choose this architecture for the following reasons:
+Some organizations use a combination high availability and disaster recovery architecture, which groups high availability with disaster recovery in the same Azure region. But grouping high availability with disaster recovery isn't ideal. [Azure availability zones](/azure/reliability/availability-zones-overview) support this architecture. The distance between availability zones within one Azure region isn't as large as the distance between two Azure regions, so a natural disaster could jeopardize the application services in the region where it occurs. You also need to consider the latency between SAP application servers and database servers. According to [SAP note 1100926](https://launchpad.support.sap.com/#/notes/1100926), a roundtrip time of less than or equal to 0.3 ms is a good value, and a time of less than or equal to 0.7 ms is a moderate value. So for zones with high latencies, have operational procedures to ensure that SAP application servers and database servers always run in the same zone. Organizations choose this architecture for the following reasons:
 
 - Compliance is sufficient with configurations that support smaller distances between production deployment and a disaster recovery target.