ASR Different Region

The Region 2 VNet is isolated only while it has no peering, VPN/ExpressRoute gateway connectivity, or other routing into production; run the Test Failover in a separate, nonproduction VNet with the same address space rather than assuming the ASR failover VNet is safe for testing.

Expected behavior

• VNet isolation: A newly created Azure VNet is isolated from other networks by default. Having the same address space as Region 1 does not itself connect the VNets. Do not attach the test VNet to the on-premises VPN or peer it with either production VNet.^1^
• Private IP address: ASR attempts to use the IP configured under the replicated VM’s Network settings. With the same address space, the test VM receives that same private IP only if the address belongs to the selected subnet and is available. Otherwise, ASR assigns another available address, normally from the end of the subnet range.^2^
• Production VM: A Test Failover does not stop the source VM, interrupt ongoing replication, or replicate test changes back to it. The production VM in Region 1 continues running normally when the test VM is placed in an isolated test network.^1^

Thus, the same private IP can safely exist in both regions during the drill because the two networks have no route to each other.

Recommended test configuration

1. Create or designate a dedicated test VNet in Region 2.
   • Use the same address range, subnet names, and subnet layout as production.
   • Do not configure VNet peering, VPN/ExpressRoute connectivity, or production routes on it.
   • Check existing peerings, gateway connections, and route tables rather than relying only on the VNet being ASR-created.
2. Verify the replicated VM’s test settings.
   • Open Recovery Services vault → Replicated items → your VM → Compute and Network.
   • Review the Test failover network, subnet, and target IP for each NIC.
   • If the matching subnet name does not exist, ASR selects the first subnet alphabetically; the subnet can be changed in the VM’s Network settings.^2^
3. Start the drill and explicitly select the isolated VNet.
   • For a recovery plan, open Recovery Plans → recovery-plan name → Test Failover.
   • Select the recovery point.
   • Select the dedicated test VNet, not a connected Region 2 production or recovery VNet.
   • Monitor progress under Jobs, then verify the test VM’s NIC and assigned private IP.^1^
4. Clean up afterward.
   • Select Cleanup test failover when testing is complete. This deletes the temporary test VMs; changes made inside them are discarded and are not returned to the production VM.^1^

Important boundary

If the Region 2 VNet is connected to on-premises or production, it is not an isolated test network. Running both copies with the same IP and machine identity on connected networks can cause routing, DNS, and application conflicts. Microsoft’s guidance for testing in a production-connected recovery network is to shut down the primary VM first, which introduces production downtime.^1^

For domain-joined applications, the isolated network may also need its own test-failed-over domain controller and DNS server; configure the VNet DNS address accordingly before testing.^3^

References

1. Run a test failover (disaster recovery drill) to Azure
2. Set up network mapping and IP addressing for VNets
3. Set up disaster recovery for Active Directory and DNS