Work out what a Cosmos DB container really provisions: how many physical partitions the throughput and the storage force, what one partition key can therefore use, and whether autoscale is cheaper than a fixed RU/s at your utilisation.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
20,000 RU/s is two partitions at 10,000 each. A partition key carrying more than half the traffic gets 429s at 10,000 while the account shows 20,000 provisioned.
5,000 RU/s is one partition and 500 GB is ten, so the container has ten and each gets 500 RU/s. A throughput-only estimate misses this entirely.
12 GB against a hard 20 GB ceiling. Writes to that key fail permanently when it arrives, and the fix is a new container with a different key.
At 80% average utilisation autoscale bills 1.5x for headroom already in use. The break-even is around 67%, and below it autoscale wins.
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Throughput is divided EVENLY across physical partitions, regardless of where the traffic goes. A container at 20,000 RU/s across two partitions gives each 10,000, so a hot key returns 429s at 10,000 while the account shows 20,000 provisioned and mostly idle.
Instead:Check Normalized RU Consumption split by PartitionKeyRangeId. The account total averages the hot partition away.
The extra is divided evenly too, so a partition holding 80% of the traffic still gets its equal share. The throughput was never the constraint.
Instead:Change the partition key, which means a new container and a migration. Do it while there is still room rather than after the 429s.
It is a hard ceiling on one partition key value with no way to raise it. Writes to that key fail permanently once it is reached, and there is no repartitioning in place.
Instead:Add a synthetic suffix to the key, a date or a bucket number, before the limit. After it, the only path is a new container.
It bills at 1.5x the manual rate for whatever it scales to, so it only saves money below roughly 67% average utilisation. Above that you pay a premium for headroom you are already using, and the 10% floor means an idle container still bills a tenth of its maximum.
Instead:Provision manually for a steady load and alert on throttling. Autoscale is for genuinely spiky traffic.
It multiplies the provisioned throughput by twice the region count, not by the region count, and it moves conflict resolution into the application. Three regions with writes is six times the single region bill.
Instead:Use a single write region with read replicas. That is most of the availability benefit, a fraction of the cost, and no conflicts.
Provisioned throughput is divided evenly across physical partitions regardless of where the traffic goes. That is the Cosmos surprise, and no metric on the account blade shows it directly.
Above 10,000 RU/s or 50 GB the container is split into physical partitions, and each gets an equal share of the provisioned throughput. A partition key carrying more than its share then returns 429s at that share, while the account shows the full figure provisioned and mostly idle. Storage forces the split too, which is the case a throughput-only estimate misses: 5,000 RU/s over 500 GB is ten partitions at 500 RU/s each.
20,000 RU/s, 100 GB
2 partitions, 10,000 RU/s each
5,000 RU/s, 500 GB
10 partitions, 500 RU/s eachThe Normalized RU Consumption metric split by PartitionKeyRangeId is what shows a hot partition. The account total averages it away, so a container at 100% on one range and 5% on nine others reads as 14% overall and looks fine. If one range is pinned, more RU/s does not fix it: the extra is divided evenly too.
One partition key value cannot hold more, there is no way to raise it, and writes to that key fail permanently once it is reached. There is no repartitioning in place: the fix is a new container with a different key and a migration. A key that is over half full is on a schedule, and the time to add a synthetic suffix is before the limit rather than after.
It scales between 10% and 100% of the maximum with the load, and bills at one and a half times the manual rate for wherever it lands. Below roughly two thirds average utilisation that is cheaper than provisioning the peak; above it you are paying a premium for headroom you are already using. The 10% floor matters too: an idle container on autoscale still bills a tenth of its maximum, forever.
manual 20,000 RU/s billed always
autoscale max(10%, use) x 1.5
at 40% use 12,000 RU/s billed, cheaper
at 80% use 24,000 RU/s billed, more expensiveA read replica costs the RU/s a second time. Enabling multi-region writes costs it again on top, so three regions with writes is six times the single region figure. It also moves conflict resolution into the application, which is a design change rather than a setting. A single write region with read replicas is most of the availability benefit at a fraction of the price and with no conflicts.
Your actual RU consumption per operation, which depends on the document size, the indexing policy and whether a query is cross-partition. A query that fans out across every partition costs the sum of what each one charges, and the indexing policy alone can double or halve a write's cost. This models the provisioning arithmetic. Measure the rest with the RU charge header on real requests, which every SDK exposes and almost nobody reads.