Reserve Azure Cosmos DB capacity

This is one of the cleanest savings levers in a Cosmos DB bill. The throughput Advisor flags is already provisioned and already being paid for at the pay-as-you-go rate; reserved capacity simply lowers the rate on usage that was always going to happen. Microsoft documents reserved capacity savings reaching up to 63 per cent versus pay-as-you-go for the longest terms and the largest throughput tiers, with the realised saving depending on the term, the scale of the commitment and the region. The saving is not a forecast of future behaviour, it is a discount applied to a usage pattern you can already see in the last 30 days of data.

The number that matters is not the headline percentage, it is the payback against the commitment. A one year reservation paid monthly carries almost no cash-flow risk: the monthly bill for that throughput simply drops. A three year term paid upfront saves more but ties up the money and the capacity decision for longer. The finance role is to match the term to how confident the business is that the workload, and that floor of RU/s, will still be running, and to reserve the steady floor rather than the peak. Throughput provisioned above the reserved amount continues at the pay-as-you-go rate, so reserving conservatively is the safe error.

The downside is bounded and known. Cosmos DB reserved capacity is not strictly locked in: Microsoft supports self-service exchanges and refunds of reservations, and currently does not charge an early-termination fee on refunds, subject to a documented cap on total cancelled commitment per billing profile in a rolling twelve month window. That means a reservation bought against a workload that later shrinks can usually be exchanged or partially returned rather than written off, which makes the commitment far less risky than it first appears.

Priya is the finance partner supporting the platform team. Cosmos DB is one of the biggest items on the Azure bill and the provisioned throughput has been flat for months, which is exactly the signature of reservable usage. Advisor estimates the saving per subscription from the last 30 days, but the instinct is not to wave the whole estimate through. It is to ask how much of that throughput is genuinely permanent. Advisor sizes its recommendation from a look-back window, so a workload that was temporarily scaled up for a backfill can be over-recommended; the finance job is to reserve the durable floor of RU/s and leave headroom on the pay-as-you-go rate.

Priya reframes the recommendation as a payback decision rather than a discount percentage. For each candidate she asks two questions: how confident are we that this throughput floor runs for the full term, and do we want the cash-flow profile of monthly billing or the deeper saving of paying upfront? The steadiest, longest-lived throughput, the production catalogue and the core API container, goes onto a three year term for the largest saving. The merely-probable throughput goes onto a one year term paid monthly, where the commitment is short and the monthly bill simply falls. Anything serverless is set aside entirely because reservations do not apply to it. The finance pack reads: 'We are converting our steady Cosmos DB throughput floor to committed pricing, sized below peak, with terms matched to confidence, and the commitment is exchangeable if the workload shrinks.'

The cost model here is unusually favourable. The throughput in scope is already provisioned and already in the budget at the pay-as-you-go rate, so a reservation does not add a workload, it lowers the price of one you are already paying for. The saving begins the hour the reservation is bought and continues for the full term, which means every month of delay is saving that is permanently forgone, not merely deferred.

The risk is the mirror image and it is bounded. The worst realistic case is a reservation bought above the throughput you steadily provision, leaving part of the commitment unused each hour because the discount is use-it-or-lose-it. Reserving the floor rather than the peak prevents most of this, and Microsoft's self-service exchange and refund process, with no early-termination fee currently and refunds capped per billing profile in a rolling twelve month window, means a genuinely over-bought reservation can usually be exchanged for one that fits or partially returned. The finance role is to reserve the confident floor on the right term, monitor reservation utilisation as a first-class metric, and treat any persistent underutilisation as a prompt to exchange rather than a loss to absorb.

Every steady floor of Cosmos DB throughput that bills at the pay-as-you-go rate is paying a premium for a flexibility the business is not using. Azure Advisor quantifies exactly how much, per subscription, and tells you how much to reserve to remove it. This is not a cut to capacity or performance: the same databases and containers keep running at the same throughput, they just cost less.

The leadership question is not 'should we use reserved capacity?' It is 'what proportion of our steady-state database throughput is still on the pay-as-you-go rate, and why?' Mature estates run their predictable RU/s floor on reservations and keep pay-as-you-go for genuinely variable or serverless workloads. A high pay-as-you-go share on steady throughput is money left on the table every month it persists.

The trade is a commitment of one or three years against a lower rate, and it is a reversible one: Microsoft supports exchanging and refunding reservations within published limits, with no early-termination fee currently charged. The decision is therefore less 'are we locked in?' and more 'are we confident this throughput floor will still be running?', which is exactly the kind of question leadership is positioned to answer.

At a cost review the CFO noticed that Cosmos DB was a large and growing line, and asked the obvious question: are we getting the best rate on the throughput that never scales down? The honest answer at the time was that the production floor, stable for the better part of a year, was still billing entirely at the pay-as-you-go rate because nobody had owned the reserved capacity decision.

The team's response was to treat it as a portfolio rather than a one-off purchase. They pulled Advisor's recommendation, read the actual provisioned throughput on each account, reserved the steady floor on a mix of one and three year terms with shared scope so the discount followed matching throughput across subscriptions, and left the autoscaling, bursty and serverless throughput on the pay-as-you-go rate where the flexibility is genuinely used. The next review showed the same databases running unchanged at a materially lower unit cost, with a documented exchange route if any workload shrank. The shift, from paying the pay-as-you-go premium by default to reserving the predictable floor on purpose, is the saving this capability delivers, and it touches nothing about how the applications run.

Steady database throughput on the pay-as-you-go rate is one of the most common avoidable costs in a growing Cosmos DB estate, precisely because it requires no mistake to occur: throughput simply defaults to the pay-as-you-go rate and stays there. The saving from reserving the predictable floor is recurring, it lands every month for the life of the reservation, and unlike a cost cut it does not reduce capacity or slow anything down.

The reason to treat this as a leadership decision rather than delegate it entirely is the commitment, and the reassuring part is how reversible that commitment is. Microsoft supports exchanging and refunding reservations within published limits and currently charges no early-termination fee, so the genuine risk is not lock-in but the discipline of reserving the floor rather than the peak. This is the rare saving that is both large and low-risk: the question to ask is simply why any steady throughput is still on the pay-as-you-go rate.