How Azure Cosmos DB Pricing Works (and 7 Ways to Save)

The cost of an operation in Azure Cosmos DB is consistent and predictable. Inserting, updating, or deleting a document of a given size will always consume the same number of RU/s. Similarly, running the same query over the same data will always result in the same RU charge. 

vCore pricing

For PostgreSQL and MongoDB (vCore) APIs, Azure Cosmos DB bills based on compute and memory per node. You’re charged according to the number and size of vCore nodes you provision. This model suits apps that need SQL-like features or high performance via PostgreSQL or MongoDB vCore. 

2. Storage pricing 

With Azure Cosmos DB, you’re billed monthly for the total GB of data stored in both transactional and analytical storage. Though, most costs derive from consumed storage (pay-as-you-go).

The more you store, the more you pay.

To simplify, if your database has 0 GB stored, the storage costs are essentially $0.

For most regions, the transaction price is $0.25 per GB per month.

These prices apply to NoSQL, MongoDB (RU), Cassandra, Gremlin, and Table APIs

3. Bandwidth pricing 

Cosmos DB bandwidth pricing follows a pay-as-you-go model and depends.

Data going into (Ingress) Azure is free (as you can see below). 

The same is not true, however, when data leaves Azure or moves between Azure regions (across regions and availability zones within Azure’s WAN).  

Then, the following transfer costs are incurred: 

Azure Cosmos DB pricing tiers

For database operations, you can select between one of the two models for managing throughput: 

• Provisioned Throughput 
• Serverless (consumption-based)

Provisioned Throughput 

Provisioned throughput is the RU/s capacity you assign for database operations. Azure Cosmos DB’s provisioned throughput model gives you a set number of Request Units per second (RU/s), reserved in advance and charged by the hour. 

Example: if you provision 100 RU/s, you can consume up to 100 RUs every second. If your operations exceed this limit, they’re throttled and must retry in the next second once the RU bucket refills. 

Billing is based on the maximum RU/s you’ve provisioned during any given hour, regardless of actual usage. So, even if you don’t use the full capacity, you’re billed for the highest throughput allocated in that hour. 

Standard (Manual) Provisioned Throughput 

You can directly manage capacity with standard or so-called “manual” provisioned throughput. This can be manually configured on your container or database using the Azure portal. 

Use case: It’s often best for workloads with a consistent baseline traffic and require high-performance SLAs. 

The table below breaks down the prices of standard provisioned throughput: 

*Prices are for the region of West Europe

Autoscale Provisioned Throughput 

Autoscale adjusts RU/s automatically based on workload demand. You define a max limit (starting at 1,000 RU/s), and billing reflects the highest usage per hour between 10–100% of that limit.  

This removes the need for manual scaling and helps manage costs for unpredictable workloads.  

Look at the table below for the prices:

*Prices are for the region of West Europe 

Besides, Provisioned throughput often doesn’t suit:

• Workloads with only occasional database operations
• Lower performance requirements

 Let us introduce you to Serverless.

Serverless Consumed Throughput 

Applications with low-traffic workloads that see occasional bursts benefit from the serverless model. Serverless is ideal for less demanding workloads that see occasional bursts. 

You don’t need to plan capacity or manage resources; it automatically scales and charges only for what you use (pay-as-you-go) per operation and storage consumed. 

Again, with no minimum usage, it suits small apps that run irregularly and don’t need constant throughput. 

And even though the unit cost is higher, you only pay for the RUs consumed per operation. That makes it a cost-effective choice for infrequent or unpredictable workloads.

Azure Free Tier 

Is Azure Cosmos DB free forever? The short answer = YES

The Azure Free Tier lets you build, test or run small applications on Azure Cosmos DB at no cost for as long as you need. It applies to NoSQL, MongoDB, Cassandra, Gremlin and Table APIs and supports provisioned and autoscale throughput in single or multi-region setups. 

Mind you, the free tier has its limitations. You get 1000 RU/s and 25 GB of storage free per account. Anything beyond that is charged at standard rates. 

Moreover, it comes with the same features as a regular Cosmos DB account (SLAs, global distribution, high availability, etc). You can enable one free tier account per Azure subscription, but you must opt in when creating it.

Azure Cosmos DB free tier for 30 days 

You can try a free 30-day trial for Azure Cosmos DB without an Azure subscription. Use it to explore or run non-production databases (testing or dev environments). 

By now, you know there are various ways to try Azure Cosmos DB. But when do you choose which one?  

The image below shows you exactly when to use each of Azure Cosmos DB’s free offers:  

Multi-region writes (Geo-Replication) 

You have the option to enable availability zones in your Cosmos DB account. This replicates data across multiple zones within a single region. So, if one region fails, you can fall back on another. 

If your application requires global write capabilities, you can enable multi-region writes. This promotes high availability and low latency by turning every region into a writable primary. Do not forget that this comes at a cost (doubling your total Cosmos DB expense).

7 Azure Cosmos DB cost-saving tips 

Remove unused databases or containers 

One of the simplest ways to save in Cosmos DB is by getting rid of unused databases or containers. These often accumulate over time without notice.

Check utilisation regularly (if Provisioned Throughput is manual) 

If you’re using standard provisioned throughput, which is manually, monitor your actual usage regularly. Before scaling throughput up or down, check metrics like request volume and RU/s consumption per collection. 

If a collection shows consistently low utilisation – it’s a strong signal that you can safely reduce throughput and cut costs. Always validate usage patterns before making changes.

Use Azure Reserved Capacity 

With reserved capacity, you can save 20–65% by committing to 1 or 3 years of provisioned throughput (RU/s) in Azure Cosmos DB. This discount applies across all APIs (MongoDB, Cassandra, SQL, Gremlin, and Table) and is available worldwide. Learn more about Azure Reservations.

Reduce storage costs by trimming backups and cleaning up unused data 

In Azure Cosmos DB, storage and backup costs can quickly add up to your bill. For storage, identify high-usage collections that might need clean-up or optimisation. 

Also, check your Backup and Restore settings. In Cosmos DB, you receive two free snapshots. However, if you set up frequent backups (e.g. hourly) with a long retention period (e.g. 7 days), you could easily end up with 168 snapshots, becoming expensive. 

Only increase backup frequency or retention if it’s needed for business or compliance reasons. Otherwise, stick with defaults or reduce retention to avoid paying for excess snapshot storage.

Review regional usage 

If multi-region writes are enabled, it can make each region a primary region, doubling the cost of your Cosmos DB account. Adding new regions increases costs, so think twice before doing so.  

Also, review regional usage regularly. If a region shows low or no activity, consider removing it to avoid unnecessary replication costs. But before you do so, weigh your uptime needs. It may be there as a standby for high availability. 

Estimate costs with calculators 

RU consumption directly affects Cosmos DB cost. Use these calculator tools to model your workload: 

• Capacity calculator
• Azure pricing calculator 

Try to run sample workloads to estimate RU/s for reads, writes, and queries.

Optimise Bandwidth usage 

Cross-region data transfers increase costs. You can reduce this by: 

• Minimising the number of replication regions 
• Avoiding unnecessary inter-region writes or reads 
• Using multi-region replication only when latency or redundancy justifies it 

Keep your traffic local unless you have a clear reason not to. 

Provisioned Throughput vs Autoscale: Which one should you use? 

If your application has consistent, predictable throughput needs, you should provision slightly above that level to avoid throttling.  

But if your workload varies – say, it's active only during office hours or weekends – then having high provisioned throughput all the time leads to waste (as visualised below). 

Obviously, you’d want to avoid that…

Cosmos DB lets you adjust provisioned throughput manually at any time using the Azure portal, CLI, or automation.

That means you can scale it up or down to match usage and avoid paying for unused capacity. 

Most workloads of modern apps, however, don't look like this. Instead, they have much more fluctuating usage flows, with greater drops and spikes. 

Therefore, choose Cosmos DB autoscale provisioned throughput for your workloads with fluctuating demand. 

Here, you set a maximum RU/s limit, while Cosmos DB automatically adjusts your throughput based on actual usage. You’re still billed hourly, but only for the throughput used within that range. This gives you flexibility without having to overprovision. 

Despite the slightly higher billing rate (50% as mentioned), autoscale should usually be your default choice (unless you have a highly consistent or predictable workload ofcourse). 

It is just more cost-effective than standard when traffic is unpredictable and not close to maximum capacity most of the time. 

Also, it is good to know that you can switch between manual and autoscale at any time.