Do failover replication and the actual failover for resources between different VNET regions require peering?

Hi Tan-9136,

Thanks for reaching out on Microsoft Q&A forum

Here are the answers to your queries to follow:

1.Does failover replication for resources like VMs and SQL Managed Instances require peering?

For Azure SQL Managed Instances, proper IP connectivity is must that means you will need connection like VNet Peering or a VPN.

2.If it does require peering, will a VNet-to-VNet VPN connection work?

Yes, a VNet-to-VNet VPN connection will work for SQL Managed Instances, but Global VNet Peering is preferred for better performance and lower latency.

3.If you have existing VNet-to-VNet VPN connections and want to switch to VNet peering, how to ensure failover replication won't be interrupted?

Keep the existing VPN connection active while you set up the VNet Peering.

Verify that the necessary routes are correctly configured.

Make sure that your User Defined Routes (UDRs) don’t direct traffic through the VPN gateway when the peering connection should be used.

4.By adding VNet Peering, will it interfere with the failover replication?

No,Adding VNet Peering won’t interfere with replication as long as you ensure all connectivity requirements are met, and routes are set correctly to avoid issues like asymmetric routing.

5.How to test the failover replication with VNet Peering instead of using VPN?

Once the peering is established and functioning:

Perform a health check on your connections (e.g., test TCP connections for SQL Managed Instances).

Use ASR’s Test Failover feature for VMs to ensure everything is working as expected before removing the VPN connections

If you find this comment helpful, Please “up-vote” for the information provided , this can be beneficial to community members.

Kindly let us know if you have any additional questions.

Thanks

Thank you @Michele Ariis and @Priya ranjan Jena

Quick questions:

1. How do I set up Global VNET peering because I don't see the option?
   Is Global VNET peering done automatically when multiple different regions are being peered?
2. How do I check the UDR doesn't direct traffic from SQL MI through VPN gateway?
3. How do I do this TCP connection test for SQL MI?

There's no special switch for Global VNet Peering: if you peer two VNets in different regions, it's already "global." Create two peerings (A→B and B→A) from the portal (VNet → Peerings → Add) with "Allow traffic to remote VNet" enabled; no gateway transit unless you really need it. To prevent traffic to SQL MI from going through the VPN gateway, check the UDRs on the subnets (both client-side and MI subnets): there must be no route to remote networks (or 0.0.0.0/0) with Next hop = Virtual network gateway; also check the Effective routes on a client NIC: the VNet peering route must appear, not the gateway route. Test with DNS and ports: make sure the MI private DNS zone is linked to both VNets; From a VM in the opposite VNet, do nslookup <mi>.database.windows.net and Test-NetConnection <fqdn> -Port 1433; if you use Redirect, also allow 11000–11999 in NSG. Safe migration from VPN to peering: 1) leave the VPN on, 2) create the two peerings, 3) fix/delete UDRs that force the gateway, 4) test DNS and connectivity (1433 and, if necessary, redirect ports), 5) run ASR Test Failover for the VMs and test access to MI, 6) only when everything is ok, remove the VPN.

Thank you very much for you reply, @Michele Ariis
I checked the route tables and there's no route that uses VPN Gateway as the next hop however I checked the NIC's effective route, it does have routes that use VPN Gateway.

My understanding is NIC's effective route VPN record will be removed automatically once I removed the VPN, correct?

As for MI private DNS Zone, I am still lacking understanding on this.
I will need to read more about what's the relationship between private DNS Zone with the VNETs.