Azure Cosmos DB cost is driven mainly by throughput, billed as request units per second (RU/s), plus storage per GB. With standard provisioned throughput you pay for the RU/s you reserve every second whether you use them or not, so the fastest wins come from matching provisioned capacity to real demand: move spiky or unpredictable workloads to autoscale or serverless, size partition keys so no single partition becomes a hot spot, set a time to live on data that expires, and trim the indexing policy. Once the steady floor of throughput is known and defensible, reserved capacity on a one or three year term discounts it materially. The goal is high utilization of provisioned RU/s, not the lowest possible setting.
Here is what actually moves the Cosmos DB bill, in priority order, with a worked example.
What drives Cosmos DB cost?
Two things: throughput and storage. Storage is a small per GB charge. Throughput is the lever. Every read, write, query, and stored procedure consumes request units, and you provision a ceiling of RU/s for a container or database. With standard provisioned throughput you pay for that ceiling continuously, so a container set to 100,000 RU/s for a daytime peak still bills the full rate at 3am. Backups, multi region writes, and analytical stores add to it, but the single largest controllable number on most bills is provisioned RU/s sitting above genuine demand.
Provisioned, autoscale, or serverless?
Cosmos DB offers three throughput models, and choosing the right one per workload is the biggest structural saving. The decision turns on how predictable and how steady the traffic is.
| Model | You pay for | Best for | Watch out for |
|---|---|---|---|
| Standard provisioned | A fixed RU/s ceiling, billed every second | Steady, predictable, high volume traffic | Idle hours bill at full rate |
| Autoscale | Highest RU/s used each hour, within a 10x band | Spiky or variable demand with quiet periods | A small premium per RU versus standard at full load |
| Serverless | Only the request units you actually consume | Intermittent, low to moderate, development and test | Throughput and storage caps per container |
The common mistake is leaving everything on standard provisioned. Autoscale lets capacity fall to a tenth of the ceiling during quiet hours, so a workload that runs hot for eight hours and idles for sixteen often costs far less on autoscale even with its per RU premium. Serverless removes the floor entirely for bursty or low traffic containers. Figures here are indicative; verify against current Azure pricing.
How do partition design and indexing quiet the bill?
Throughput is spread evenly across physical partitions, so a poorly chosen partition key creates a hot partition that throttles under load and pushes you to over provision RU/s for the whole container just to keep one partition alive. Choosing a high cardinality key that distributes reads and writes evenly lets the same workload run on far lower provisioned throughput. Indexing is the second quiet cost: Cosmos DB indexes every property by default, and every indexed write consumes request units. Narrowing the indexing policy to the paths you actually query reduces RU cost on every write, often by a meaningful share on write heavy containers. Finally, set a time to live on data that expires so storage and index size do not grow without bound.
These three moves, a balanced partition key, a lean indexing policy, and a time to live, compound: they lower the RU/s you need to provision, which is the number you are billed on.
Does reserved capacity help?
Once you know the steady floor of throughput a workload genuinely needs, Cosmos DB reserved capacity discounts that committed RU/s in exchange for a one or three year commitment, in the same risk for discount trade as other Azure commitments. The discipline mirrors our wider Azure cost optimization guide: commit only to the floor you can defend from a forecast, keep the variable peak on autoscale or on demand, and rightsize before you commit so you do not lock waste in for the term. Reserved capacity sits underneath the throughput model choice, not instead of it.
A worked example
A European SaaS company ran every Cosmos DB container on standard provisioned throughput sized for peak, including a reporting container that was busy for two hours a day and idle the rest. Moving the reporting and several event style containers to autoscale, rebalancing a hot partition key on the main container so its provisioned RU/s could drop, and trimming the indexing policy on a write heavy audit container cut the Cosmos DB line by well over a third, with no change to latency at peak. Committing the remaining steady floor to reserved capacity added a further saving. The work formed part of an Azure program that left the estate materially lighter. Figures are verified against billing data and anonymised.
Frequently asked questions
Cut your Cosmos DB and Azure data bill
We help enterprises right size Cosmos DB throughput, fix hot partitions, and place reserved capacity against a defensible forecast, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the cloud cost optimization playbook, read the deeper Azure cost optimization guide, and see how the same discipline applies to Azure OpenAI spend governance.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.