Right-size Azure Cosmos DB throughput with autoscale

Provisioned throughput is usually the largest component of an Azure Cosmos DB bill, and a manual ceiling means paying for peak capacity twenty-four hours a day for a workload that only peaks for part of it. Switching a spiky or variable workload to autoscale is a pure savings move: there is nothing new to buy, the data does not move, and the monthly charge falls because you are billed hourly for what the workload actually consumed rather than for a static ceiling.

The arithmetic has a clean break-even that Microsoft documents. Autoscale is priced at 1.5 times the manual rate per RU/s, so it only saves money when average utilisation sits below roughly 66.7 per cent of the manual ceiling. Below that line, autoscale wins, because the hours the workload spends scaled down outweigh the per-RU premium. Above it, a steady workload is cheaper left on manual. The finance job is to read Advisor's seven-day estimate, confirm the workload is genuinely variable, and treat the ones below break-even as risk-free savings and the steady ones as a deliberate keep-on-manual decision.

The payback is immediate and the downside is bounded. There is no migration cost, no resource to procure, and the change is reversible with a single command. The only thing to verify is that Tmax is set high enough to cover the real peak, so the saving never comes at the cost of throttling the workload.

Priya is the finance partner watching Cosmos DB climb the Azure bill. Advisor surfaces five autoscale recommendations across the estate, each with a seven-day savings number attached. The instinct is not to bank the headline total and move on; it is to ask whether each flagged workload is genuinely variable, because that is what determines whether the saving is real. Switching to autoscale buys nothing and moves no data, so the cost question is narrow: the only thing that can erode the saving is a workload that runs near its ceiling most of the time, where the 1.5x autoscale rate would cost more than it saves.

Priya asks the team to line each recommendation up against its average utilisation. Three containers are clearly spiky, busy during business hours and near-idle overnight, sitting well under the 66.7 per cent break-even, and those are the risk-free savings to take. One is a steady high-throughput container that runs hot most of the day, where autoscale would actually raise the bill, so it stays on manual as a deliberate call. The last is borderline and gets a week of monitoring before a decision. The finance pack reads: 'Three containers move to autoscale for an estimated recurring saving with no spend and no migration; one steady workload stays on manual on purpose; the saving is billing for use instead of a ceiling, and it reverses in one command if a peak ever changes.'

The cost model here is unusually clean for an optimisation. The saving is recurring, it requires no spend to capture, and Azure Advisor has already estimated it from real seven-day usage, so the number on the recommendation is close to what lands on the bill. There is no migration to fund and no resource to buy: the change is a billing-mode switch on capacity you already own.

The discipline is to respect the break-even rather than chase the headline. Autoscale costs 1.5 times the manual rate per RU/s, so it saves only where average utilisation sits below about 66.7 per cent of the ceiling. The finance role is to confirm each flagged workload is genuinely variable, take the ones below break-even as recurring savings, leave the steady high-utilisation ones on manual on purpose, and note the multi-region-write accounts where autoscale is free and should simply be the default. Tracked that way, the recommendation turns from a one-off tip into a forecastable, repeatable line on the savings tracker.

Cosmos DB on a fixed manual ceiling is a standing cost set to the busiest hour and charged for every hour. For a workload with a daily peak and a quiet night, that means the bill is sized for the peak and paid around the clock. Autoscale lets the spend follow demand down when the workload is idle, so the line item reflects use rather than a one-time guess.

The leadership question is not 'can we cut the database?' It is 'is our database spend tracking what we actually use, or a ceiling nobody has revisited?' Azure Advisor already flags the accounts where the answer is the latter, with a savings estimate attached. The defensible end state is that variable workloads run on autoscale with a sensible peak ceiling, and the few genuinely steady high-utilisation workloads stay on manual on purpose, both as documented choices.

This is a savings decision with almost no risk attached. The change buys nothing, moves no data, and reverses in one command, so the trade is a small per-unit premium on autoscale against the larger saving from paying for use instead of a permanent peak.

After a cost review where Cosmos DB was the line that had grown fastest, the CFO asked the obvious question: are we paying for what we use, or for capacity we set once and forgot? The honest answer at the time was that several containers had been sized manually during the early build and never revisited, so the bill was pinned to old peak guesses rather than current demand.

The team's response was to stop treating throughput as a set-and-forget number and start treating it as a managed cost. They pulled every Azure Advisor autoscale recommendation, checked each flagged workload's real utilisation, moved the variable ones to autoscale with a sensible peak ceiling, and left the genuinely steady high-utilisation containers on manual as a documented choice. The next quarter the Cosmos DB line fell, not because anything was cut, but because the spiky workloads stopped paying peak rates overnight. The next time the CFO asked the question, the answer had changed from 'we think it is about right' to 'variable workloads bill for what they use, the steady ones are on manual on purpose, and Advisor confirms there is no idle ceiling left to trim.' That shift, from a static guess to spend that tracks demand, is the saving this capability delivers, and it costs nothing to reach.

This is the rare optimisation where the upside is real recurring money and the downside is close to nothing. Moving a variable workload to autoscale buys no new resource, moves no data, and reverses in a single command, while the saving, paying for use instead of a permanent peak, lands every month. Azure Advisor even quantifies it in advance from real usage, so leadership is approving a number, not a hope.

The cost of leaving it is quiet and compounding: every over-provisioned container keeps paying peak rates overnight, and the gap widens as traffic patterns drift away from the original guess. Against a saving that is forecast, recurring and reversible, the only real requirement is to set the peak ceiling correctly so performance is never traded for cost. That makes this exactly the kind of low-risk savings decision leadership should approve quickly.