|
| 1 | +--- |
| 2 | +title: Multi-Region Solutions in Azure AI Search |
| 3 | +titleSuffix: Azure AI Search |
| 4 | +description: Learn about multi-region deployments in Azure AI Search, including data synchronization and request failover. |
| 5 | +author: haileytap |
| 6 | +ms.author: haileytapia |
| 7 | +ms.service: azure-ai-search |
| 8 | +ms.topic: conceptual |
| 9 | +ms.date: 08/08/2025 |
| 10 | +--- |
| 11 | + |
| 12 | +# Multi-region deployments in Azure AI Search |
| 13 | + |
| 14 | +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. |
| 15 | + |
| 16 | +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. |
| 17 | + |
| 18 | +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). |
| 19 | + |
| 20 | +## Why use multiple regions? |
| 21 | + |
| 22 | +If you need two or more search services, creating them in different regions can meet the following operational requirements: |
| 23 | + |
| 24 | ++ **Resiliency to region outages**. If there's an outage, Azure AI Search doesn't provide instant failover to another region. |
| 25 | + |
| 26 | ++ **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. |
| 27 | + |
| 28 | +## Multi-region architecture |
| 29 | + |
| 30 | +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. |
| 31 | + |
| 32 | +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). |
| 33 | + |
| 34 | +The following diagram illustrates a geo-distributed set of search services: |
| 35 | + |
| 36 | +:::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"::: |
| 37 | + |
| 38 | +> [!TIP] |
| 39 | +> 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. |
| 40 | +
|
| 41 | +## Data synchronization |
| 42 | + |
| 43 | +To synchronize two or more distinct search services, you can either: |
| 44 | + |
| 45 | ++ Push content into an index using [Documents - Index (REST API)](/rest/api/searchservice/documents/) or an equivalent API in the Azure SDKs. |
| 46 | ++ Pull content into an index using an [indexer](search-indexer-overview.md). |
| 47 | + |
| 48 | +### [Push APIs](#tab/push-apis) |
| 49 | + |
| 50 | +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. |
| 51 | + |
| 52 | +### [Pull APIs (Indexers)](#tab/pull-apis) |
| 53 | + |
| 54 | +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. |
| 55 | + |
| 56 | +The following diagram illustrates this architecture: |
| 57 | + |
| 58 | +:::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"::: |
| 59 | + |
| 60 | +--- |
| 61 | + |
| 62 | +## Data residency |
| 63 | + |
| 64 | +When you create multiple search services in different regions, your content is stored in the region you chose for each service. |
| 65 | + |
| 66 | +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: |
| 67 | + |
| 68 | ++ [Enrichment cache](cognitive-search-incremental-indexing-conceptual.md) |
| 69 | ++ [Debug sessions](cognitive-search-debug-session.md) |
| 70 | ++ [Knowledge store](knowledge-store-concept-intro.md) |
| 71 | + |
| 72 | +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). |
| 73 | + |
| 74 | +## Request failover and redirection |
| 75 | + |
| 76 | +For redundancy at the request level, Azure provides several [load-balancing options](/azure/architecture/guide/technology-choices/load-balancing-overview): |
| 77 | + |
| 78 | +### [Azure Application Gateway](#tab/application-gateway) |
| 79 | + |
| 80 | +Use [Azure Application Gateway](/azure/application-gateway/overview) to load balance between servers in a region at the application layer. |
| 81 | + |
| 82 | +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. |
| 83 | + |
| 84 | +### [Azure Front Door](#tab/front-door) |
| 85 | + |
| 86 | +Use [Azure Front Door](/azure/frontdoor/front-door-overview) to optimize global routing of web traffic and provide global failover. |
| 87 | + |
| 88 | +### [Azure Load Balancer](#tab/load-balancer) |
| 89 | + |
| 90 | +Use [Azure Load Balancer](/azure/load-balancer/load-balancer-overview) to load balance between search services in a backend pool. |
| 91 | + |
| 92 | +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. |
| 93 | + |
| 94 | +### [Azure Traffic Manager](#tab/traffic-manager) |
| 95 | + |
| 96 | +Use [Azure Traffic Manager](/azure/traffic-manager/traffic-manager-overview) to route requests to multiple geo-located websites backed by multiple search services. |
| 97 | + |
| 98 | +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. |
| 99 | + |
| 100 | +The following diagram illustrates search apps connecting through Traffic Manager: |
| 101 | + |
| 102 | +:::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"::: |
| 103 | + |
| 104 | +> [!TIP] |
| 105 | +> 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. |
| 106 | +
|
| 107 | +--- |
| 108 | + |
| 109 | +As you evaluate these load-balancing options, consider the following points: |
| 110 | + |
| 111 | ++ Azure AI Search is a backend service that accepts indexing and query requests from a client. |
| 112 | + |
| 113 | ++ 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. |
| 114 | + |
| 115 | ++ 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. |
| 116 | + |
| 117 | ++ 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. |
| 118 | + |
| 119 | +## Related content |
| 120 | + |
| 121 | ++ [Reliability in Azure AI Search](/azure/reliability/reliability-ai-search) |
| 122 | ++ [Design reliable Azure applications](/azure/architecture/framework/resiliency/app-design) |
0 commit comments