Request units connect application work to cost
Azure Cosmos DB normalizes database operations through request units. Different operations consume different amounts. A point read of a small item is typically cheaper than a complex query scanning partitions. Larger items, writes, consistency choices, indexing, and query shape can increase request-unit consumption.
This makes request units a bridge between code and economics.
Measure RU consumption by database, container, operation, and time. Identify the queries and request patterns responsible for peaks and growth. Compare successful and throttled requests. Where application telemetry allows, map them to user actions or business processes.
Do not evaluate average RU use alone. A workload may have low daily average and sharp peaks that require autoscale or another capacity strategy. A steady baseline may justify provisioned throughput and a commercial commitment. The pattern matters as much as the total.
Choose throughput mode for the demand pattern
Azure Cosmos DB offers throughput choices intended for different workload shapes. Current availability, capabilities, limits, and pricing should be validated against Microsoft documentation for the selected API and region.
The economic reasoning is straightforward:
- stable continuous demand can benefit from appropriately sized provisioned throughput;
- variable demand may benefit from autoscale when peaks and idle periods justify the premium and flexibility;
- intermittent or low-volume use may fit serverless where supported;
- shared database throughput can improve pooling but may make one container’s demand affect others;
- dedicated container throughput improves isolation but can strand capacity.
Model real hourly or finer-grained behavior. A monthly average hides whether capacity was needed continuously or only for a short burst.
Suppose a workload averages 8,000 RU/s but peaks at 40,000 for twenty minutes each hour. Fixed capacity at the peak can be expensive. Autoscale may fit—but only after the team confirms that the peak represents useful demand rather than an inefficient query or retry storm.
Capacity selection comes after application review, not before it.
Partitioning determines how efficiently demand is served
The partition key affects data distribution, scalability, and query behavior. A poor key can create hot partitions, uneven throughput use, and cross-partition queries.
An effective key has sufficient cardinality, distributes storage and request volume, and supports common access patterns. The correct choice is application-specific and difficult to change after data grows.
Look for:
- partitions receiving a disproportionate share of requests;
- keys that grow without bound in one logical partition;
- frequent queries that do not include the partition key;
- transactional needs that span partitions;
- skew caused by a small set of customers or dates; and
- storage growth that threatens design limits.
Do not choose a key only because it evenly distributes current data. If every common query must fan out across partitions, the application may spend more RU and deliver slower responses.
For an existing workload, redesign may require a new container and data migration. Compare the implementation effort and risk with the recurring cost and performance benefit.
Query and item design can be the largest lever
A point read using an item ID and partition key is economically different from a broad query. Application teams should know when they are using each pattern.
Review high-RU operations:
- Can the application address the item directly?
- Is the query filtering on the partition key?
- Are unnecessary fields or large items being read?
- Does a request retrieve far more records than the user needs?
- Are pagination and continuation handled efficiently?
- Is the same data repeatedly queried when a controlled cache would help?
- Are retries amplifying demand?
Item design matters because larger payloads affect reads, writes, network, and storage. Embedding related data can reduce joins and requests but may increase update cost and duplication. Splitting data can reduce item size but require more operations.
Optimize for the actual access pattern and consistency requirement. There is no universal rule that denormalization or normalization is always cheaper.
Indexing should serve queries you actually run
Indexing improves query performance but adds write and storage cost. A broad default policy can index paths never queried. An overly narrow policy can make important queries expensive or unsupported.
Analyze query patterns before changing indexing. Exclude paths that contain large or frequently changing values when they are not used for filtering or sorting. Add composite or other supported indexes when they materially improve known queries. Test write RU, query RU, index transformation, and application behavior.
Index changes can have substantial operational effects on large containers. Plan and observe them rather than applying a generic optimization rule.
The same governance principle applies here: every retained index should have a purpose, and every exclusion should be validated against real queries.
Regions and consistency are product decisions
Adding regions can improve availability, locality, and disaster recovery. It also increases cost through replicated throughput, storage, and potentially network behavior.
Before changing regional configuration, document:
- user and application geography;
- read and write locations;
- failover and recovery objectives;
- data residency;
- latency requirements;
- consistency requirements; and
- active-active or active-passive behavior.
Do not remove a region because it appears lightly used without understanding the resilience design. Conversely, do not maintain a multi-region architecture whose business requirement has disappeared.
Consistency choices can affect application behavior and request-unit consumption. Select the model required for correctness; then design access efficiently within that constraint. Cost should inform the choice but should not weaken data semantics the product depends on.
Storage, backup, and change streams add to the system cost
Throughput usually receives most attention, but data volume can grow continuously. Large items, duplicate documents, retained historical versions, analytical copies, and change-feed consumers can create storage and processing cost.
Map the full data lifecycle:
- primary operational data;
- time-to-live and deletion rules;
- backup and restore requirements;
- analytical replication or exports;
- change-feed processing;
- test and development copies; and
- retired containers or accounts.
Time-to-live can automate data expiration where business and compliance rules allow. It should implement an approved policy, not substitute for one.
Examine downstream consumers. A change-feed processor that repeatedly fails and retries can create both database and compute cost. An analytical copy may be valuable but should have an owner and retention purpose.
A workload example
Consider an account costing $64,000 per month. Provisioned throughput represents $48,000, replicated storage $10,000, and connected monitoring and processing $6,000.
Analysis finds:
- one query accounts for 28 percent of RU consumption;
- a hot customer partition causes throttling;
- autoscale reaches its maximum because retries amplify the peak;
- two retained test containers contain stale copies; and
- a second region remains required for recovery.
The team replaces the broad query with partition-aware reads, introduces a revised key strategy for new data, controls retries, and deletes approved test copies. It keeps the second region.
The result is not the absolute lowest bill. It is a lower and more stable cost while preserving the recovery requirement. That is successful FinOps: reducing inefficient demand without calling required resilience “waste.”
Measure cost per useful database outcome
Total RU and total cost are diagnostic measures. Product economics need a meaningful denominator.
Possible units include cost per valid transaction, active customer, stored business record, completed workflow, or API operation. Pair the unit with latency, throttling, error rate, and availability.
If monthly Cosmos DB cost rises 15 percent while completed orders rise 40 percent and service quality remains stable, unit economics improved. If request units rise without a corresponding business outcome, the team has a reason to investigate code, data model, or retries.
Avoid using raw request count as the only denominator. An inefficient application can generate more requests and make cost per request appear lower.
Start with the highest-RU operation
Select one material account. Reconcile throughput, storage, regions, backup, and connected services. Identify the operation responsible for the largest repeatable RU consumption and trace it to an application behavior.
Benchmark a safe alternative, observe performance and throttling, and verify total cost after the data settles. Then address the next driver.
BICloud Tech helps Azure teams connect Cosmos DB cost to application access patterns, partition design, throughput, resilience, and business demand. Our Azure Cost Optimization services focus on lower unit cost without compromising the performance and correctness the application requires.
