Migrate Cosmos DB to continuous backup for point-in-time restore

The right lens here is not security spend, it is the cost of an outage. When a Cosmos DB account is on periodic backup and something corrupts your data, the recovery path runs through a Microsoft support ticket and a restore you do not control, so the outage clock keeps running for hours. Continuous backup converts that into a self-service restore your team runs in minutes. The variable you are buying down is downtime duration, and downtime duration is the most expensive line in any incident.

The spend to buy that down is small and bounded. The seven-day continuous tier carries no backup-storage charge, so for many accounts the migration is genuinely free. The thirty-day tier, which the Advisor recommendation targets for its full thirty-day restore window, is billed at a documented rate of $0.20 per GB of data per region per month for backup storage. Restore operations themselves are charged each time you run one, but you only run a restore during an actual incident, when the alternative is a far larger outage bill.

Frame it as insurance with a known premium. The premium is, at most, a modest monthly backup-storage charge on the accounts that hold data worth a thirty-day window, and nothing on the seven-day tier. The payout is the difference between a multi-hour, ticket-driven recovery and a minutes-long self-service one. For any account behind revenue or customer-facing traffic, that trade is one-sided.

Priya is the finance partner sitting in on the reliability review. The recommendation reads 'migrate three Cosmos DB accounts to continuous backup,' and the instinct is to ask the one question that matters: what does this cost, and what does it save? The team walks her through the two tiers. The seven-day continuous tier adds no backup-storage charge, so any account that only needs a week of restore history migrates for free. The thirty-day tier is billed at a documented $0.20 per GB of data per region per month for backup storage, so its cost is simply data size times region count times that rate, a number the team can put an exact figure against per account.

She maps the three accounts to the data behind them. The two production accounts hold live customer data where a multi-hour, ticket-driven recovery would mean lost transactions and refunds, so the thirty-day tier is worth its modest monthly charge to maximise the restore window. The scratch analytics account can sit on the free seven-day tier or stay as it is. The finance pack reads: 'Two production accounts move to the thirty-day tier at a small, exactly forecastable monthly storage cost; the rest is free; and what we buy is the ability to recover ourselves in minutes instead of waiting hours on a vendor ticket during an outage.' The framing is downtime avoided per pound spent, not storage purchased.

The cost model here is asymmetric, but along a different axis than most security work: it is about downtime, not breach liability. The cost of acting is small and forecastable: nothing for the seven-day tier, and a documented $0.20 per GB per region per month of backup storage for the thirty-day tier, plus a per-incident restore charge you only ever pay during an actual recovery. The cost of not acting is the difference in outage duration between a self-service restore measured in minutes and a ticket-driven one measured in hours, on whatever revenue and customer trust sits behind that database.

The finance role is to attach an hourly cost of downtime to each account behind the recommendation and weigh it against the tiny premium of the appropriate tier. For a customer-facing production account, even a conservative downtime figure makes the thirty-day tier's monthly storage charge look like a rounding error. For a scratch or internal account, the free seven-day tier covers it. Either way the decision is sized by downtime avoided, and that is the number that belongs on the reliability review, not the raw storage cost in isolation.

The leadership question this capability answers is simple: when our primary database gets corrupted, how long are we down, and who is in control of bringing it back? On periodic backup the honest answer is 'hours, and not us, we wait on Microsoft support.' On continuous backup it becomes 'minutes, and us, we restore to the second ourselves.'

That is a resilience decision, not really a budget one. The seven-day tier costs nothing extra in backup storage, and the thirty-day tier costs a small, predictable monthly amount. Against that sits the cost of an outage on a customer-facing system, which is rarely small and never predictable. Continuous backup is the kind of trade where the downside of acting is a rounding error and the downside of not acting is a headline.

Azure Advisor already flags which accounts are exposed. The decision is whether to treat that flag as a quiet backlog item or as what it is: the gap between owning your recovery and renting it from a support queue during your worst hour.

After the migration script near-miss, the CEO asked Priya the only question that mattered at the next review: if that script had actually shipped, how long would we have been down? The honest answer at the time was uncomfortable. The account was on periodic backup, so the team would have opened a support ticket with Microsoft, waited in a queue, and accepted whatever snapshot point was available, potentially losing up to an hour of good writes along with the bad. The recovery was real but it was slow and it was not in the team's hands.

The response was to treat the Advisor recommendation as a resilience decision rather than a backlog ticket. The team migrated the two production accounts to continuous backup, ran a rehearsed point-in-time restore into a throwaway account to prove the path worked, and documented the runbook. The next time the CEO asked the question, the answer had changed from 'hours, and we wait on the vendor' to 'minutes, and we do it ourselves, to the exact second before the mistake.' That shift, from renting your recovery to owning it, is the confidence signal this capability delivers, and on the seven-day tier it costs nothing in Azure storage to reach.

The root cause of a long database outage is rarely the corruption itself, it is the recovery path. A team that has to open a vendor ticket and wait for a stale snapshot is structurally slower to recover than one that can restore itself to the exact second before the mistake. Continuous backup is the capability that puts recovery back in your own hands, and Azure Advisor already tells you which accounts lack it.

The cost of getting this wrong shows up as a prolonged outage on a customer-facing system, which is expensive and reputationally damaging in ways that dwarf any backup-storage line. The cost of getting it right is, at most, a small predictable monthly charge and often nothing at all. This is the rare resilience control where the risk of inaction is severe and the cost of action is trivial, which is exactly the trade leadership should be quickest to approve.