The auto-failover groups feature allows you to manage the replication and failover of all user databases in a managed instance to another Azure region. The secondaries are currently used both as a disaster recovery solution for failover, and as for read scale-out by sending read workloads to these secondaries.
Still, many customers today use GeoDR as a disaster recovery solution only. These customers not using secondaries for read workloads still need to pay the full SQL license cost for their secondary – well, the Failover rights benefit is the solution for them.
What does the Failover Rights benefit offer?
The idea behind Failover Rights GeoDR is to remove the license costs for secondary instances that do not service read workloads (those instances are called Standby geo replicas). The Cost structure can be seen on the picture below, and it is expected the total cost for this instance to drop for up to 55% depending on your service tier (you would still have to pay for the underlying infrastructure). For more precise calculation, use this AHB calculator Azure Hybrid Benefit - Hybrid Cost Calculator | Microsoft Azure
The benefit translates differently between customers using the Pay-as-you-go model vs. customers using theAzure Hybrid Benefit (AHB).
Pay-as-you-go customers see the vCores discounted from their invoice, while
Customers using the AHB for the standby replica have an equal number of vCores as the secondary replica uses returned to their licensing pool.
What does the Standby replica support?
Even though the Standby replica must be used as DR-only, with no production applications connected to the replica, there are still some activities that are permitted. For example, you can still:
Perform maintenance operations (e.g., check DB)
Let monitoring applications connect to the Standby replica
Run DR drills
This means this instance cannot be used for read-only purposes such as reporting.
How to setup the failover group and get the Failover rights benefit?
There are several ways you can get the Failover rights benefit.
The first one would be during the failover group creation. The form is adapted to accommodate the new benefit and we added a new field to be selected if you want the Failover rights benefit to be activated. Of course, for this you need to confirm the Secondary instance will be used as a Standby replica. This is a failover group parameter, and it will be later accessible via Failover group blade through either the Primary or Secondary instance menu.
The other option would be on the Compute+Storage blade of your Secondary instance. Please note that the benefit is on the failover group level, but you can activate it on the instance blade because the benefit is given based on the vCores number of your Secondary.
And the positive effect is that this change is directly reflected and visible on the Cost summary. The failover rights benefit masks whatever the previous license state of the instance was, since it is not possible to have both AHB and Failover rights benefit applied at the same time.
Please note, that there is no need to recreate the failover group in order to get the benefit.
Failover group overview
One new improvement is the content of the Failover group blade. Here you can now see the status of the failover group, the failover rights benefit, and also the status of the belonging instances. One useful thing is that the underlying license status of your instances is visible, so you know what to expect if the failover group benefit is removed, or if failover happens.
Be careful if your PAYG secondary instance (covered by the failover rights benefit) becomes the new primary instance since the costs may increase.
What primary/secondary configuration is supported?
To make the Failover group work properly, our recommendation is to have the same vCore configuration for both Primary and Secondary instance, but this does not need to always be the case. And no matter what the chosen configuration is, the size of the benefit will always depend on the secondary instance, irrelevant to the primary instance. For example:
Passive instances with less vCores than the primary, will get the benefit for all their vCores. Even not advisable to have this kind of a mismatch, since the secondary could lag, it is still possible. The full benefit is given for the secondary and up to the number of vCores it allocates.
Passive instances with equal vCores as the primary, will get the benefit for all their vCores. No surprises here.
Passive instances with more vCores than the primary, will get the benefit for all their vCores.
The last case even possible is not expected to last long (especially for failover configurations with a Standby replica), since there is no reason to pay for the Secondary more vCores than needed (even though the licenses are given for free), and we will consider these situations as transient states. A couple of scenarios where the primary/secondary configuration is not favorable but expected to be only temporal are
UpdateSLO, where the advice is when scaling up, to scale up first the secondary ending in fog configuration where secondary has more vCores than the primary.
UpdateSLO, where the advice is when scaling down, to scale down first the primary ending in fog configuration where secondary has more vCores than the primary.
Failover in already mismatched configuration when secondary with less vCores becomes the primary
What happens if I remove the failover rights benefit?
The license state of the secondary instance (PAYG or AHB) will be remembered once the Failover rights benefit is activated, and in case the benefit is removed, the secondary instance will return to its previous state.
Also, if the failover group is removed, the standby replica becomes a read-write standalone instance and returns to its previous license state.
How does the billing work?
All the given graphs below are extracted from the Portal. You can do the same by
going to the Cost analysis for a chosen subscription,
set the Daily costs as a View,
find your Managed Instance from the list of all Resources, and
tick the SQL License costs as a metric subcategory.
It should look something like the screenshot below.
Now, for a given Failover group, composed of two Azure SQL Managed Instances (both are 8vCores GP instances with 256GB data storage), we'll observe how the billing changes in the following scenarios:
1. Let's observe the Secondary instance that is Pay-as-You-Go, and what are the expenses over time
Here is the total cost over time (the daily cost doesn't change over time).
Here are the licenses cost only (the daily cost also doesn't change over time).
2. Let's observe the Secondary instance that is PAYG, and what happens after we assign the Failover rights (the failover group benefit). The benefit is applied on Sep 27th @ 8pm.
Here is the total cost over time, and it can be seen that some portion is already given on the very date when the benefit was applied. The following days, the total cost is reduced for the full license price.
Here are the licenses cost only, and it can be seen that the total license cost drops to zero the following day.
3. Let's observe the Secondary instance that is PAYG, and what happens after we assign the AHB instance benefit, while the Failover rights are not activated. The benefit is applied on Nov 7th @ 8pm.
Here is the total cost over time (exactly the same as the previous case when we applied the Failover rights benefit)
Here are the licenses cost only (and the price also drops to zero)
4. Let's observe the Primary instance that is PAYG, and what are the expenses after the failover while the Failover rights benefit is applied
Here are the total costs for the instance initially in the Primary state. Before the failover, you were paying the full price, but after the failover, the instance becomes the Secondary and goes under the Failover and the total of this instance is reduced.
Here are the licenses cost only, and right after the failover, the license price for this instance drops to zero.
5. Let's observe the Secondary instance that is PAYG, and what are the expenses after the failover while the Failover rights benefit is applied
Here are the total costs for the instance initially in the Secondary state. Before the failover, the instance was covered by the Failover rights benefit, and the total cost was reduced. After the failover, the instance becomes the Primary and the Failover rights benefit is removed, and the total cost for this instance is increased.
Here are the licenses cost only, and right after the failover, the how the license price jumps to the full price.
The last scenario is something to pay attention to as it can increase your total instance cost. The advice is to check both the Primary and the Secondary instance right after the failover and their license status. The best place to do this is the Failover group summary and License type setting for each of the instances.