Skip to article
Databases SQL Managed Instance

SQL managed instance failover group

Microsoft Learn describes failover groups for Azure SQL Managed Instance as a way to manage geo-replication and coordinated failover of all user databases from one managed instance to another managed instance in a different Azure region, with stable listener endpoints for application connectivity.

Source: Microsoft Learn - Failover groups overview and best practices for Azure SQL Managed Instance Reviewed 2026-05-25

Exam trap
Creating a failover group but leaving applications pointed at the primary managed instance host instead of the failover group listener.
Production check
Run az sql instance-failover-group show and confirm partner instance, listener names, failover policy, grace period, and region.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
SQL MI failover group, managed instance failover group, instance failover group, SQL Managed Instance FOG
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-25
Review level
template-specs-five-use-cases
Article depth
template-specs-five-use-cases-three-case-studies
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A SQL managed instance failover group is a disaster recovery setup that pairs two managed instances in different Azure regions. It replicates user databases from the primary instance to the secondary and gives applications listener names that can move during failover. The goal is not just to copy data; it is to make regional recovery manageable at the instance level. When the primary region is unavailable or a planned test is approved, the failover group can redirect workloads to the secondary side.

Why it matters

SQL managed instance failover group matters because regional outages are not solved by backups alone. Backups can restore data, but failover groups provide a more operationally ready path for keeping applications online when a primary region is impaired. They also make recovery testable: teams can validate listener connections, failover procedures, application retries, monitoring, and runbook ownership before a real event. The feature carries responsibility. If the secondary instance is undersized, unreachable, poorly monitored, or missing dependent services, the failover group gives a false sense of safety. Good design treats it as one part of end-to-end business continuity. That discipline prevents improvisation.

Technical context

Technically, a failover group for SQL Managed Instance sits on top of geo-replication between two managed instances. It involves the Azure SQL control plane, managed instance networking, DNS listener endpoints, replication state, failover policy, grace period, maintenance planning, and application connection strings. Unlike database-level failover groups for Azure SQL Database, a managed instance failover group covers all user databases in the instance. The paired instances must be designed with compatible regions, DNS zone considerations, network connectivity between VNets, and enough capacity on the secondary to run the workload.

Exam context

Compare with

SQL Managed Instance Azure SQL Database

Where it is used

Where you see it

  1. In the Azure portal, the managed instance Failover groups blade shows partner instance, replication state, listeners, failover policy, and available failover actions. during DR reviews.
  2. In Azure CLI output, az sql instance-failover-group show returns primary and partner details, policy, grace period, secondary type, and resource location. during continuity testing.
  3. In application configuration, connection strings should point to failover group listener endpoints rather than a single managed instance host name. during quarterly connection-string review meetings.

Common situations

  • Provide regional disaster recovery for all user databases on a SQL Managed Instance when business continuity requires faster recovery than restore alone.
  • Use stable read-write listener endpoints so applications reconnect to the current primary after a planned or emergency geo-failover.
  • Run quarterly failover exercises that measure application reconnection, secondary capacity, monitoring, and operator decision steps.
  • Offload approved read-only workloads to the secondary listener when reporting should not consume primary instance capacity.
  • Compare manual and automatic failover policy choices against data-loss tolerance, operator availability, and incident declaration procedures.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Online pharmacy survives regional database outage Scenario, objectives, solution, measured impact, and takeaway.
Scenario

An online pharmacy processed prescription refills on SQL Managed Instance. Leadership required a tested regional recovery path before expanding same-day delivery.

Goals
  • Fail over all user databases as one recovery unit.
  • Keep application connection strings stable during failover.
  • Prove the secondary region could handle refill traffic.
  • Reduce recovery decision time during a regional incident.
Approach using SQL managed instance failover group

The platform team implemented a SQL managed instance failover group between primary and secondary managed instances in separate regions. They built the secondary with matching capacity, connected VNets through approved private paths, and updated applications to use the read-write failover group listener. Azure CLI created and showed the failover group configuration, then operators ran planned failover tests during pharmacy maintenance windows. Application teams measured reconnect behavior, refill queue processing, and identity dependencies in the secondary region. The runbook defined when manual failover would be declared, who could approve forced failover, and how backup retention still handled bad data scenarios.

Potential outcomes
  • Planned failover completed with application reconnection in 94 seconds during the final test.
  • Secondary-region refill throughput reached 96 percent of primary baseline.
  • Incident decision steps dropped from sixteen checklist items to six owner-approved actions.
  • A same-day delivery launch risk was cleared after two successful quarterly exercises.
What to learn

A failover group turns regional recovery from a theoretical architecture diagram into a rehearsed operational workflow.

Scenario 02 Airport baggage platform validates listener routing Scenario, objectives, solution, measured impact, and takeaway.
Scenario

An airport baggage routing system used SQL Managed Instance for bag status and conveyor events. Hard-coded database endpoints made a prior DR test fail late at night.

Goals
  • Replace instance-specific connection strings with failover group listeners.
  • Confirm baggage applications reconnect after planned failover.
  • Keep secondary capacity ready for holiday travel peaks.
  • Expose DNS and private networking issues before an incident.
Approach using SQL managed instance failover group

The airport technology team redesigned the database recovery path around SQL managed instance failover group listeners. Network engineers verified private DNS and VNet peering between the two managed instance regions. Platform engineers used Azure CLI to show failover group listener names, policy, partner resource group, and secondary location, then exported the output for the operations binder. Application owners replaced hard-coded endpoints, tested connection pooling behavior, and simulated region failover during an overnight baggage drill. Monitoring dashboards showed bag scan latency, database failover events, and failed connection counts. The team also adjusted maintenance windows so primary and secondary instances were less likely to be serviced during the same operational period.

Potential outcomes
  • The next DR test completed without changing application connection strings.
  • Bag scan latency stayed under the 250 millisecond target after failover.
  • Two private DNS misconfigurations were found and fixed before the holiday schedule.
  • The operations team reduced overnight test staffing from nine people to five.
What to learn

Failover group listeners matter as much as replication because applications must reconnect to the recovered primary without emergency edits.

Scenario 03 Media analytics company offloads read-only reporting Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A media analytics company used SQL Managed Instance for subscriber scoring. Heavy analyst queries competed with ingestion during live sports events.

Goals
  • Add regional recovery without slowing primary ingestion.
  • Route approved reporting workloads to a secondary listener.
  • Test failover before playoff traffic peaks.
  • Track the cost and value of the secondary instance.
Approach using SQL managed instance failover group

The data platform team configured a SQL managed instance failover group and enabled reporting teams to use the read-only listener for approved dashboards. Azure CLI created the failover group, showed the listener endpoints, and documented the failover policy. Analysts moved event-night dashboards to the secondary listener, while ingestion applications stayed on the read-write listener. Operations ran planned failover tests, measured dashboard freshness, and compared ingestion latency before and after read offload. FinOps tagged the secondary instance as both disaster recovery and reporting capacity so the business could see why it was not simply idle infrastructure.

Potential outcomes
  • Primary ingestion CPU dropped by 19 percent during live event windows.
  • Dashboard freshness stayed within the five-minute business target.
  • Planned failover testing achieved a 12-minute end-to-end application validation cycle.
  • Cost review approved the secondary because reporting offload avoided a primary scale-up.
What to learn

A SQL managed instance failover group can support both resilience and read-only offload when the secondary is sized, monitored, and funded honestly.

Azure CLI

With ten years of Azure engineering behind me, I use Azure CLI for SQL managed instance failover groups because disaster recovery needs repeatable proof, not hopeful screenshots. CLI commands show the failover policy, partner instance, region, replication relationship, grace period, and listener details. They also let operators rehearse planned failovers, update configuration, and capture evidence during quarterly resilience tests. In an outage, the CLI is often faster than navigating the portal, especially when teams already have runbooks. It also reduces dangerous ambiguity: the command names, resource group, location, and failover type are visible before execution. It also exposes drift before drills.

Useful for

  • Create an instance failover group between approved primary and partner managed instances after DNS zone and network requirements are met.
  • Show failover group configuration before a resilience test and export listener, policy, partner, and grace-period details.
  • Update failover policy, grace period, or secondary usage after the business continuity owner approves the change.
  • Set the primary during a planned failover test or emergency runbook, using allow-data-loss only under explicit approval.
  • Delete a retired failover group after applications, backups, monitoring, and secondary cleanup have been verified.

Before you run a command

  • Confirm tenant, subscription, resource groups, primary managed instance, partner managed instance, location, and shared DNS zone requirements.
  • Verify VNet connectivity, private DNS behavior, region pairing strategy, secondary capacity, and application use of failover group listeners.
  • Check permissions to create, update, or fail over instance failover groups, and confirm the Microsoft.Sql provider is available.
  • Review RPO, RTO, failover policy, grace period, maintenance windows, data-loss tolerance, and who can approve emergency failover.
  • Use explicit output format and record command evidence, because failover operations affect every user database on the managed instance.

What the output tells you

  • Partner instance fields confirm whether the failover group connects the intended primary and secondary managed instances across regions.
  • Failover policy and grace period show whether failover is customer-managed, automatic, and how long Azure waits before automatic action.
  • Listener names tell application teams which endpoints should appear in connection strings for read-write and, where used, read-only traffic.
  • Provisioning state and replication-related fields help operators decide whether a planned failover test can proceed safely.
  • Location, resource group, and secondary type reveal whether the command targeted the correct side of the recovery architecture.

Mapped commands

SQL Managed Instance failover group CLI operations

direct 
az sql instance-failover-group create --resource-group <resource-group> --name <failover-group> --mi <primary-managed-instance> --partner-mi <secondary-managed-instance> --partner-resource-group <partner-resource-group>
az sql instance-failover-groupprovisionDatabases
cost-impacting Microsoft Learn 
az sql instance-failover-group show --resource-group <resource-group> --location <location> --name <failover-group>
az sql instance-failover-groupdiscoverDatabases
read-only Microsoft Learn 
az sql instance-failover-group update --resource-group <resource-group> --location <location> --name <failover-group> --failover-policy Manual
az sql instance-failover-groupconfigureDatabases
mutating Microsoft Learn 
az sql instance-failover-group set-primary --resource-group <secondary-resource-group> --location <secondary-location> --name <failover-group>
az sql instance-failover-groupoperateDatabases
failover Microsoft Learn 
az sql instance-failover-group delete --resource-group <resource-group> --location <location> --name <failover-group>
az sql instance-failover-groupremoveDatabases
destructive Microsoft Learn

Architecture context

Architecturally, I design a SQL managed instance failover group as the data-tier component of a regional recovery pattern. The primary and secondary instances need compatible capacity, private connectivity, DNS zone planning, VNet peering or equivalent network paths, and maintenance schedules that do not create avoidable overlap. Applications should use the failover group listener, not hard-coded instance endpoints. Monitoring must cover replication health, lag, failover operations, and secondary readiness. The secondary region also needs dependent services: application hosts, identity, storage, Key Vault, private DNS, and observability. A database failover without application and network recovery is only half a continuity plan. before launch.

Security
Security impact is direct because failover groups duplicate sensitive user databases into another region and expose listener endpoints that applications trust. Both managed instances must have consistent identity, auditing, encryption, network restrictions, and privileged access controls. Operators should verify that the secondary region does not become a weaker boundary with broader firewall rules or forgotten administrators. Listener connection strings need secure storage, and failover permissions should be limited to trained roles. Forced failover options deserve extra control because they can involve data loss. Compliance teams should review regional data residency, audit evidence, and who can initiate or approve failover. Role ownership must be reviewed.
Cost
Cost impact is direct because a failover group requires a secondary managed instance with enough capacity to serve the workload when needed. That secondary may be active for read-only workloads or standby for disaster recovery, but it still represents compute, storage, backup, networking, monitoring, and operations cost. Under-sizing saves money until the first failover test proves applications cannot run. Over-sizing without owner approval creates a quiet DR premium. FinOps reviews should track secondary utilization, reserved capacity, backup storage, data transfer, monitoring costs, and whether read-only offload justifies active capacity. Business owners should fund the recovery objective they expect. Drill labor also belongs in the model.
Reliability
Reliability impact is direct and central. A failover group improves regional resilience by replicating user databases and allowing coordinated failover to a secondary managed instance. It does not guarantee that the whole application will recover; clients need retry logic, connection strings must use listeners, and dependent services must exist in the recovery region. Reliable operation requires planned failover tests, monitoring of replication state, documented RPO and RTO expectations, and clear rules for manual versus automatic failover. Operators must also remember that dropped databases on the primary replicate as deletions, so backup retention and change controls remain important. Evidence should be saved after drills.
Performance
Performance impact appears in both replication and failover behavior. The primary workload must sustain replication to the secondary, and the secondary region must have enough compute, storage, and network capacity to run applications after failover. Initial seeding can be lengthy for large databases, and ongoing workload intensity affects how quickly changes replicate. Read-only listener use can offload reporting, but it may expose latency or stale-read assumptions. Operators should test application response time after failover, not only database availability. Network path quality between regions, DNS behavior, connection pooling, and retry policies all influence perceived performance during recovery. Drill metrics should guide secondary sizing.
Operations
Operators manage SQL managed instance failover groups through create, show, update, failover, and delete workflows. Practical work includes validating partner instance readiness, checking VNet connectivity, confirming listener usage, testing planned failover, reviewing Activity Log events, and documenting who declares a regional outage. During tests, operators monitor replication state, application reconnects, DNS behavior, and secondary capacity. After failover, they verify database roles, alerts, backups, and user access. Mature teams keep a runbook that distinguishes planned failover, customer-managed emergency failover, and data-loss-accepting scenarios, because the wrong choice during pressure can worsen the outage. Post-drill notes should be attached to the continuity record.

Common mistakes

  • Creating a failover group but leaving applications pointed at the primary managed instance host instead of the failover group listener.
  • Under-sizing the secondary instance because it looks idle, then failing the first realistic recovery test under production load.
  • Ignoring private DNS, VNet peering, or routing requirements between the primary and secondary managed instance networks.
  • Assuming failover group protects against accidental deletes or bad data, even though those changes can replicate to the secondary.
  • Using forced failover with possible data loss without a clear incident commander, business approval, and post-failover validation plan.