Home / AI & GenAI

AI & GenAIHow-toAdvanced

Azure AI Search disaster recovery: a second service, index rebuilds and traffic switching

Azure AI Search has no built-in cross-region failover. Plan DR with a second search service in another region, defined as code and kept in sync by indexers or dual-push, then switch app traffic. Includes sync options, a failover runbook and cost notes.

Deepak Bhardwaj3 min read

Applies toAzure AI Search (Basic and above) used for RAG and enterprise search

1. What you get by default

  • Replicas and availability zones protect against node and zone failures within one region.
  • There's no geo-replication of indexes, and no customer-initiated failover. If the region is down, the service is down.

So DR means a second search service in another region.

2. Define everything as code

Index schemas, data sources, skillsets, indexers, synonym maps and vectorisers in source control. Deploy them to both services with the REST API or the SDKs:

for svc in srch-prod-cin srch-prod-sin; do
  curl -X PUT "https://$svc.search.windows.net/indexes/kb-docs?api-version=2024-07-01" \
    -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" \
    --data @search/indexes/kb-docs.json
done

3. Keep the DR index in sync

Option How Notes
Indexers in both regions Each service has indexers pulling from the (geo-replicated) source storage or database Simplest. Each service runs the same skillset and vectoriser, which doubles embedding cost
Dual-push The ingestion pipeline pushes the same documents (with vectors already computed) to both services Embed once; works with any source
Rebuild on failover DR service exists but is empty; index only when needed Cheapest. RTO = full index time

Use the same embedding model and version in both regions. Integrated vectorisation in DR needs its own model deployment in the DR region.

4. App configuration

  • App settings hold the search endpoint and index name. Better: a gateway or config service that switches the endpoint.
  • Use Entra ID (managed identity) on both services, with the same role assignments.
  • Private endpoints in both regions, with DNS for each.

5. Failover runbook

  1. Confirm the primary search service is unavailable (Resource Health, failed queries from multiple clients).
  2. Check that the DR index is current: document count, and the last indexer run or last push timestamp.
  3. Switch the app's search endpoint to the DR service (config change, feature flag or gateway route).
  4. Check search quality with golden queries.
  5. If the DR index is empty or stale, start indexers or a push job, and tell users results may be incomplete.
  6. Fail back after the primary is healthy, and resync anything indexed only in DR (dual-push avoids this).

6. Cost notes

  • A second service is billed whether it's used or not. A warm DR service can use fewer replicas (for example 1) and scale out on failover. Replica count changes take time, so test how long.
  • Doubling indexer-driven enrichment doubles skill costs (OCR, embeddings). Dual-push with stored vectors avoids that.

7. Test

  • Twice a year, switch a test app (or a canary share of production) to the DR service, and compare top-5 results for golden queries.

Tip

Front Door or Traffic Manager can route between two search services, but most RAG apps reach search from the backend through private endpoints. Switching the endpoint in configuration is usually simpler and more predictable.

Related fixes