Cosmos DB

This page will provide information and links about how to optimize Cosmos DB for cost

Factors that affect cost

Things to Think about

Provisioned Throughput (RU/s)

Cosmos DB charges for Request Units per second (RU/s) when using the Provisioned Throughput model.

• Factors:

  • RU/s provisioned per container or shared across a database

  • Minimum RU/s is required (400 RU/s per container or 100 RU/s shared)

  • Always-on cost, even if not used

  • Cost scales linearly with RU/s

• Tips:

  • Use autoscale to scale between 10% and 100% of max RU/s

  • Consolidate collections when appropriate

Autoscale vs Manual Provisioning

• Autoscale: Charges for the maximum RU/s used in the hour

• Manual Provisioning: Charges for the provisioned RU/s regardless of usage

• Autoscale benefits: Great for spiky workloads

• Manual benefits: Better for predictable, steady workloads

Storage

You pay for the total amount of data stored, including:

• Raw data

• Indexes

• Metadata

• TTL-expired data (if not yet removed)

Pricing is per GB/month, and differs by API and region.

Multi-region Replication

If you need multi-region then your costs will increase to cover the additional usage.

• Cosmos DB supports global distribution (multi-region writes/reads)

• Each additional region adds storage and RU/s costs

• Write regions are more expensive than read-only regions

Consistency Levels

Cosmos DB offers five consistency levels, each of them will affect the number of RU used to access data.

1. Strong

2. Bounded staleness

3. Session

4. Consistent prefix

5. Eventual

• Impact: Stronger consistency can lead to higher RU usage due to replication/coordination overhead

API Choice

There are a number of different flavours of the Cosmos DB API that you can use.  The chosen API will affect the costs you incur based on pricing and utilization patterns for the data.

• Cosmos DB supports multiple APIs:

  • SQL (Core)

  • MongoDB

  • Cassandra

  • Gremlin (Graph)

  • Table

Pricing may vary slightly between APIs due to differences in implementation (e.g., indexing, data model).

Query Patterns and RU Consumption

• Complex queries and large item sizes consume more RUs

• High frequency reads/writes can spike usage

• Indexing policy affects RU consumption (more indexes = higher cost per write)

Additional Features That Add Cost

• Change Feed: No direct cost, but reading it consumes RUs

• Analytical Store (for Synapse Link): Adds cost for storage and queries

• Backup Policy:

  • Periodic backups are included

  • Continuous backup is more expensive (billed based on storage and retention period)

Common Optimizations

🔢 Provisioned Throughput (RU/s)

• Use Autoscale RU/s if your workload is spiky or varies by hour/day

• Use Manual RU/s for steady, predictable workloads

• Share throughput at database level instead of per container where possible

• Consolidate containers with similar access patterns into a shared throughput database

• Right-size RU/s by analyzing actual usage vs provisioned (Azure Monitor or Metrics)

📁 Data and Storage

• Compress data and use efficient schemas to reduce storage size

• Remove unused data regularly (use TTL to expire stale data)

• Optimize indexing to reduce storage and RU consumption on writes

• Avoid storing large blobs (store in Azure Blob Storage instead, link from Cosmos)

🌍 Global Distribution

• Limit regions to only what’s required for your business continuity / latency goals

• Avoid write regions unless necessary, as they incur higher costs

• Use regional pricing calculator to compare storage/throughput costs across locations

🧠 Query Optimization

• Avoid full scans – always filter with partition keys where possible

• Use projections (SELECT only needed fields) to minimize RU usage

• Review and test indexing policies – remove unused indexes

• Use server-side stored procedures for batch operations to reduce network & RU cost

🔁 Change Feed and Integration

• Throttle change feed consumption to avoid spikes in RU usage

• Use checkpoints in change feed processing to avoid reprocessing data

• Evaluate Synapse Link use – enable analytical store only when needed

📦 API and Features

• Pick the right API (e.g., Core (SQL) vs MongoDB) based on your use case

• Disable multi-master write unless absolutely necessary

• Turn off continuous backup unless you need point-in-time restore (use periodic)

📊 Monitoring and Alerts

• Set up cost alerts for Cosmos DB resources using Cost Management + Azure Monitor

• Track RU usage vs provisioned via Metrics or Azure Advisor

• Review Azure Advisor recommendations for right-sizing or unused regions

🧪 Bonus: Experimental/Dev/Test Environments

• Use emulator locally for development/testing

• Move dev/test workloads to lower RU settings

• Tag environments clearly and exclude non-prod from high-availability setups

💰Azure Reservations for Cosmos DB

• Cosmos DB Reserved Capacity lets you commit to a specific amount of provisioned RU/s for 1 or 3 years, in exchange for a significant discount.

• Discount applies to provisioned throughput (manual or autoscale max RU/s), not serverless or consumption-based usage.

You would buy a reservation and scope it to a subscription or management group or make it shared and then its R/U allocation would apply to Cosmos DB accounts that would fall within its scope.

A reservation is a good choice in the following scenarios:

• Stable workload

• Predictable growth

• Provisioned RU

How can Turbo360 help

• Turbo360 scheduler can help with changing R/U allocations for CosmosDB on a time based schedule

• Cost Analysis will help you view cost usage

Useful Resources

In the below video we talk to the CosmosDB team about cost optimizations.