Protect Azure SQL with auto-failover groups

The cost of a failover group is mostly the cost of running the secondary. The replica has to match the primary's service tier and compute size so it can carry the full write workload after failover, so as a rule of thumb you are funding a second copy of the database's compute, plus a small amount of cross-region data transfer for replication. That is a known, recurring number you can put in a budget.

Set that against the thing it removes: unplanned regional downtime for a production database. An outage with no second-region fallback is not a fixed cost, it is an open-ended one. The bill runs while the database is unreachable, and it includes lost transactions, idle staff, missed SLAs to your own customers, and the recovery effort, none of which you control once the region is down. The finance question is not 'what does the replica cost' in isolation, it is 'what is an hour of this database being down worth, and how many hours does the failover group remove'.

Microsoft documents a recovery point objective of about five seconds and, with the recommended customer-managed failover policy, a recovery time of typically up to about a minute for failover groups, so the resilience you are buying is specific rather than vague. Frame it as insurance with a quantifiable premium: the replica is the premium, the avoided outage is the claim, and unlike most insurance the payout also removes the recovery scramble, not just the loss.

Priya is the finance partner supporting the platform team's pre-peak reliability review. The recommendation list lands with several production databases flagged for having no cross-region fallback, and the team's instinct is to ask for budget to put a failover group on all of them. The finance instinct is narrower: which of these databases actually backs revenue or a customer-facing service, because the cost of protecting one is a standing second copy of its compute, and that should be spent where downtime hurts.

Priya asks the team to split the flagged databases into three buckets. The payments ledger and the live customer API database are revenue-critical: an hour of downtime there has a direct, measurable cost, so the recurring replica spend is easy to justify. A reporting database can tolerate being read from backup for a few hours, so it does not need a standing secondary. A pile of test and staging databases need nothing. The finance pack reads: 'Two databases get a second-region replica because an outage there costs more per hour than the replica costs per month; the rest are documented as accepting backup-based recovery, so we are buying resilience exactly where the downtime cost justifies it, not blanket.'

The cost model here is a premium against a tail risk. The premium is concrete and recurring: a secondary replica sized to match the primary, plus cross-region replication traffic. The tail risk is a regional outage, which is rare per year but, when it lands on a critical database, is expensive in a way you do not control. The bill during an outage is not just lost revenue per hour, it is also the staff time consumed by the recovery and any contractual penalties for missing your own customers' SLAs.

This is why the decision should be made per database, not across the estate. Funding a standing replica for every test and reporting database wastes money on downtime that costs little; refusing one for the revenue-critical database saves a small monthly amount and leaves an open-ended outage cost on the table. The finance role is to attach an hourly cost of downtime to each candidate database and fund the replica wherever a single bad regional afternoon would cost more than the replica does over its lifetime.

Every production database sits in one Azure region. The leadership question is what happens to the business if that region is impaired for a few hours. For a database with no geo-replicated secondary, the honest answer is that the service it backs is down until the region recovers or someone restores from backup, and recent data may be lost.

An auto-failover group changes that answer. It keeps a continuously replicated copy of the database in a second region, and when the primary region fails the team triggers the failover with a single command and the platform moves traffic to the secondary, with the application reconnecting to the same endpoint name within about a minute. The outcome shifts from 'we are down until Azure recovers' to 'we failed over to the second region and stayed open, with at most a few seconds of data behind'.

This is a deliberate resilience investment, not a free win. You are paying to run a standby copy of the database in another region. The decision leadership owns is which databases are important enough to the business that an open-ended regional outage is unacceptable, and therefore worth that standing premium.

After a cloud region elsewhere in the industry had a multi-hour outage that took several well-known services offline, the CEO asked the obvious question at the next review: if our primary Azure region went down for an afternoon, what happens to us? The honest answer at the time was that the payments service would be down until the region came back, because the database lived in one region with only geo-redundant backups behind it, and restoring those is an hours-long, lossy job.

The team's response was to stop treating disaster recovery as an improvised project and start treating the recovery path as a built-in property of the critical databases. They put the payments ledger and the customer API database into failover groups with a secondary in a second region and the recommended customer-managed failover policy, and pointed the applications at the listener endpoints instead of the server names. The next time the question came up, the answer had changed from 'we would be down for hours' to 'we trigger the failover for those two databases with one command, the platform promotes the second region, the apps reconnect to the same endpoint, and we keep taking payments with at most a few seconds of data behind, typically inside a minute.' That shift, from a region outage being a crisis to it being a short, deliberate failover for the databases that matter, is the confidence this capability buys, and the cost is the standing replica behind those few databases.

Regional cloud outages are infrequent but not hypothetical, and when one hits a single-region system of record the business is simply offline until recovery completes. The auto-failover group is the capability that turns that scenario from a multi-hour outage into a short, one-command failover to a second region for the databases you have chosen to protect.

The trade-off is honest and ongoing: you pay to run a standby copy of each protected database. So the board-level decision is not technical, it is a continuity judgement about which databases are important enough that an open-ended regional outage is unacceptable. For those, the standing premium is small against the cost of being down; for the rest, accepting backup-based recovery is a legitimate, documented choice.