# Azure Cosmos DB for MongoDB

> Cosmos DB for MongoDB speaks the MongoDB wire protocol on top of the standard Cosmos request-unit meter, so idle provisioned RU/s bill exactly as on any Cosmos account. ZopNight discovers these accounts as a distinct API kind, applies the 60-day RU/s comparison, and surfaces the same throughput-rightsizing recommendations.

Source: https://zop.dev/integrations/azure/cosmosdb-mongo
Updated: 2026-08-19

---

Cosmos DB for MongoDB exposes the Cosmos engine through MongoDB wire-protocol compatibility. It shares the request-unit billing model, so idle provisioned throughput costs the same as on any Cosmos account.

## MongoDB syntax, request-unit economics

Compatibility here is protocol-deep, not billing-deep. Applications connect with MongoDB drivers and query with MongoDB syntax, but underneath every operation is priced in request units, and provisioned RU/s reserve capacity that bills hourly whether the collections are busy or silent. Teams arriving from self-hosted MongoDB or Atlas often expect instance-shaped pricing (a server size, a cluster tier) and instead get a throughput reservation per database or collection whose idle cost is invisible until the first full month's invoice.

## A distinct API kind in ZopNight's inventory

Discovered via Azure Resource Graph as a distinct API kind, separate from core Cosmos accounts. Azure Monitor metrics with a 60-day lookback, Cost Management billing attribution, and throughput-rightsizing recommendations all apply, so a Mongo-API account gets the same consumed-versus-provisioned RU/s scrutiny as its SQL-API siblings. With no stop operation on any Cosmos account, this type is discovery and cost visibility only; the actionable output is a right-sized or autoscaled throughput number.

## Migration habits that overpay on the Mongo API

The waste patterns are migration-shaped. A lift-and-shift from MongoDB typically creates one Cosmos collection per Mongo collection, each with its own provisioned throughput, so a schema with many small collections carries many idle RU/s floors at once. Sizing throughput to match the old cluster's peak, rather than measured demand, imports overprovisioning wholesale. And developer or staging accounts on manual provisioned throughput sit idle nights and weekends at full reservation price, when serverless would bill them nearly nothing.

## Finding Mongo-API accounts in the portal

Azure portal → Azure Cosmos DB lists all accounts; the API column identifies those on the MongoDB API. Within an account, per-collection throughput settings live in Data Explorer, which is where oversized reservations from an old migration are usually found still intact.