To deploy a pair of Azure SQL Managed Instances (MI) in an auto-failover group, you must deploy the primary and secondary instances in different Azure regions.
While technically you can choose any two regions, the standard best practice is to use Azure Paired Regions (e.g., East US and West US).
Failover Groups Overview & Best Practices – Azure SQL Managed Instance | Microsoft Learn
Deployment Requirements
To ensure the failover group functions correctly, your deployment must meet these specific criteria:
Geographic Separation: The secondary instance cannot be in the same region as the primary. Using paired regions is recommended because Azure ensures that only one region in a pair is updated at a time, minimizing the risk of simultaneous downtime.
Networking (non-overlapping IPs): The Virtual Networks (VNets) for the primary and secondary instances must have non-overlapping IP address ranges. If both use 10.0.0.0/16, you will not be able to peer them, and the failover group configuration will fail.
Global VNet Peering: You must establish a connection between the two VNets using Global VNet Peering so the instances can replicate data privately.
DNS Zone Matching: Both instances must belong to the same DNS zone. This is usually handled automatically if you select the primary instance as the “partner” when creating the secondary instance in the Azure portal.
Quick Comparison: Primary vs. Secondary
| Feature | Primary Instance | Secondary Instance |
| Location | Your main production region | A different region (Paired or Unpaired) |
| Read/Write | Yes | only read-only, after failover it is read/write |
| Service Tier | Eg. Business critical or General Purpose or other | Should be same tier as primary, Business critical or General Purpose or other |
| Instance Size and storage size | Same, ex: 4 vcore, 64GB | Same, 4 vcore, 64GB |
| Update Policy | ex: 2022 or should be same | ex: 2022 or should be same |
The backup redundancy can be a Locally Redundant Storage (LRS) or Zone Redundant or Geo Redundant. Always choose paired regions for SQL MI instance due to low latency between the regions. Open Ports: Ensure Network Security Groups (NSGs) allow traffic on ports 5022 and 11000-11999.
The Azure SQL MI failover group cannot be created if any of the (service tier, storage size, vcore, Update Policy) components are different in the source and target regions.
You can always configure the failover policy either customer managed policy (Manual failover) or Auto-Failover policy which is controlled by Microsoft.
Most applications use customer managed failover because you decide when to failover and failback.
Summary
Deploy your Primary in your main production region and your Secondary in its Azure Paired Region. Ensure their VNets don’t overlap, peer them together, and keep their hardware specs identical.
Visit CloudNerchuko for more blog posts.