Key Vault Built-in DR Behavior

Question

Hi,

According to Microsoft doc: https://learn.microsoft.com/en-us/azure/key-vault/general/disaster-recovery-guidance

I understand that Azure Key Vault has a built-in disaster recovery (DR) solution that works across regions, and that this feature is included regardless of the Key Vault tier (Standard or Premium).

From what I’ve read, this built-in DR means that in the event of a primary region outage, I should be able to access my Key Vault resources from the secondary region without needing to trigger a manual failover.

However, I’d like to confirm the following:

1. Is it correct that there's no supported way to perform a DR test for this built-in failover behavior? If so, how can we validate or gain confidence that the failover will actually work during a regional outage? And I can still access to my key vault when primary region outage?
2. In a scenario where my Key Vault is integrated with a private endpoint, and I want to rely on the built-in DR, what’s the recommended setup for private endpoints?

• Should I pre-deploy a private endpoint in the secondary region, but still point it to the Key Vault in the primary region?
• In that case, would I need to create a secondary Private DNS Zone to support name resolution for the secondary region's private endpoint?

Appreciate any clarification on this setup.

Answer 1

1. Is there a supported way to perform a DR test for the built-in Key Vault failover?

AFAIK, there is no Microsoft-supported way to test the automatic cross-region failover for Azure Key Vault. The built-in disaster recovery for Azure Key Vault is automatic and managed by Microsoft, without customer-facing failover controls. You cannot simulate a regional outage or trigger a manual failover to test the DR behavior. The platform handles this silently during real outages.

2. How can you gain confidence that failover will actually work during a real outage?

While there's no way to simulate or force failover, you can review Azure SLAs and past incident reports (https://azure.status.microsoft/en-us/status/history/) to understand how failover has worked in practice. You might be able to perform additional resilience testing at the application layer (e.g., simulate Key Vault unavailability by blocking DNS resolution or network access), but this obviously doesn't test Azures internal failover.

3. What's the recommended setup for private endpoints to support DR across regions?

If you want your application to continue accessing Azure Key Vault during a primary region outage, and you're using Private Endpoints, you must architect for regional redundancy.

• Deploy two Private Endpoints, one per region:
  • Primary PE in the primary region's VNet.
  • Secondary PE in the secondary region's VNet.
• Both PEs point to the same Key Vault, which is regionally-redundant (not geo-replicated, but available across regions through platform resilience).
• Configure Azure Private DNS Zones to resolve the Key Vault FQDN to the right private IPs.

DNS Setup:

• Azure uses the format yourvault.vault.azure.net.
• Create two A records in a single Private DNS Zone (privatelink.vaultcore.azure.net):
  • One pointing to the primary PE IP.
  • One pointing to the secondary PE IP.

Failover is not automatic at the DNS level. You'll need to handle DNS resolution or traffic redirection at the network layer (e.g., via custom logic, DNS failover, or traffic manager-like solution in your infrastructure).

4. Should you create a secondary Private DNS Zone?

No, you typically do not need to create a secondary Private DNS Zone. You can use a single Private DNS Zone (privatelink.vaultcore.azure.net) shared across both regions if your VNets are peered or connected via Azure Virtual WAN. Alternatively, if using separate DNS zones per region, you'll need to manage cross-region name resolution manually.

---

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