Azure Cosmos DB autoscale cost: when the 50% premium pays off
Cosmos DB autoscale raises the per-RU/s rate by 50 percent but scales throughput automatically between 10 percent and 100 percent of a maximum. For variable traffic it can be cheaper than standard provisioned; for flat traffic it is a needless premium. Here is the math.
Quick answer
Cosmos DB autoscale bills at about $0.012 per 100 RU/s per hour, a 50 percent premium over standard provisioned throughput at about $0.008 per 100 RU/s per hour, but it automatically scales between 10 percent and 100 percent of the configured maximum and bills only the highest RU/s used each hour. Autoscale is cheaper when traffic is variable enough that average usage sits below about 66 percent of peak, because the idle-hour savings outweigh the higher rate. For flat, predictable traffic that runs near its ceiling all day, standard provisioned is cheaper. The rule: autoscale for spiky traffic, standard for steady traffic.
Cosmos DB charges for throughput in request units per second (RU/s), and you can provision that throughput two ways. Standard (manual) provisioning fixes the RU/s and bills it around the clock. Autoscale sets a maximum and lets Cosmos scale instantly between 10 percent and 100 percent of it, billing each hour for the highest RU/s reached, but at a 50 percent higher rate. Choosing between them is a bet on how variable your traffic is.
The two rates
| Mode | Rate per 100 RU/s-hour | Scales? |
|---|---|---|
| Standard provisioned | ~$0.008 | No, fixed |
| Autoscale | ~$0.012 | 10% to 100% of max |
At standard rates, 1000 RU/s fixed costs about $58 per month. The same 1000 RU/s as an autoscale maximum costs about $88 per month if it runs at the ceiling every hour, the 50 percent premium in action. But autoscale rarely runs at the ceiling every hour, and that is the whole point.
Where autoscale wins
Autoscale bills each hour for the peak RU/s that hour, and can drop as low as 10 percent of the maximum when traffic is quiet. If your workload spends most of the day well below peak, an application busy during business hours and nearly idle overnight, autoscale bills the low RU/s during the quiet hours and only the premium rate during the busy ones. The break-even is roughly when average usage sits below about 66 percent of the maximum: below that, the idle-hour savings beat the 50 percent premium. This mirrors the idle-elimination logic in the Cosmos DB serverless guide.
Where standard is cheaper
For traffic that is flat and predictable, running near a steady RU/s all day, standard provisioning is cheaper because you never benefit from autoscale's ability to scale down and you pay the 50 percent premium for nothing. A background service pushing a constant stream of writes at a known rate should be provisioned manually at that rate. The saving from RU/s efficiency, covered in the RU optimization guide, applies to both modes.
A worked comparison
Imagine a container that peaks at 1000 RU/s for eight business hours and drops to about 100 RU/s the other sixteen. Standard at 1000 RU/s bills the full rate all day: about $58 per month. Autoscale with a 1000 RU/s maximum bills roughly the premium rate for the eight peak hours and the 10 percent floor for the rest, landing closer to $40 per month. The variability makes autoscale the cheaper choice. Flip the pattern to constant 1000 RU/s and standard's $58 beats autoscale's $88.
Choosing the mode
Estimate your RU/s over a representative day and compute the average as a fraction of the peak. If it is below about two thirds, autoscale is likely cheaper; if it hugs the peak, use standard. For deeply intermittent or unpredictable workloads, serverless may beat both. Price each mode against the resource catalog before you deploy so the throughput choice is grounded in your actual traffic shape rather than a default.
FAQ
How much more does Cosmos DB autoscale cost?
Autoscale bills at about $0.012 per 100 RU/s per hour versus about $0.008 for standard provisioned throughput, a 50 percent premium on the rate. But autoscale bills each hour only for the highest RU/s reached and can scale down to 10 percent of the configured maximum, so for variable traffic the idle-hour savings can more than offset the higher rate.
When is Cosmos DB autoscale cheaper than standard?
When traffic is variable enough that average usage sits below about 66 percent of peak. Because autoscale bills the hourly peak and can drop to 10 percent of the maximum during quiet periods, a workload busy during business hours and idle overnight pays the premium only during busy hours and the low floor otherwise, landing cheaper than paying the standard rate around the clock.
When is standard provisioned Cosmos DB cheaper?
When traffic is flat and predictable, running near a steady RU/s all day. In that case autoscale never gets to scale down, so you pay the 50 percent premium for no benefit. A background service pushing a constant write stream at a known rate should be provisioned manually at that rate rather than using autoscale.
How do I decide between autoscale and standard?
Estimate RU/s over a representative day and compute average usage as a fraction of the peak. Below roughly two thirds, autoscale is likely cheaper because of its scale-down savings; near the peak, standard is cheaper because you avoid the premium. For deeply intermittent or unpredictable workloads, serverless may beat both, so compare all three for your traffic shape.
How does C3X help with Cosmos DB throughput cost?
C3X prices Cosmos DB throughput configurations from Terraform before you deploy, so the cost of autoscale versus standard provisioned RU/s is visible in the pull request. That lets you compare the two modes against your expected traffic shape at design time and avoid paying the autoscale premium on steady workloads or the standard flat rate on spiky ones.
What to do next
Compare Cosmos DB autoscale and standard before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.