Azure Cosmos DB Monitoring: RU Consumption and Autoscale Cost Optimization

Azure Cosmos DB’s Request Unit billing model creates a cost trap that most teams discover only after their first production month. A single poorly indexed query or an unbalanced partition key can push normalized RU consumption to 100% in seconds, triggering 429 rate limit errors and autoscale spikes that triple your bill before anyone notices. Microsoft’s own documentation confirms that autoscale only kicks in when normalized RU consumption stays at 100% for a sustained period in a 5 second interval, meaning momentary spikes can burn through provisioned capacity without triggering the scaling you thought you paid for.

This guide covers how to monitor RU consumption at the partition level, when autoscale actually saves money versus when it costs more, and the specific metrics and alert thresholds that prevent bill shock in production. Every pricing figure and cost scenario is sourced from Azure’s public rate cards as of May 2026, with links to verify current rates.

What Is Request Unit (RU) Consumption in Azure Cosmos DB

Request Units are Azure Cosmos DB’s currency for measuring database operations. Every read, write, query, or stored procedure execution consumes a specific number of RUs based on the resources it requires: CPU cycles, memory, and IOPS. A point read of a 1 KB document costs 1 RU. Writing that same document costs approximately 5 RUs. Running a complex query with multiple filters and aggregations can consume hundreds or thousands of RUs depending on the query plan and data scanned.

The reason Azure abstracts performance into RUs rather than exposing raw CPU or memory limits is consistency. The same operation on the same data will always consume the same number of RUs, regardless of which Azure region or physical partition serves the request. This predictability is valuable for capacity planning, but it also creates a billing dynamic where inefficient queries or poor partition key design directly translate to higher costs.

Cosmos DB offers three throughput modes: provisioned throughput (manual), autoscale provisioned throughput, and serverless. Provisioned throughput reserves a fixed number of RU/s per hour and charges you whether you use them or not. Autoscale adjusts RU/s automatically between 10% and 100% of a defined maximum, billing you for the highest RU/s reached in each hour. Serverless charges only for RUs consumed on demand with no upfront reservation. Each mode fits different workload patterns, and choosing wrong creates either wasted capacity or throttling.

How RU Consumption Maps to Cost

Azure Cosmos DB pricing for provisioned throughput is $0.008 per 100 RU/s per hour in single write region configurations. For a container provisioned at 10,000 RU/s, that translates to $58.40 per month in the West US region. Autoscale provisioned throughput costs 1.5x the manual rate, or $0.012 per 100 RU/s per hour, meaning the same 10,000 RU/s maximum costs $87.60 per month if autoscale is enabled.

Multi region write configurations double the per-RU cost. A container with 10,000 RU/s provisioned across two regions with multi region writes enabled costs $0.016 per 100 RU/s per hour, or $116.80 per month. Storage adds $0.25 per GB per month for transactional storage and $0.02 per GB per month for analytical storage. Egress from Azure to the internet incurs bandwidth charges starting at $0.05 per GB after the first 5 GB per month.

Pricing based on Azure public rate cards as of May 2026 for West US region. Multi region, availability zone, and enterprise tier configurations incur additional charges. Verify current rates at [Azure Cosmos DB pricing page](https://azure.microsoft.com/en-us/pricing/details/cosmos-db/).

RU Consumption vs. Normalized RU Consumption

Azure Monitor surfaces two related but distinct metrics: RU consumption and normalized RU consumption. RU consumption shows the absolute number of RUs consumed by operations in a given time window. Normalized RU consumption is a percentage metric between 0% and 100% that represents the maximum RU/s utilization across all physical partitions in that time window.

Normalized RU consumption is the signal that matters for understanding whether you are hitting capacity limits. If a container is provisioned with 10,000 RU/s distributed across 10 physical partitions, each partition gets 1,000 RU/s. If one partition consumes 800 RU/s in a given second while the others consume 200 RU/s, the normalized RU consumption metric reports 80% because the busiest partition used 80% of its allocated capacity. This is why a hot partition, a single logical partition key that receives disproportionate traffic, can push normalized RU consumption to 100% even when total RU consumption across all partitions is well below the provisioned limit.

How Azure Cosmos DB Autoscale Works and When It Scales

Autoscale provisioned throughput adjusts RU/s automatically between 10% and 100% of a user defined maximum. If you configure a container with autoscale max RU/s of 20,000, Cosmos DB can scale the container between 2,000 RU/s and 20,000 RU/s based on demand. Billing reflects the highest RU/s reached in each hour. If the container scales to 15,000 RU/s for even one second during an hour, you pay for 15,000 RU/s for that entire hour at the autoscale rate.

The critical detail most teams miss is the autoscale trigger threshold. Azure’s documentation states that autoscale only scales RU/s to maximum throughput when normalized RU consumption stays at 100% continuously for at least 5 seconds. Momentary spikes that hit 100% for 1 or 2 seconds do not trigger scaling to max RU/s. Instead, the system scales to a value higher than the previously scaled RU/s but lower than max, attempting to absorb the spike without incurring full max RU/s cost.

This behavior is designed to be cost friendly, but it creates a trade off. If your workload has very short traffic spikes, brief bursts where a single partition maxes out for 2 or 3 seconds then drops, autoscale may not scale up fast enough. You will see 429 rate limit errors during those spikes even though you configured autoscale. The application must retry those requests, adding latency and potentially degrading user experience.

Autoscale Cost vs. Manual Provisioned Throughput Cost

Autoscale costs 1.5x the manual provisioned rate. For a workload that consistently uses 80% to 100% of provisioned RU/s, manual provisioned throughput is cheaper because you avoid the 50% autoscale premium. For workloads with predictable daily traffic patterns, low overnight and high during business hours, autoscale saves money by scaling down overnight and scaling up during peak.

Consider a scenario: a container configured with manual provisioned throughput at 10,000 RU/s costs $58.40 per month. The same container configured with autoscale max RU/s of 10,000 costs $87.60 per month if it consistently scales to 10,000 RU/s every hour. But if the workload only requires 10,000 RU/s for 8 hours per day (business hours) and drops to 2,000 RU/s the remaining 16 hours, autoscale saves significantly. At 10,000 RU/s for 8 hours per day, you pay for 240 hours per month at 10,000 RU/s and 480 hours at 2,000 RU/s. Total cost is approximately $43.80 per month, 25% cheaper than manual provisioning at the peak rate.

This estimate models a predictable daily traffic pattern with distinct peak and off-peak periods. Workloads with frequent unpredictable spikes or steady baseline usage may not see the same savings.

The break-even point for autoscale versus manual provisioning depends on how many hours per month the workload runs at less than 67% of max RU/s. If the workload spends more than 67% of hours at lower RU/s, autoscale is cheaper. If it consistently runs above 67%, manual provisioning avoids the autoscale premium.

When Autoscale Does Not Scale and You Still Pay

Autoscale only adjusts RU/s based on actual consumption load. It does not account for inefficient queries, missing indexes, or poor partition key distribution. If normalized RU consumption hits 100% because a single partition is overloaded (hot partition), autoscale will scale the entire container’s RU/s up, but the additional RU/s are distributed evenly across all partitions. The hot partition gets more RU/s, but so do the underutilized partitions. You pay for the increased RU/s across the entire container even though most partitions do not need it.

A Reddit thread documents a scenario where a development team saw their Cosmos DB bill jump from $900 to $8,000 in a single month after deploying a new feature that introduced a query without a composite index. The query scanned large portions of a partition on every request, maxing out normalized RU consumption and triggering autoscale to maximum RU/s for hours at a time. The query itself was the problem, not the traffic volume. Autoscale did its job by preventing 429 errors, but it did so by provisioning capacity the team did not intend to pay for. The fix was adding a composite index and rewriting the query, not increasing max RU/s.

Monitoring Normalized RU Consumption at the Partition Level

Azure Monitor provides the Normalized RU Consumption metric at both the container level and the partition key range level. Partition key range is the internal identifier for a physical partition. Each partition key range can hold up to 20 GB of data and supports up to 10,000 RU/s in a single region write configuration.

To monitor RU consumption effectively, you must track normalized RU consumption by partition key range, not just at the container level. A container-level view shows overall utilization, but it hides hot partitions. If one partition consistently runs at 100% while others sit at 20%, the container-level metric may average out to 60%, making the problem invisible.

Navigate to Azure Monitor in the Azure portal, select your Cosmos DB account, then Metrics. Choose the Normalized RU Consumption metric and apply a split by PartitionKeyRangeId. This surfaces per-partition utilization. Look for partition key ranges that consistently show normalized RU consumption at or near 100% while others remain low. This is the signature of a hot partition caused by unbalanced partition key design or a query pattern that targets a single logical partition key.

Alert Thresholds for RU Consumption

Set alerts on normalized RU consumption at two levels: container level and partition level. At the container level, alert when average normalized RU consumption exceeds 80% for more than 5 minutes. This indicates sustained high utilization and gives you lead time before hitting capacity limits. At the partition level, alert when any single partition key range exceeds 90% normalized RU consumption for more than 2 minutes. This flags hot partitions early before they cause 429 errors.

Microsoft’s documentation recommends monitoring 429 rate limit errors using the Total Requests metric filtered by status code 429 and split by operation type. A small percentage of 429s, 1% to 5% of total requests, is acceptable because Cosmos DB SDKs retry automatically. If 429s exceed 5% of requests or if end to end latency increases beyond acceptable thresholds, investigate the root cause. Common causes include missing indexes, inefficient queries, hot partitions, or provisioned RU/s set too low for actual workload demand.

Identifying Hot Partitions with Diagnostic Logs

Azure Monitor diagnostic logs provide request-level telemetry that shows RU consumption per operation along with the partition key value. Enable diagnostic logs by navigating to Diagnostic settings in your Cosmos DB account and streaming logs to a Log Analytics workspace. Query the CDBDataPlaneRequests table for high RU consumption operations.

Example query to find the top 10 highest RU consuming requests in the past hour:

CDBDataPlaneRequests
| where TimeGenerated > ago(1h)
| top 10 by RequestCharge desc
| project TimeGenerated, OperationName, ActivityId, RequestCharge, PartitionKey, StatusCode

This surfaces the exact operations and partition keys consuming the most RUs. If the same partition key appears repeatedly in the top results, you have a hot partition. If a specific operation type, such as a query, consistently shows high RequestCharge values, the query plan is inefficient and needs optimization.

Cost Optimization Strategies for RU Consumption

Reducing RU consumption directly lowers Cosmos DB cost. The most effective strategies focus on query efficiency, indexing, and partition key design.

Optimize Queries and Indexing Policies

Every query in Cosmos DB consumes RUs based on the data scanned and the complexity of operations performed. Queries without filters that scan entire containers consume hundreds of thousands of RUs. Adding a filter on an indexed property reduces RU consumption by narrowing the scan scope. Composite indexes allow efficient filtering on multiple properties simultaneously, dramatically lowering RU cost for range queries and sorts.

Azure’s query metrics API returns the RU charge for each query execution. Use this to identify expensive queries. If a query consumes more than 100 RUs, examine the query plan and indexing policy. Add composite indexes for combinations of properties frequently filtered or sorted together. For example, if queries commonly filter by CategoryID and sort by Price, create a composite index on [/CategoryID/?, /Price/?]. This reduces the query from a full partition scan to an efficient index seek.

Indexing policies in Cosmos DB default to indexing all properties automatically. This simplifies development but increases write RU consumption and storage cost. Review your indexing policy and exclude properties that are never queried. Write operations consume fewer RUs when fewer properties are indexed.

Choose the Right Partition Key

Partition key design determines how data and throughput distribute across physical partitions. A good partition key has high cardinality (many distinct values), evenly distributes request volume across partitions, and allows efficient querying by including the partition key in most queries.

A common mistake is choosing a partition key with low cardinality, such as a status field with only three possible values. This creates a small number of logical partitions that cannot scale beyond the per-partition RU/s limit of 10,000 RU/s. If one status value receives 80% of traffic, that single partition maxes out while others sit idle. Cosmos DB cannot rebalance this because each logical partition maps to one physical partition.

A better partition key for an e-commerce order system is CustomerId or a composite of CustomerId and OrderDate. This spreads orders across many partitions, and most queries (retrieve orders for customer X, retrieve orders placed on date Y) can include the partition key, avoiding cross partition queries that cost more RUs.

If you identify a hot partition in an existing container, the only solution is to migrate data to a new container with a better partition key. Cosmos DB does not support repartitioning in place. Plan this migration carefully, use the bulk executor library or Azure Data Factory to parallelize the copy, and validate query performance in the new container before cutting over production traffic.

Use Serverless for Unpredictable or Low-Volume Workloads

Serverless Cosmos DB charges only for RUs consumed with no upfront provisioning. Cost is $0.25 per million RUs consumed plus storage at $0.25 per GB per month. Serverless works well for development environments, infrequent batch jobs, or applications with highly variable traffic where provisioning capacity in advance wastes money.

Serverless has limits: maximum 5,000 RU/s per partition, no SLA guarantees on latency, and no support for multi region writes. For production workloads requiring consistent performance or global distribution, provisioned throughput or autoscale is the better choice. But for workloads that run intermittently or have long idle periods, serverless eliminates the cost of provisioned capacity sitting unused.

Serverless pricing based on Azure public rate card as of May 2026. Verify current rates at [Azure Cosmos DB serverless pricing](https://azure.microsoft.com/en-us/pricing/details/cosmos-db/serverless/).

Right-Size Provisioned RU/s Using Azure Monitor Data

Many teams overprovision RU/s out of caution, setting manual throughput higher than actual peak demand. Use Azure Monitor historical data to identify true peak utilization. Query the Normalized RU Consumption metric over the past 30 days and find the 95th percentile. If the 95th percentile is 60% of provisioned RU/s, you are overprovisioned by 40%. Reduce manual RU/s to align with actual demand, or switch to autoscale and set max RU/s at the 95th percentile level.

Be cautious with this approach during traffic growth periods or before seasonal peaks. Underprovisioning leads to 429 errors and degraded user experience. Always leave headroom for traffic spikes, typically 20% to 30% above observed peak, unless autoscale is enabled to handle spikes automatically.

Monitoring Azure Cosmos DB with CubeAPM

CubeAPM provides unified monitoring for Azure Cosmos DB alongside application traces, logs, and infrastructure metrics, all in a single self hosted platform. Unlike cloud-only SaaS tools that charge per host and per feature, CubeAPM uses flat ingestion-based pricing at $0.15 per GB with unlimited retention and no per-seat fees.

CubeAPM connects to Azure Cosmos DB via OpenTelemetry or Prometheus exporters, collecting metrics on RU consumption, normalized RU consumption, request latency, throttling rate (429 errors), storage utilization, and partition-level performance. Dashboards visualize RU consumption trends, partition hotspots, and query performance in the context of application-level distributed traces, so you can correlate a spike in RU usage with the specific API endpoint or database query that caused it.

Alerts in CubeAPM trigger on any metric or combination of metrics without requiring separate query languages. Set an alert for normalized RU consumption exceeding 90% on any partition for more than 2 minutes, and route notifications to Slack, PagerDuty, or email with full trace context included. This eliminates the need to toggle between Azure Monitor, Application Insights, and log analytics workspaces to understand what broke.

Because CubeAPM runs inside your own cloud VPC or data center, telemetry data never leaves your infrastructure. This avoids the $0.10 per GB Azure egress charges incurred when sending metrics and logs to external SaaS platforms. For a workload ingesting 30 TB per month of observability data, running CubeAPM self-hosted saves approximately $3,000 per month in egress fees alone compared to sending the same data to Datadog or New Relic.

CubeAPM also supports monitoring other Azure services including Azure Kubernetes Service (AKS), Azure SQL Database, Azure Functions, and Azure Service Bus, making it a unified platform for Azure infrastructure and application observability without vendor lock-in or unpredictable SaaS pricing growth.

Conclusion

Azure Cosmos DB’s RU consumption model delivers predictable performance but creates cost traps that appear only in production. Monitoring normalized RU consumption at the partition level, understanding when autoscale actually scales versus when it bills without scaling, and optimizing queries and partition keys are the three actions that prevent bill shock. Autoscale saves money for workloads with clear peak and off-peak patterns but costs more for steady-state workloads that consistently run above 67% utilization. Hot partitions caused by poor partition key design waste RUs by distributing capacity unevenly, and the only fix is migrating to a new container with a better key.

Set alerts on partition-level normalized RU consumption above 90% for more than 2 minutes and container-level consumption above 80% for more than 5 minutes. Use diagnostic logs to identify the exact queries and partition keys consuming the most RUs, then optimize indexing policies and query filters to reduce scan scope. For workloads with unpredictable traffic or long idle periods, serverless eliminates wasted provisioned capacity. For predictable traffic patterns with distinct peaks, autoscale reduces cost by scaling down during off-peak hours.

Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve. Features, pricing, and plan limits can change over time. Always verify the latest information directly with the vendor before making purchasing or deployment decisions.

Frequently Asked Questions