Idle Cosmos DB Containers with Provisioned Throughput

Provisioned RU/s is reserved capacity: it is billed every hour for the configured amount whether or not any requests arrive, and it is reserved in every region associated with the account. An idle container provisioned at a few thousand RU/s in a three-region account keeps paying for three times that throughput indefinitely.

Idle throughput is also sticky. The minimum RU/s a container can be lowered to rises with storage and with the highest throughput ever provisioned on it (one hundredth of that peak for manual throughput), so a container that was scaled up for a bulk import may not be able to go back to 400 RU/s. Azure Advisor flags containers with no activity in the past 30 days and recommends lowering their throughput or deleting them.

Provisioned throughput

RU/s configured on a container or shared database, billed hourly at the highest RU/s set in the hour, whether used or not

Regional multiplier

Throughput is reserved in each region of the account, so the hourly total is the configured RU/s times the number of regions

Minimum RU/s

400 RU/s for manual throughput, or higher based on storage and the highest RU/s ever provisioned

Storage

Billed separately per GB per month for data and index in every region

• Review Azure Advisor for 'Consider taking action on the idle Azure Cosmos DB containers', which lists containers with no activity over the past 30 days
• In Azure Monitor, chart Total Requests (TotalRequests) and Total Request Units (TotalRequestUnits) split by DatabaseName and CollectionName over 30 days, alongside Provisioned Throughput (ProvisionedThroughput), and flag containers with near-zero requests
• List containers and databases with dedicated throughput in non-production accounts or with names indicating tests, migrations or backups, and confirm ownership
• Multiply each idle container's RU/s by the number of regions on its account to size the waste, since every region bills the same throughput

• Delete containers that are no longer needed, exporting data first (for example with a change feed or copy job) if it must be retained elsewhere
• If the container must stay but is rarely used, lower its RU/s to the current minimum shown in the portal or SDK, or switch it to autoscale so it bills at 10% of its maximum when idle (at the autoscale rate, which is 1.5 times the manual rate in single-write-region accounts)
• Move low-traffic containers that don't need their own throughput into a shared-throughput database; this requires migrating data to a new container, for example with a change feed-based process. Microsoft does not recommend shared throughput for most active workloads because one container's burst can throttle the others, so reserve it for rarely used containers
• For development and test accounts with sporadic use, consider a serverless account, noting that serverless accounts are single-region and require creating a new account
• Tag containers created for migrations or tests with an owner and expiry date so they are reviewed when the work ends

• Cost recommendations - Azure Advisorlearn.microsoft.com
• Optimizing Throughput Cost - Azure Cosmos DBlearn.microsoft.com
• Optimize Cost for Multi-Region Deployments - Azure Cosmos DBlearn.microsoft.com
• Service Quotas and Default Limits - Azure Cosmos DBlearn.microsoft.com
• Serverless Consumption-Based Account Type - Azure Cosmos DBlearn.microsoft.com
• Azure Cosmos DB pricingazure.microsoft.com