Azure Cosmos DB Account
Does ZopNight manage Azure Cosmos DB Account?
Azure Cosmos DB bills by request units (provisioned RU/s cost the same at 0 percent utilization as at 100) plus storage, and an account cannot be stopped. ZopNight compares 60 days of consumed versus provisioned RU/s per account and flags over-provisioned throughput and autoscale candidates.
Rules that fire on Azure Cosmos DB Account
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only; Cosmos DB accounts cannot be stopped. |
Azure Cosmos DB is a globally distributed, multi-model NoSQL database billed by provisioned or serverless request units. Over-provisioned RU/s on quiet containers is a frequent and expensive form of waste.
Request units bill as provisioned, not as consumed
The Cosmos meter is the request unit. On provisioned throughput, an account or container reserves a number of RU/s and bills for every one of them, every hour, regardless of whether requests arrive. A container provisioned at high throughput serves its idle weekends at exactly its weekday price. Serverless accounts flip the model and bill per request actually made, and autoscale sits between the two, scaling the provisioned number within a configured range. Storage bills separately on consumed data. Multi-region replication multiplies the throughput meter by each added region.
Throughput telemetry and rightsizing evidence
Discovered via Azure Resource Graph with API kind and throughput configuration. Azure Monitor metrics with a 60-day lookback show consumed versus provisioned RU/s, Cost Management billing attributes spend, and recommendation rules flag throughput over-provisioning. Because Cosmos DB accounts cannot be stopped, savings come from throughput rightsizing and autoscale adoption rather than scheduling: the recommendation output is a smaller or adaptive RU/s number, not an off-hours window.
Where RU/s overspend hides
The characteristic leaks: containers provisioned for a load test or launch spike and never dialed back; throughput set per container across dozens of small collections, each carrying its own idle floor; and steady-state manual throughput on workloads whose traffic is actually spiky, where autoscale would track the curve instead of paying for its peak continuously. Extra read regions on non-production accounts quietly multiply all of it.
Inspecting Cosmos accounts in the portal
Azure portal → Azure Cosmos DB lists every account with its API kind. Inside an account, Data Explorer shows per-database and per-container throughput settings, and the Metrics blade charts normalized RU consumption, the direct visual of how much of the provisioned meter is being used.