Assume you have created Azure SQL Managed Instance in two regions (One is Primary region for read/write workloads, and another is for a secondary region for read workloads) with a failover group.
Now, the application can connect to the Primary region SQL MI and perform read or write operations on the databases of SQL Managed Instance.
For the secondary region, if you configure the secondary for standby, Microsoft says you cannot use this for read workloads where your application connects to the secondary and perform read operations on the database.
Table of Contents
- Optimizing Azure SQL Managed Instance: The “Standby” vs. “Readable” Dilemma
- Summary: Choosing the Right Strategy
Optimizing Azure SQL Managed Instance: The “Standby” vs. “Readable” Dilemma
When designing a high-availability (HA) and disaster recovery (DR) strategy for Azure SQL Managed Instance (MI), the goal is often twofold: ensure maximum uptime and minimize licensing overhead. However, there is a fine line between a Passive Standby and an Active Secondary. Let’s understand what Microsoft is saying:
1. The Architecture: Failover Groups
In a geo-distributed setup, you typically deploy two SQL Managed Instances linked by an Auto-Failover Group or a Customer managed failover group.
- Primary Region: Handles all Read/Write traffic via the Primary Listener and Application connects to the SQL MI using read/write listener of Failover group.
- Secondary Region: Acts as a synchronized copy of your databases, ready to take over if the primary region goes down due to outage or any kind of disaster.
2. The License-free DR Benefit
Microsoft offers a significant cost-saving feature for SQL MI: the Failover Rights benefit. These benefits fall under Pay-as-you-Go and Azure Hybrid Benefits
Referring Azure SQL MI documentation of Configure License-Free Standby Replica – Azure SQL Managed Instance | Microsoft Learn, below are two examples:
Example 1: As a pay-as-you-go customer, if you have 16 vCores assigned to the secondary instance, a discount for 16 vCores appears on your invoice if you designate your secondary instance for standby only.
Example 2: if you have 16 Azure Hybrid Benefit licenses and you deploy two SQL managed instances that have 8 vCores each to a failover group, after you designate the secondary instance as standby, 8 vCores are returned to your license pool for you to use with other Azure SQL deployments.
The benefit is that you only pay for primary instance and you will get the discount on secondary instance on your invoice (credit card bill).
3. The Catch: What Defines “Standby”?
According to Microsoft’s licensing terms, a “Standby” instance is only permitted to perform the following tasks:
| Task | Description |
| Limited read-only workloads | Example: Dynamic Management Views (DMVs), backups, and Database Console Commands (DBCC) queries. Note: You cannot do production read workloads on your database in SQL MI |
| Planned Failover | Perform DR drills to the secondary which makes it as read/write and old primary as only read. |
| Forced Failover | Perform actual DR to the secondary and results in data loss if transaction committed in primary are not reflected in the secondary. |
| System administration | Taking database backups, restore, consistency checks (DBCC) |
I have covered a few tasks in this blog post, but to check all the tasks visit Configure License-Free Standby Replica – Azure SQL Managed Instance | Microsoft Learn
4. Readable replica
Means the secondary is same as the primary except you are only using the secondary for read-only workloads. Here you need to pay full SQL Server license costs.
Note: As the SQL MI secondary instance is part of a failover group, you are not allowed to perform the write operations on the databases and results in error if you perform any write operations.
Also Read:
Azure SQL MI Failover Group Pre-Requisites
Crucially, you cannot connect your application to the secondary for production read-only workloads. If your application connects to the secondary to run reports, dashboards, or any user-facing queries, it is no longer a standby as it is an Active Secondary, and you are required to pay for the full SQL license costs on both instances.
| Feature | Standby (DR Only) | Readable Secondary |
| Licensing Cost | $0 (SQL License cost waived) | Full Price (SQL License required) |
| Read Operations | Prohibited for workloads | Allowed via Read-only Listener |
| Primary Use Case | Disaster Recovery | Reporting & Offloading Traffic |
| Maintenance | DBCC CHECKDB, Backups only | Full reporting functionality |
Summary: Choosing the Right Strategy
If your application requires high performance and you want to offload heavy “Read” queries to another region to reduce the load on your Primary, you must accept the SQL licensing costs for both regions.
However, if your secondary region exists strictly for the “What If” scenario of a regional outage, then configuring it as a Standby is a good way to reduce your Azure monthly spend on the secondary SQL MI.
For more SQL MI blogposts, visit Category: Azure SQL MI – Cloud Nerchuko
Disclaimer: This is human-authored content, developed with AI assistance to ensure technical accuracy and clarity.