@@ -217,8 +217,8 @@
         },
         {
             "source_path_from_root": "/articles/search/search-performance-optimization.md",
-            "redirect_url": "/azure/search/search-reliability",
-            "redirect_document_id": true
+            "redirect_url": "/azure/reliability/reliability-ai-search",
+            "redirect_document_id": false
         },
         {
             "source_path_from_root": "/articles/search/cognitive-search-quickstart-ocr.md",
@@ -455,6 +455,11 @@
             "source_path_from_root": "/articles/search/search-get-started-powershell.md",
             "redirect_url": "/azure/search/search-get-started-text",
             "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/search/search-reliability.md",
+            "redirect_url": "/azure/reliability/reliability-ai-search",
+            "redirect_document_id": false
         }
     ]
   }
\ No newline at end of file

@@ -1,15 +1,17 @@
+items:
 - name: Azure
   tocHref: /azure/
   topicHref: /azure/index
   items:
+  - name: Search
+    tocHref: /azure/reliability
   - name: AI services
     tocHref: /azure/ai-services/
     topicHref: /azure/ai-services/index
     items:
     - name: Azure AI Search
       tocHref: /azure/search/
       topicHref: /azure/search/index
-
 - name: Azure
   tocHref: /legal/
   topicHref: /azure/index

@@ -185,7 +185,7 @@ from azure.search.documents import SearchClient
 from azure.identity import DefaultAzureCredential, AzureAuthorityHosts
 
 # Azure Public Cloud
-audience = "https://search.windows.net"
+audience = "[https://search.windows.net](https://search.azure.com)"
 authority = AzureAuthorityHosts.AZURE_PUBLIC_CLOUD
 
 service_endpoint = os.environ["AZURE_SEARCH_ENDPOINT"]

@@ -8,7 +8,7 @@ ms.author: haileytapia
 ms.service: azure-ai-search
 ms.update-cycle: 180-days
 ms.topic: how-to
-ms.date: 08/01/2025
+ms.date: 08/08/2025
 ms.custom:
   - references_regions
   - build-2024
@@ -115,7 +115,7 @@ In most cases, choose a region near you, unless any of the following apply:
 
 1. Do you have a specific tier in mind? Check [region availability by tier](search-sku-tier.md#region-availability-by-tier).
 
-1. Do you have business continuity and disaster recovery (BCDR) requirements? Create two or more search services in [regional pairs](/azure/reliability/cross-region-replication-azure#azure-paired-regions) within [availability zones](search-reliability.md#availability-zones). For example, if you're operating in North America, you might choose East US and West US, or North Central US and South Central US, for each search service.
+1. Do you have business continuity and disaster recovery (BCDR) requirements? Create two or more search services in [regional pairs](/azure/reliability/cross-region-replication-azure#azure-paired-regions), each with two or more replicas for [availability zones](/azure/reliability/reliability-ai-search#availability-zone-support). For example, if you're operating in North America, you might choose East US and West US, or North Central US and South Central US, for each search service.
 
 1. Do you need [AI enrichment](cognitive-search-concept-intro.md), [integrated data chunking and vectorization](vector-search-integrated-vectorization.md), or [multimodal search](multimodal-search-overview.md)? For [billing purposes](cognitive-search-attach-cognitive-services.md), Azure AI Search and Azure AI services multi-service must coexist in the same region.
 

@@ -8,7 +8,7 @@ ms.author: haileytapia
 ms.service: azure-ai-search
 ms.topic: how-to
 ms.custom: references_regions
-ms.date: 08/01/2025
+ms.date: 08/08/2025
 ---
 
 # Upgrade your Azure AI Search service in the Azure portal
@@ -76,7 +76,7 @@ The date you created your service partially determines its [upgrade eligibility]
 
 You can't undo a service upgrade. Before you proceed, make sure that you want to permanently increase the [storage limit](#higher-storage-limits) and [vector index size](#higher-vector-limits) of your search service. We recommend that you test this operation in a nonproduction environment.
 
-The availability of your search service during an upgrade depends on how many replicas you've provisioned. With two or more replicas, your service remains available while one replica is updated. For more information, see [Reliability in Azure AI Search](search-reliability.md).
+The availability of your search service during an upgrade depends on how many replicas you've provisioned. With two or more replicas, your service remains available while one replica is updated. For more information, see [Reliability in Azure AI Search](/azure/reliability/reliability-ai-search).
 
 To upgrade your service:
 

@@ -9,7 +9,7 @@ ms.service: azure-ai-search
 ms.custom:
   - ignite-2023
 ms.topic: conceptual
-ms.date: 04/18/2025
+ms.date: 06/23/2025
 ---
 
 # Indexers in Azure AI Search
@@ -32,7 +32,7 @@ You can use an indexer as the sole means for data ingestion, or in combination w
 |----------|---------|
 | Single data source | This pattern is the simplest: one data source is the sole content provider for a search index. Most supported data sources provide some form of change detection so that subsequent indexer runs pick up the difference when content is added or updated in the source. |
 | Multiple data sources | An indexer specification can have only one data source, but the search index itself can accept content from multiple sources, where each indexer job brings new content from a different data provider. Each source can contribute its share of full documents, or populate selected fields in each document. For a closer look at this scenario, see [Tutorial: Index from multiple data sources](tutorial-multiple-data-sources.md). |
-| Multiple indexers | Multiple data sources are typically paired with multiple indexers if you need to vary run time parameters, the schedule, or field mappings. </br></br>[Cross-region scale out of Azure AI Search](search-reliability.md#data-sync) is a variation of this scenario. You might have copies of the same search index in different regions. To synchronize search index content, you could have multiple indexers pulling from the same data source, where each indexer targets a different search index in each region.</br></br>[Parallel indexing](search-howto-large-index.md#parallel-indexing) of very large data sets also requires a multi-indexer strategy, where each indexer targets a subset of the data. |
+| Multiple indexers | Multiple data sources are typically paired with multiple indexers if you need to vary run time parameters, the schedule, or field mappings. </br></br>[Cross-region scale out of Azure AI Search](search-multi-region.md#data-synchronization) is a variation of this scenario. You might have copies of the same search index in different regions. To synchronize search index content, you could have multiple indexers pulling from the same data source, where each indexer targets a different search index in each region.</br></br>[Parallel indexing](search-howto-large-index.md#parallel-indexing) of very large data sets also requires a multi-indexer strategy, where each indexer targets a subset of the data. |
 | Content transformation | Indexers drive [skillset execution and AI enrichment](cognitive-search-concept-intro.md). Content transforms are defined in a [skillset](cognitive-search-working-with-skillsets.md) that you attach to the indexer. You can use skills to [incorporate data chunking and vectorization](vector-search-integrated-vectorization.md).|
 
  You should plan on creating one indexer for every target index and data source combination. You can have multiple indexers writing into the same index, and you can reuse the same data source for multiple indexers. However, an indexer can only consume one data source at a time, and can only write to a single index. As the following graphic illustrates, one data source provides input to one indexer, which then populates a single index:  

@@ -0,0 +1,122 @@
+---
+title: Multi-Region Solutions in Azure AI Search
+titleSuffix: Azure AI Search
+description: Learn about multi-region deployments in Azure AI Search, including data synchronization and request failover.
+author: haileytap
+ms.author: haileytapia
+ms.service: azure-ai-search
+ms.topic: conceptual
+ms.date: 08/08/2025
+---
+
+# Multi-region deployments in Azure AI Search
+
+Although Azure AI Search is a single-region service, you can achieve higher availability and resiliency by deploying multiple search services with identical configurations and content across multiple regions.
+
+This article describes the components of a multi-region solution, which relies on your custom script or code to handle failover if a service becomes unavailable.
+
+For more information about the reliability features of Azure AI Search, including intra-regional resiliency via availability zones, see [Reliability in Azure AI Search](/azure/reliability/reliability-ai-search).
+
+## Why use multiple regions?
+
+If you need two or more search services, creating them in different regions can meet the following operational requirements:
+
++ **Resiliency to region outages**. If there's an outage, Azure AI Search doesn't provide instant failover to another region.
+
++ **Fast performance for a globally distributed application**. If indexing and query requests come from around the world, users who are closest to the host data center experience faster performance. Creating more services in regions with close proximity to these users can equalize performance for everyone.
+
+## Multi-region architecture
+
+In a multi-region setup, two or more search services are located in different regions and have synchronized indexes. Users are automatically routed to the service with the lowest latency.
+
+Azure AI Search doesn't provide an automated method of index replication across regions. However, you can synchronize data using [push or pull model indexing](search-what-is-data-import.md), both of which are described in the following section. You can also add Azure Traffic Manager or another load balancer for [request redirection](#request-failover-and-redirection).
+
+The following diagram illustrates a geo-distributed set of search services:
+
+:::image type="content" source="media/search-multi-region/geo-redundancy.png" alt-text="Diagram that shows a cross-tab view of services by region." border="true" lightbox="media/search-multi-region/geo-redundancy.png":::
+
+> [!TIP]
+> For a complete implementation, see the [Bicep sample](https://github.com/Azure-Samples/azure-search-multiple-regions) on GitHub. The sample deploys a fully configured, multi-region search solution that can be modified to your regions and indexing strategies.
+
+## Data synchronization
+
+To synchronize two or more distinct search services, you can either:
+
++ Push content into an index using [Documents - Index (REST API)](/rest/api/searchservice/documents/) or an equivalent API in the Azure SDKs.
++ Pull content into an index using an [indexer](search-indexer-overview.md).
+
+### [Push APIs](#tab/push-apis)
+
+If you use the REST APIs to [push content into your index](search-what-is-data-import.md#pushing-data-to-an-index), you can synchronize multiple search services by sending updates to each service whenever changes occur. Ensure that your code handles cases in which an update fails for one service but succeeds for other services.
+
+### [Pull APIs (Indexers)](#tab/pull-apis)
+
+If you have an indexer on one search service, you can create a second indexer on a second service to reference the same data source. Each service in each region has its own indexer and target index. Although the indexes are independent and store their own copies of the data, they remain synchronized because the indexers pull from the same source.
+
+The following diagram illustrates this architecture:
+
+:::image type="content" source="media/search-multi-region/scale-indexers.png" alt-text="Diagram of a single data source with distributed indexer and service combinations." border="true" lightbox="media/search-multi-region/scale-indexers.png":::
+
+---
+
+## Data residency
+
+When you create multiple search services in different regions, your content is stored in the region you chose for each service.
+
+Azure AI Search doesn't store data outside of your specified region without your authorization. Authorization is implicit when you use features that write to Azure Storage, for which you provide a storage account in your preferred region. These features include:
+
++ [Enrichment cache](cognitive-search-incremental-indexing-conceptual.md)
++ [Debug sessions](cognitive-search-debug-session.md)
++ [Knowledge store](knowledge-store-concept-intro.md)
+
+If your search service and storage account are in the same region, network traffic uses private IP addresses over the Microsoft backbone network, so you can't configure IP firewalls or private endpoints for network security. As an alternative, use the [trusted service exception](search-indexer-howto-access-trusted-service-exception.md).
+
+## Request failover and redirection
+
+For redundancy at the request level, Azure provides several [load-balancing options](/azure/architecture/guide/technology-choices/load-balancing-overview):
+
+### [Azure Application Gateway](#tab/application-gateway)
+
+Use [Azure Application Gateway](/azure/application-gateway/overview) to load balance between servers in a region at the application layer.
+
+By default, service endpoints are accessed through a public internet connection. Use Application Gateway if you set up a private endpoint for client connections that originate from within a virtual network.
+
+### [Azure Front Door](#tab/front-door)
+
+Use [Azure Front Door](/azure/frontdoor/front-door-overview) to optimize global routing of web traffic and provide global failover.
+
+### [Azure Load Balancer](#tab/load-balancer)
+
+Use [Azure Load Balancer](/azure/load-balancer/load-balancer-overview) to load balance between search services in a backend pool.
+
+To use [health probes](/azure/load-balancer/load-balancer-custom-probe-overview) on a search service, you must use an HTTPS probe with `/ping` as the path.
+
+### [Azure Traffic Manager](#tab/traffic-manager)
+
+Use [Azure Traffic Manager](/azure/traffic-manager/traffic-manager-overview) to route requests to multiple geo-located websites backed by multiple search services.
+
+Traffic Manager doesn't provide an endpoint for a direct connection to Azure AI Search. Instead, requests are assumed to flow from Traffic Manager to a search-enabled web client to a search service on the backend. In this scenario, the service and client are in the same region. If one service goes down, the client fails, and Traffic Manager redirects to the remaining client.
+
+The following diagram illustrates search apps connecting through Traffic Manager:
+
+:::image type="content" source="media/search-multi-region/azure-function-search-traffic-mgr.png" alt-text="Diagram of search apps connecting through Azure Traffic Manager." border="true" lightbox="media/search-multi-region/azure-function-search-traffic-mgr.png":::
+
+> [!TIP]
+> Azure AI Search provides a [multi-region Bicep sample](https://github.com/Azure-Samples/azure-search-multiple-regions) that uses Traffic Manager for request redirection when the primary endpoint fails. This solution is useful for routing to a search-enabled client that only calls a search service in the same region.
+
+---
+
+As you evaluate these load-balancing options, consider the following points:
+
++ Azure AI Search is a backend service that accepts indexing and query requests from a client.
+
++ By default, service endpoints are accessed through a public internet connection. We recommend [Azure Application Gateway](/azure/application-gateway/overview) for private endpoints that originate from within a virtual network.
+
++ Azure AI Search accepts requests addressed to the `<your-search-service-name>.search.windows.net` endpoint. If you reach the same endpoint using a different DNS name in the host header, such as a CNAME, the request is rejected.
+
++ Requests from the client to a search service must be authenticated. To access search operations, the caller must have [role-based permissions](search-security-rbac.md) or provide an [API key](search-security-api-keys.md) with the request.
+
+## Related content
+
++ [Reliability in Azure AI Search](/azure/reliability/reliability-ai-search)
++ [Design reliable Azure applications](/azure/architecture/framework/resiliency/app-design)

@@ -5,7 +5,7 @@ description: Shows supported regions and feature availability across regions for
 author: haileytap
 ms.author: haileytapia
 manager: nitinme
-ms.date: 07/31/2025
+ms.date: 08/08/2025
 ms.service: azure-ai-search
 ms.update-cycle: 90-days
 ms.topic: conceptual
@@ -25,7 +25,7 @@ When you create an Azure AI Search service, your region selection might depend o
 | Feature | Description | Availability |
 |---------|-------------|--------------|
 | [AI enrichment](cognitive-search-concept-intro.md) | Refers to [built-in skills](cognitive-search-predefined-skills.md) that make internal calls to Azure AI for enrichment and transformation during indexing. Integration requires that Azure AI Search coexists with an [Azure AI services multi-service account](/azure/ai-services/multi-service-resource#azure-ai-services-resource-for-azure-ai-search-skills) in the same physical region. You can bypass region requirements by using [identity-based connections](cognitive-search-attach-cognitive-services.md#bill-through-a-keyless-connection), currently in public preview. | Regional support is noted in this article. |
-| [Availability zones](search-reliability.md#availability-zone-support) | Divides a region's data centers into distinct physical location groups, providing high availability within the same geo. | Regional support is noted in this article. |
+| [Availability zones](/azure/reliability/reliability-ai-search#availability-zone-support) | Divides a region's data centers into distinct physical location groups, providing high availability within the same geo. | Regional support is noted in this article. |
 | [Agentic retrieval](search-agentic-retrieval-concept.md) | Takes a dependency on semantic ranker, which is another premium feature. | Regional support is noted in this article. |
 | [Semantic ranker](semantic-search-overview.md) | Takes a dependency on Microsoft-hosted models in specific regions. | Regional support is noted in this article. |
 | [Query rewrite](semantic-how-to-query-rewrite.md) | Takes a dependency on Microsoft-hosted models in specific regions. | Regional support is noted in this article. |

@@ -1,205 +0,0 @@
----
-title: Reliability in Azure AI Search
-titleSuffix: Azure AI Search
-description: Learn how to improve the reliability and availability of Azure AI Search services.
-author: haileytap
-ms.author: haileytapia
-ms.service: azure-ai-search
-ms.topic: conceptual
-ms.date: 04/14/2025
-ms.custom:
-  - subject-reliability
-  - references_regions
-  - ignite-2023
----
-
-# Reliability in Azure AI Search
-
-Across Azure, [reliability](/azure/reliability/overview) means resiliency and availability if there's a service outage or degradation. In Azure AI Search, reliability can be achieved within a single service or through multiple search services in separate regions.
-
-+ Deploy a single search service and scale up for high availability. You can add multiple replicas to handle higher indexing and query workloads. If your search service [supports availability zones](#availability-zone-support), replicas are automatically provisioned in different physical data centers for extra resiliency.
-
-+ Deploy multiple search services across different geographic regions. All search workloads are fully contained within a single service that runs in a single geographic region, but in a multi-service scenario, you have options for synchronizing content so that it's the same across all services. You can also set up a load balancing solution to redistribute requests or fail over if there's a service outage.
-
-For business continuity and recovery from disasters at a regional level, plan on a cross-regional topology, consisting of multiple search services having identical configuration and content. Your custom script or code provides the *failover* mechanism to an alternate search service if one suddenly becomes unavailable.
-
-<a name="scale-for-availability"></a>
-
-## High availability
-
-In Azure AI Search, replicas are copies of your index. A search service is commissioned with at least one replica, and can have up to 12 replicas. [Adding replicas](search-capacity-planning.md#add-or-remove-partitions-and-replicas) allows Azure AI Search to do machine reboots and maintenance against one replica, while query execution continues on other replicas.
-
-For each individual search service, Microsoft guarantees at least 99.9% availability for configurations that meet these criteria:
-
-+ Two replicas for high availability of *read-only* workloads (queries)
-
-+ Three or more replicas for high availability of *read-write* workloads (queries and indexing) 
-
-The system has internal mechanisms for monitoring replica health and partition integrity. If you provision a specific combination of replicas and partitions, the system ensures that level of capacity for your service.
-
-No Service Level Agreement (SLA) is provided for the *Free* tier. For more information, see the [SLA for Azure AI Search](https://azure.microsoft.com/support/legal/sla/search/v1_0/).
-
-<a name="availability-zones"></a>
-
-## Availability zone support
-
-[Availability zones](/azure/reliability/availability-zones-overview) are an Azure platform capability that divides a region's data centers into distinct physical location groups to provide high availability, within the same region. In Azure AI Search, individual replicas are the units for zone assignment. A search service runs within one region; its replicas run in different physical data centers (or zones) within that region.
-
-Availability zones are used when you add two or more replicas to your search service. Each replica is placed in a different availability zone within the region. If you have more replicas than available zones in the search service region, the replicas are distributed across zones as evenly as possible. There's no specific action on your part, except to [create a search service](search-create-service-portal.md) in a region that provides availability zones, and then to configure the service to [use multiple replicas](search-capacity-planning.md#add-or-remove-partitions-and-replicas).
-
-### Prerequisites
-
-+ Service tier must be *Standard* or higher
-+ Service region must be in a region that has available zones (listed in the following section)
-+ Configuration must include multiple replicas: two for read-only query workloads, three for read-write workloads that include indexing
-
-### Supported regions
-
-Support for availability zones depends on infrastructure and storage. Currently, the following zone has insufficient storage and doesn't provide an availability zone for Azure AI Search:
-
-+ Japan West
-
-Otherwise, availability zones for Azure AI Search are supported in the following regions:
-
-| Region | Roll out date |
-|--------|-----------|
-| Australia East | January 30, 2021 or later |
-| Brazil South |  May 2, 2021 or later |
-| Canada Central | January 30, 2021 or later |
-| Central India | January 20, 2022 or later |
-| Central US | December 4, 2020 or later |
-| China North 3 | September 7, 2022 or later |
-| East Asia | January 13, 2022 or later |
-| East US | January 27, 2021 or later |
-| East US 2 | January 30, 2021 or later |
-| France Central| October 23, 2020 or later |
-| Germany West Central |  May 3, 2021, or later |
-| Israel Central | April 1, 2024, or later |
-| Italy North | April 1, 2024, or later |
-| Japan East | January 30, 2021 or later |
-| Korea Central | January 20, 2022 or later |
-| North Europe | January 28, 2021 or later |
-| Norway East | January 20, 2022 or later |
-| Qatar Central | August 25, 2022 or later |
-| South Africa North | September 7, 2022 or later |
-| South Central US | April 30, 2021 or later |
-| South East Asia | January 31, 2021 or later |
-| Sweden Central | January 21, 2022 or later |
-| Switzerland North | September 7, 2022 or later |
-| UAE North | September 9, 2022 or later |
-| UK South | January 30, 2021 or later |
-| US Gov Virginia | April 30, 2021 or later |
-| West Europe | January 29, 2021 or later |
-| West US 2 | January 30, 2021 or later |
-| West US 3 | June 02, 2021 or later |
-
-> [!NOTE]
-> Availability zones don't change the terms of the [SLA](https://azure.microsoft.com/support/legal/sla/search/v1_0/). You still need three or more replicas for query high availability.
-
-## Multiple services in separate geographic regions
-
-Service redundancy is necessary if your operational requirements include:
-
-+ [Business continuity and disaster recovery (BCDR) requirements](/azure/reliability/disaster-recovery-overview). Azure AI Search doesn't provide instant failover if there's an outage.
-
-+ Fast performance for a globally distributed application. If query and indexing requests come from all over the world, users who are closest to the host data center experience faster performance. Creating more services in regions with close proximity to these users can equalize performance for all users.
-
-If you need two or more search services, creating them in different regions can meet application requirements for continuity and recovery, and faster response times for a global user base.
-
-Azure AI Search doesn't provide an automated method of replicating search indexes across geographic regions, but there are some techniques that can make this process simple to implement and manage. These techniques are outlined in the next few sections.
-
-The goal of a geo-distributed set of search services is to have two or more indexes available in two or more regions, where a user is routed to the Azure AI Search service that provides the lowest latency:
-
-   ![Diagram showing cross-tab view of services by region.][1]
-
-You can implement this architecture by creating multiple services and designing a strategy for data synchronization. Optionally, you can include a resource like Azure Traffic Manager for routing requests. 
-
-> [!TIP]
-> For help with deploying multiple search services across multiple regions, see this [Bicep sample on GitHub](https://github.com/Azure-Samples/azure-search-multiple-regions) that deploys a fully configured, multi-regional search solution. The sample gives you two options for index synchronization, and request redirection using Traffic Manager.
-
-<a name="data-sync"></a>
-
-### Synchronize data across multiple services
-
-There are two options for keeping two or more distinct search services in sync:
-
-+ Pull content updates into a search index by using an [indexer](search-indexer-overview.md).
-+ Push content into an index using the [Add or Update Documents (REST)](/rest/api/searchservice/documents) API or an Azure SDK equivalent API.
-
-To configure either option, we recommend using the [sample Bicep script in the azure-search-multiple-region](https://github.com/Azure-Samples/azure-search-multiple-regions) repository, modified to your regions and indexing strategies.
-
-#### Option 1: Use indexers for updating content on multiple services
-
-If you're already using indexer on one service, you can configure a second indexer on a second service to use the same data source object, pulling data from the same location. Each service in each region has its own indexer and a target index (your search index isn't shared, which means each index has its own copy of the data), but each indexer references the same data source.
-
-Here's a high-level visual of what that architecture would look like.
-
-![Diagram showing a single data source with distributed indexer and service combinations.][2]
-
-#### Option 2: Use REST APIs for pushing content updates on multiple services
-
-If you're using the Azure AI Search REST API to [push content to your search index](tutorial-optimize-indexing-push-api.md), you can keep your various search services in sync by pushing changes to all search services whenever an update is required. In your code, make sure to handle cases where an update to one search service fails but succeeds for other search services.
-
-### Fail over or redirect query requests
-
-If you need redundancy at the request level, Azure provides several [load balancing options](/azure/architecture/guide/technology-choices/load-balancing-overview):
-
-+ [Azure Traffic Manager](/azure/traffic-manager/traffic-manager-overview), used to route requests to multiple geo-located websites that are then backed by multiple search services. 
-+ [Application Gateway](/azure/application-gateway/overview), used to load balance between servers in a region at the application layer.
-+ [Azure Front Door](/azure/frontdoor/front-door-overview), used to optimize global routing of web traffic and provide global failover.
-+ [Azure Load Balancer](/azure/load-balancer/load-balancer-overview), used to load balance between services in a backend pool.
-
-Some points to keep in mind when evaluating load balancing options:
-
-+ Search is a backend service that accepts query and indexing requests from a client. 
-
-+ Requests from the client to a search service must be authenticated. For access to search operations, the caller must have role-based permissions or provide an API key on the request.
-
-+ Service endpoints are reached through a public internet connection by default. If you set up a private endpoint for client connections that originate from within a virtual network, use [Application Gateway](/azure/application-gateway/overview).
-
-+ Azure AI Search accepts requests addressed to the `<your-search-service-name>.search.windows.net` endpoint. If you reach the same endpoint using a different DNS name in the host header, such as a CNAME, the request is rejected.
-
-Azure AI Search provides a [multi-region deployment sample](https://github.com/Azure-Samples/azure-search-multiple-regions) that uses Azure Traffic Manager for request redirection if the primary endpoint fails. This solution is useful when you route to a search-enabled client that only calls a search service in the same region.
-
-Azure Traffic Manager is primarily used for routing network traffic across different endpoints based on specific routing methods (such as priority, performance, or geographic location). It acts at the DNS level to direct incoming requests to the appropriate endpoint. If an endpoint that Traffic Manager is servicing begins refusing requests, traffic is routed to another endpoint.
-
-Traffic Manager doesn't provide an endpoint for a direct connection to Azure AI Search, which means you can't put a search service directly behind Traffic Manager. Instead, the assumption is that requests flow to Traffic Manager, then to a search-enabled web client, and finally to a search service on the backend. The client and service are located in the same region. If one search service goes down, the search client starts failing, and Traffic Manager redirects to the remaining client.
-
-> [!NOTE]
-> If you are using Azure Load Balancer [health probes](/azure/load-balancer/load-balancer-custom-probe-overview) on a search service, you must use an HTTPS probe with `/ping` as the path.
-
-![Diagram of search apps connecting through Azure Traffic Manager.][4]
-
-## Data residency in a multi-region deployment
-
-When you deploy multiple search services in various geographic regions, your content is stored in the region you chose for each search service.
-
-Azure AI Search doesn't store data outside of your specified region without your authorization. Authorization is implicit when you use features that write to an Azure Storage resource: [enrichment cache](enrichment-cache-how-to-configure.md), [debug session](cognitive-search-debug-session.md), [knowledge store](knowledge-store-concept-intro.md). In all cases, the storage account is one that you provide, in the region of your choice. 
-
-> [!NOTE]
-> If both the storage account and the search service are in the same region, network traffic between search and storage uses a private IP address and occurs over the Microsoft backbone network. Because private IP addresses are used, you can't configure IP firewalls or a private endpoint for network security. Instead, use the [trusted service exception](search-indexer-howto-access-trusted-service-exception.md) as an alternative when both services are in the same region. 
-
-## About service outages and catastrophic events
-
-As stated in the [SLA](https://azure.microsoft.com/support/legal/sla/search/v1_0/), Microsoft guarantees a high level of availability for index query requests when an Azure AI Search service instance is configured with two or more replicas, and index update requests when an Azure AI Search service instance is configured with three or more replicas. However, there's no built-in mechanism for disaster recovery. If continuous service is required in the event of a catastrophic failure outside of Microsoft’s control, we recommend provisioning a second service in a different region and implementing a geo-replication strategy to ensure indexes are fully redundant across all services.
-
-Customers who use [indexers](search-indexer-overview.md) to populate and refresh indexes can handle disaster recovery through geo-specific indexers that retrieve data from the same data source. Two services in different regions, each running an indexer, could index the same data source to achieve geo-redundancy. If you're indexing from data sources that are also geo-redundant, remember that Azure AI Search indexers can only perform incremental indexing (merging updates from new, modified, or deleted documents) from primary replicas. In a failover event, be sure to redirect the indexer to the new primary replica. 
-
-If you don't use indexers, you would use your application code to push objects and data to different search services in parallel. For more information, see [Synchronize data across multiple services](#data-sync).
-
-## Back up and restore alternatives
-
-A business continuity strategy for the data layer usually includes a restore-from-backup step. Because Azure AI Search isn't a primary data storage solution, Microsoft doesn't provide a formal mechanism for self-service backup and restore. However, you can use the **index-backup-restore** sample code in this [Azure AI Search .NET sample repo](https://github.com/Azure-Samples/azure-search-dotnet-utilities)  or in this [Python sample repository](https://github.com/Azure/azure-search-vector-samples/blob/main/demo-python/code/utilities/index-backup-restore/azure-search-backup-and-restore.ipynb) to back up your index definition and snapshot to a series of JSON files, and then use these files to restore the index, if needed. This tool can also move indexes between service tiers.
-
-Otherwise, your application code used for creating and populating an index is the de facto restore option if you delete an index by mistake. To rebuild an index, you would delete it (assuming it exists), recreate the index in the service, and reload by retrieving data from your primary data store.
-
-## Related content
-
-+ Review [Service limits](search-limits-quotas-capacity.md) to learn more about the pricing tiers and service limits.
-+ Review [Plan for capacity](search-capacity-planning.md) to learn more about partition and replica combinations.
-+ Review [Case Study: Use Cognitive Search to Support Complex AI Scenarios](https://techcommunity.microsoft.com/t5/azure-ai/case-study-effectively-using-cognitive-search-to-support-complex/ba-p/2804078) for more configuration guidance.
-
-<!--Image references-->
-[1]: ./media/search-reliability/geo-redundancy.png
-[2]: ./media/search-reliability/scale-indexers.png
-[4]: ./media/search-reliability/azure-function-search-traffic-mgr.png

@@ -7,7 +7,7 @@ author: haileytap
 ms.author: haileytapia
 ms.service: azure-ai-search
 ms.topic: conceptual
-ms.date: 08/01/2025
+ms.date: 08/08/2025
 ---
 
 # Choose a service tier for Azure AI Search
@@ -69,7 +69,7 @@ Most features are available on all tiers, including the Free tier. In a few case
 | [Customer-managed encryption keys](search-security-manage-encryption-keys.md) | Not available on the Free tier. |
 | [IP firewall access](service-configure-firewall.md) | Not available on the Free tier. |
 | [Private endpoint (integration with Azure Private Link)](service-create-private-endpoint.md) | For inbound connections to a search service, not available on the Free tier. <br>For outbound connections by indexers to other Azure resources, not available on Free or S3 HD. <br>For indexers that use skillsets, not available on Free, Basic, S1, or S3 HD.|
-| [Availability Zones](search-reliability.md) | Not available on the Free or Basic tier. |
+| [Availability zones](/azure/reliability/reliability-ai-search#availability-zone-support) | Not available on the Free tier. |
 | [Semantic ranker](semantic-search-overview.md) | Not available on the Free tier. |
 
 Resource-intensive features might not work well unless you give it sufficient capacity. For example, [AI enrichment](cognitive-search-concept-intro.md) has long-running skills that time out on a Free service unless the dataset is small.
@@ -80,7 +80,7 @@ Tiers determine the  maximum storage of the service itself, plus the maximum num
 
 ## Partition size and speed
 
-Tier pricing includes details about per-partition storage that ranges from 15 GB for Basic, up to 2 TB for Storage Optimized (L2) tiers. Other hardware characteristics, such as speed of operations, latency, and transfer rates, aren't published, but tiers that are designed for specific solution architectures are built on hardware that has the features to support those scenarios. For more information about partitions, see [Estimate and manage capacity](search-capacity-planning.md) and [Reliability in Azure AI Search](search-reliability.md).
+Tier pricing includes details about per-partition storage that ranges from 15 GB for Basic, up to 2 TB for Storage Optimized (L2) tiers. Other hardware characteristics, such as speed of operations, latency, and transfer rates, aren't published, but tiers that are designed for specific solution architectures are built on hardware that has the features to support those scenarios. For more information about partitions, see [Estimate and manage capacity](search-capacity-planning.md) and [Reliability in Azure AI Search](/azure/reliability/reliability-ai-search).
 
 > [!NOTE]
 > Higher-capacity partitions became available in select regions in April 2024. A second wave of higher-capacity partitions was released in May 2024. If you have an older search service, you might be able to [upgrade your service](search-how-to-upgrade.md) to benefit from more capacity at the same billing rate.

@@ -52,6 +52,12 @@ items:
       href: search-query-overview.md
   - name: Relevance
     href: search-relevance-overview.md
+  - name: Reliability
+    items:
+      - name: Reliability in Azure AI Search
+        href: /azure/reliability/reliability-ai-search?toc=/azure/search/toc.json&bc=/azure/search/breadcrumb/toc.json
+      - name: Multi-region deployment
+        href: search-multi-region.md
   - name: Security
     href: search-security-overview.md
 - name: Quickstarts
@@ -188,8 +194,6 @@ items:
       href: search-capacity-planning.md
     - name: Plan and manage costs
       href: search-sku-manage-costs.md
-    - name: Reliability and recovery
-      href: search-reliability.md
     - name: Multi-tenancy
       href: search-modeling-multitenant-saas-applications.md
     - name: Manage