Azure Cosmos DB for MongoDB
Does ZopNight manage Azure Cosmos DB for MongoDB?
Azure Cosmos DB for MongoDB (vCore) bills per cluster tier and shard, around the clock, not in request units. ZopNight discovers each vCore cluster (`microsoft.documentdb/mongoclusters`) with its tier, shard count and high-availability setting and attributes its spend; no rule evaluates it yet. RU-based Mongo API accounts appear under Azure Cosmos DB Account.
Rules that fire on Azure Cosmos DB for MongoDB
No active rule family targets Azure Cosmos DB for MongoDB today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
Azure Cosmos DB for MongoDB (vCore) is a MongoDB-compatible cluster service: you pick a compute tier and a shard count, and the cluster bills for that capacity whether its databases are busy or silent.
MongoDB syntax, cluster-shaped economics
This is the vCore flavour of the MongoDB API, not the request-unit one. Applications connect with MongoDB drivers and query with MongoDB syntax, and the bill follows the cluster: each shard bills hourly at its tier’s compute rate, doubled when high availability runs a standby, with storage on top. RU-based Mongo API accounts are ordinary Cosmos DB accounts, priced in request units, and appear under Azure Cosmos DB Account in ZopNight.
A distinct cluster type in ZopNight’s inventory
Discovered via Azure Resource Graph as a MongoDB vCore cluster, with its tier, shard count and high-availability setting, and its compute spend attributed per cluster. No Azure Monitor metrics are collected for this type and no recommendation rule evaluates it today. With no stop operation, this type is discovery and cost visibility only; the actionable decision is the tier and shard count, which you review against usage in the portal.
Migration habits that overpay on vCore
The waste patterns are migration-shaped. Sizing the tier to match the old cluster’s peak, rather than measured demand, imports overprovisioning wholesale. Adding shards for growth that never arrived multiplies the hourly rate. And high availability switched on for every cluster doubles the compute bill of clusters that never needed a standby.
Finding vCore clusters in the portal
In the Azure portal, open the cluster resource (type Azure Cosmos DB for MongoDB (vCore)); its settings show the compute tier, storage, shard count and high-availability mode that drive the bill.