Request for guidance on ADX geo-redundant replication for BCDR

Christine Han 140 Reputation points Microsoft Employee
2026-05-11T20:10:01.5133333+00:00

Hi Kusto team,

Due to the recent Sev-1 incident on Kusto in the US region, we'd like to request your support in setting up a replica for our Central US region cluster. We're aware of the Active-Active pattern described in the official BCDR guidance (Business continuity and disaster recovery overview), but the cost of running a second full-size cluster is not acceptable for our cluster. Could you advise on alternative options or update the plan to support geo-redundant Replication on ADX?

Azure Data Explorer
Azure Data Explorer

An Azure data analytics service for real-time analysis on large volumes of data streaming from sources including applications, websites, and internet of things devices.

Answer accepted by question author
Marcin Policht 108.6K Reputation points MVP Volunteer Moderator
2026-05-11T21:13:45.09+00:00

One potential approach is to implement an Active-Passive Hot Standby configuration using Continuous Data Export and Geo-Redundant Storage. This should ensure that your data is replicated to the secondary region at the storage layer without requiring a full-scale compute cluster to be running 24/7. In this scenario, you maintain a secondary cluster at the minimum possible SKU and node count to handle metadata sync and critical small-scale queries, which significantly reduces the monthly burn compared to a mirrored production environment.

Data replication is managed by exporting your primary data to an Azure Storage account configured with GRS or RA-GRS. You can use the following command structure to set up a continuous export job that pushes your data to the secondary region's storage endpoint.

.create-or-alter continuous-export MyExportJob
over (MyTable)
to table MyExternalTable
with (intervalBetweenRuns=5m)
<| MyTable | where ingestion_time() > ago(5m)

In the event of a regional failure like the one recently seen in Central US, you would trigger a scale-up operation on the passive cluster. This can be automated using the Azure CLI to increase the capacity or change the VM size to match your production requirements only when the failover is active. This allows you to pay for the high-performance compute only during the duration of the incident.

az kusto cluster update --cluster-name "secondary-cluster" --resource-group "my-rg" --sku name="Standard_E16s_v4" capacity=10

Another way to further reduce costs is to utilize External Tables on the secondary cluster. Instead of ingesting all data twice, which doubles the ingestion cost, the secondary cluster can query the exported data directly from the GRS storage.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.