What Does Request unit Mean?
On This Page
Quick Definition
A request unit (RU) is a way Azure Cosmos DB measures how much processing power a database operation needs. Each operation, like reading a document or running a query, consumes a certain number of RUs. You pay for a certain number of RUs per second, so you need to plan how many RUs your application will use. Understanding RUs helps you control costs and make sure your database responds quickly enough.
Commonly Confused With
Database throughput is the total RUs per second allocated to an entire Azure Cosmos DB database, which can be shared among all containers within that database. Request units are the individual units of that throughput consumed by a single operation. Throughput is the bucket of RUs, while an RU is the drop in the bucket.
If you set database throughput to 10,000 RUs per second, each container in the database can use up to that total. A single query might consume 10 RUs, and that consumption is deducted from the database throughput.
Request cost is the exact number of RUs charged for a specific database operation. It is a measured value, not a unit. Technically, 'request units' are the unit of measurement, and 'request cost' is the number of those units an operation uses. The terms are often used interchangeably, but in exams, 'request cost' might refer to the numeric value shown in the response header.
A query returns x-ms-request-charge: 42.3, meaning the request cost is 42.3 RUs. Each of those is one request unit.
Capacity units are a term used in other Azure services, such as Azure Data Factory or Azure Analysis Services, to represent a bundle of compute and memory resources. They are not the same as RUs. RUs are specific to Azure Cosmos DB and measure throughput for database operations, while capacity units are used for different services with different billing models.
In Azure Analysis Services, a capacity unit includes 2.5 GB of memory and 1 vCPU. In Azure Cosmos DB, an RU is only about the resources needed for one database operation, not a fixed bundle of compute.
Must Know for Exams
Request units are a fundamental concept for several Azure certification exams, particularly those focused on data services and solutions architecture. The most relevant exam is the DP-900: Microsoft Azure Data Fundamentals. This exam covers the core concepts of Azure Cosmos DB, including the request unit model, provisioning throughput, and cost implications. Questions often ask you to define an RU, explain how RU consumption varies by operation type, or recommend a throughput provisioning strategy for a given scenario.
The AZ-900: Microsoft Azure Fundamentals exam also touches on RUs in the context of Azure Cosmos DB as a service. You might see a question about the pricing model of Cosmos DB and how RUs determine cost. While AZ-900 does not require deep technical knowledge, knowing the basic idea of RUs as a cost and performance unit is helpful.
The DP-203: Data Engineering on Microsoft Azure exam goes deeper. It includes objectives about designing and implementing data storage solutions using Cosmos DB. You must understand how to select the appropriate RU provisioning mode (manual vs. autoscale), how to estimate RU consumption for different workloads, and how to troubleshoot rate limiting. Scenario-based questions might ask you to choose between partition keys or indexing policies to reduce RU costs.
The AZ-305: Designing Microsoft Azure Infrastructure Solutions exam also covers Cosmos DB as part of data platform design. You may need to recommend RU provisioning for a globally distributed application or explain how consistency levels affect RU costs.
In exam questions, RUs appear in several ways. You might be asked to calculate the total RUs needed for a batch of operations, or to identify why an application is receiving 429 errors. You might need to choose the most cost-effective RU provisioning model for a low-traffic app. Multiple-choice questions often present scenarios with different operation mixes and ask you to select the best option for minimizing cost while meeting performance SLAs.
Some questions test your understanding that RU consumption is not just about reads and writes. For example, a stored procedure that performs multiple operations within a single transaction consumes the sum of all those operations' RUs. Similarly, a query that uses an index consumes fewer RUs than one that does not. These nuances are frequently tested.
To prepare for these questions, you should study the official Azure documentation on RUs, practice with the Azure Cosmos DB RU calculator, and work through sample questions that involve estimating RU costs. Understanding that RU is a metric that normalizes resource consumption across operations, and that each operation's RU cost depends on item size, consistency level, and indexing, will give you a solid foundation for the exam.
Simple Meaning
Think of a request unit like a token for work. Imagine you have a vending machine that sells snacks. Each snack costs a certain number of tokens. A small bag of chips might cost one token, while a large sandwich might cost three tokens. The machine can only give out a limited number of snacks per minute based on how many tokens you insert. If you insert more tokens per minute, the machine works faster and gives you more snacks per minute.
In Azure Cosmos DB, a request unit (RU) is that token. Every operation you do in the database, reading a small piece of data, writing a new record, running a complex query, or deleting old data, costs a certain number of RUs. A simple read of a tiny document might cost 1 RU, but a complicated query that scans thousands of records might cost 100 RUs or more.
You choose how many RUs per second your database is allowed to use. This is like putting a certain number of tokens into the vending machine every second. If you put in 400 tokens per second, the machine can handle 400 RUs of work each second. If your application suddenly needs 800 RUs in one second, the machine will either delay the extra work or, if you have automatic scaling, give you more tokens temporarily.
The key is that you pay for the number of RUs you provision, whether you use them all or not. So if you set your database to 1,000 RUs per second, you pay for that capacity even when nobody is reading or writing data at 2 AM. This is why understanding RUs is important for both performance and cost.
Full Technical Definition
A request unit (RU) is a performance currency in Azure Cosmos DB, representing the normalized throughput required to execute a database operation. Azure Cosmos DB is a NoSQL database service that stores data in documents (JSON), graph structures, or key-value pairs. The RU is the unit of measure for the computational resources needed, including CPU cycles, memory, input/output operations per second (IOPS), and storage latency.
Each operation in Azure Cosmos DB has an RU cost that varies based on multiple factors. The size of the item being read or written directly affects the RU cost. A 1 KB document read consumes approximately 1 RU, while a 100 KB document might consume 10 RUs. Write operations cost more than reads because they require data replication and consistency checks. The consistency level chosen for the database also impacts RU costs. Stronger consistency models, such as strong consistency, require more RUs because the system must synchronously replicate data to multiple replicas before confirming the write. Eventual consistency, being the weakest, costs the least.
Indexing is another major factor. Azure Cosmos DB automatically indexes every property of every document by default. Queries that use the index efficiently consume fewer RUs than those that require full scans. If a query cannot use the index, it may need to load every document in the container, dramatically increasing the RU cost. The size and complexity of the query itself also matter. A simple point read using the document ID and partition key costs the least, while a cross-partition query that touches many partitions or uses multiple filters costs more.
RU consumption is metered per second. When you provision a certain number of RUs per second, Azure Cosmos DB reserves capacity to serve that throughput. If you exceed the provisioned RU limit within a given second, requests are rate-limited and the client receives a HTTP 429 status code (Too Many Requests). The client must then retry after a backoff period. To avoid this, you can use autoscale, which automatically adjusts the RUs between a minimum and maximum range based on traffic.
The RU model applies to all APIs supported by Azure Cosmos DB, including SQL (Core) API, MongoDB API, Cassandra API, Gremlin API, and Table API. Each API translates its native operations into RUs using the same underlying resource model. For example, a MongoDB find() operation is converted to a SQL-like query and its RU cost is calculated accordingly.
In exam contexts, you need to understand how to estimate RU costs for different operations, how to optimize queries to reduce RU consumption, and how to choose between provisioned throughput and serverless modes. You also need to know that RU costs are additive across multiple operations in a transaction and that using stored procedures or triggers can help batch operations to reduce overall RU cost.
Real-Life Example
Imagine you are running a busy coffee shop. Each customer who comes in wants a coffee. Your coffee shop has one barista who can make coffee, but the process of making each coffee requires some resources. A simple black coffee takes one unit of work, the barista pours a cup from the pot. A cappuccino takes two units, the barista must steam milk and combine it with espresso. A fancy latte with caramel and whipped cream takes three units of work. The barista can only handle a certain number of work units per minute. If you only have one barista, the maximum work units per minute is, say, 30.
In this analogy, the barista is your Azure Cosmos DB database. The work units are request units (RUs). Every operation, a read, a write, a query, has a cost in RUs. A simple read of a small document is like a black coffee: 1 RU. A write that must be replicated to three data centers for consistency is like a cappuccino: 2 or more RUs. A complex query that scans many documents is like a triple-latte with extra shots: 5 or more RUs.
You, as the shop owner, decide how many work units per minute your barista can handle. You provision 30 RUs per second. That means the barista can serve up to 30 work units in one second. If 20 customers arrive all at once and each orders a black coffee (1 RU each), that is 20 RUs in one second, well within your limit. But if 10 customers order cappuccinos (2 RUs each) and 10 customers order lattes (3 RUs each), that is 20 + 30 = 50 RUs needed in one second. The barista can only handle 30, so the 10 latte customers are told to wait. In database terms, those requests get HTTP 429 errors and must retry later.
To solve this, you could hire a second barista (increase your provisioned RUs per second). That costs more but prevents delays. Alternatively, you could ask customers to order simpler drinks (optimize your queries to use indexes and limit document sizes) so each operation uses fewer RUs. Understanding RUs helps you balance cost and performance, just like managing barista capacity in a coffee shop.
Why This Term Matters
Request units matter because they directly control both the performance and the cost of your Azure Cosmos DB database. For any IT professional working with Azure data services, understanding RUs is essential for designing efficient, scalable, and cost-effective solutions.
In practical IT terms, if you provision too few RUs, your application will experience rate limiting (HTTP 429 errors) during traffic spikes. This can cause slow responses, failed transactions, and a poor user experience. For example, an e-commerce site that experiences a flash sale might suddenly need to handle thousands of write operations per second. If the database is underprovisioned, many orders will be rejected and customers will see errors. On the other hand, if you provision too many RUs, you pay for idle capacity that you never use, which wastes budget.
RU management also affects query optimization. Developers and database administrators need to analyze the RU cost of each query to identify expensive operations. If a query costs 10,000 RUs and runs every minute, you might need to rethink the indexing strategy or rewrite the query. Azure Cosmos DB provides metrics in the Azure portal and through diagnostics logs that show the RU consumption per operation. Monitoring these metrics helps you fine-tune performance.
RU provisioning is tied to the choice between provisioned throughput and serverless mode. In provisioned throughput, you set a fixed number of RUs per second and pay for that amount. In serverless mode, you pay only for the RUs consumed by each operation, which is more cost-effective for low-traffic or unpredictable workloads. Understanding when to use each mode saves money.
For IT architects, the RU model also influences partition design. Each partition in a container has a maximum throughput limit of 10,000 RUs per second. If you need more throughput, you must distribute operations across multiple partitions using a good partition key. Choosing a bad partition key can cause hot partitions where one partition exceeds its RU limit while others are idle. This is a common exam topic and a real-world pitfall.
How It Appears in Exam Questions
In Azure certification exams, request unit questions typically fall into three categories: definition and concept, cost and provisioning, and troubleshooting.
Definition questions are straightforward. The exam might ask: 'What is a request unit in Azure Cosmos DB?' The correct answer is something like: 'A request unit is a normalized measure of the throughput required to perform a database operation.' Distractors might say it is a measure of storage capacity, network bandwidth, or a type of database index. You must know that RU measures throughput (resources per second).
Cost and provisioning questions present a scenario. For example: 'A company has an Azure Cosmos DB container that stores user profiles. The application reads each profile once per hour. There are 10,000 users. Each read operation costs 1 RU. What is the minimum provisioned throughput needed to serve all reads in one hour?' The answer requires you to calculate: 10,000 reads × 1 RU = 10,000 RUs per hour. Since throughput is provisioned per second, you divide by 3,600 seconds in an hour: 10,000 / 3,600 ≈ 2.78 RUs per second. So you provision at least 3 RUs per second. But exam trick: the minimum provisioned throughput is 400 RUs per second for a container, so the answer would be 400 RUs, not 3. The question tests both the calculation and the knowledge of minimum throughput limits.
Another common pattern is: 'You are designing a Cosmos DB solution. Your application will perform 1,000 small document writes per second. Each write costs 10 RUs. What is the required throughput?' Answer: 10,000 RUs per second. But then the question might add: 'The data needs to be replicated across two regions. How does that affect RU cost?' Writes replicated to additional regions cost extra RUs, roughly 2x per additional region for strong consistency.
Troubleshooting questions often revolve around HTTP 429 errors. A question might say: 'Users report slow response times and the application logs show HTTP 429 errors. What is the likely cause?' The answer: The application is exceeding the provisioned RU throughput. Then the question might ask for a solution: increase provisioned RUs, implement retry logic, or optimize queries to reduce RU consumption.
Scenario-based questions might describe a container with a bad partition key that causes a hot partition. The exam might ask: 'Why is one partition experiencing high RU consumption while others are low?' The answer: The partition key is causing uneven data distribution, so one partition handles most requests and hits its 10,000 RU limit. The fix: choose a different partition key.
Finally, some questions test your understanding of indexing and RU cost. A query that uses a composite index on two properties might reduce RU consumption compared to a query without that index. The exam might present a slow query and ask which index to create to lower RU costs.
Practise Request unit Questions
Test your understanding with exam-style practice questions.
Example Scenario
You are a database administrator for a startup that runs a mobile app for tracking fitness goals. Users log their daily workouts, and the data is stored in Azure Cosmos DB. Your container is called 'workouts' and each document contains fields like userId, date, exerciseType, duration, and calories.
Your app currently has about 1,000 active users. Each user logs one workout per day, and when they open the app, they view their last 10 workouts. So the read operations happen more often than writes. You set up the container with 400 RUs per second, which is the minimum allowed.
One day, your app gets featured on the app store and the user base grows to 10,000 active users overnight. Suddenly, many users start seeing error messages like 'Something went wrong, please try again.' You check the Azure portal and see that the Cosmos DB container is receiving HTTP 429 errors because the throughput is exhausted.
You need to understand request units to fix this. Each read of a single workout document costs about 1 RU. Each write (logging a new workout) costs about 5 RUs. With 10,000 users, if half of them view their workouts at the same time and half log new workouts, the peak load could be 5,000 reads × 1 RU = 5,000 RUs plus 5,000 writes × 5 RUs = 25,000 RUs, for a total of 30,000 RUs in one second. But your container only has 400 RUs per second. That is why users see errors.
You can solve this by increasing the provisioned throughput to 30,000 RUs per second. But that is expensive. A better approach might be to use autoscale with a maximum of 10,000 RUs. Autoscale will allow burst capacity up to 10,000 RUs, and you only pay for what you use. You could optimize the app to reduce RU consumption. For example, you could read the last 10 workouts in a single query instead of 10 separate reads, which might reduce the total RU cost per user. You could also reduce the indexing on fields that are never queried, such as internal metadata, to lower write RU costs.
This scenario shows how understanding RUs is practical. Without this knowledge, you might guess at the cause of errors or waste money on excessive provisioning. With it, you can make informed decisions that keep your app running smoothly and cost-effectively.
Common Mistakes
Thinking that request units are the same as database operations per second.
An operation can consume multiple RUs. A complex query might use 100 RUs, so one operation equals many RUs. Provisioning 400 RUs per second does not mean you can process 400 operations per second.
Always estimate the RU cost per operation, not the number of operations. Use the Azure Cosmos DB RU calculator to get accurate RU costs.
Believing that all read operations cost the same number of RUs.
Read RU cost depends on item size and consistency level. A 1 KB read under eventual consistency costs less than a 100 KB read under strong consistency. Also, query reads cost more than point reads.
Check the RU charge in the response headers or use the Azure portal metrics for real operations. Design your data model to keep documents small and use lower consistency levels when acceptable.
Setting provisioned RUs to exactly match average usage without accounting for peaks.
If average usage is 500 RUs per second but spikes reach 2,000 RUs, the spikes will cause HTTP 429 errors. Provisioned throughput is a per-second limit, not an average over minutes.
Use autoscale provisioning or provision for peak load. Monitor usage patterns and adjust RUs accordingly, especially for applications with variable traffic.
Assuming that increasing RUs always solves performance problems with no trade-offs.
More RUs increase cost. Also, if the performance issue is due to a bad partition key, increasing RUs may only shift the bottleneck to the partition limit of 10,000 RUs. The real fix might be redesigning the partition key.
First analyze the RU consumption patterns. If one partition is hot, optimize the partition key. If queries are expensive, add indexes. Only increase RUs after optimizing the workload.
Confusing provisioned throughput with storage capacity.
RUs measure throughput (operations per second), not storage space. Storage is billed separately in GB. A container can have low storage but high RU consumption if many operations are performed.
Separate the two concepts in your mind. Monitor both metrics independently: storage size for cost per GB, and RU consumption for cost per operation.
Exam Trap — Don't Get Fooled
{"trap":"When asked about the cost of a write operation that replicates to multiple regions, some learners think that the base RU cost of the write is the same as a single-region write and that replication is free.","why_learners_choose_it":"They may assume that Azure Cosmos DB automatically replicates data and that the RU cost covers all replications, or they forget that multi-region writes consume additional RUs per region.","how_to_avoid_it":"Remember that for multi-region writes (especially with strong consistency), each additional region amplifies the RU cost.
A single-region write costs 5 RUs for a 1 KB document. Adding a second region with strong consistency roughly doubles the cost to 10 RUs. Always calculate the total RU cost as (base write cost) * (number of regions) for strong consistency.
For eventual consistency, the cost increase is lower but still present."
Step-by-Step Breakdown
Step 1: Understand the operation type
Before you can determine RU consumption, you need to know what type of operation you are performing. Point reads (reading a single document by its ID and partition key) are the cheapest. Queries (using filters, joins, or aggregate functions) are more expensive. Writes include the cost of indexing, which is why they are generally costlier than reads.
Step 2: Determine the item size
The size of the document or item being read or written directly affects RU cost. Azure Cosmos DB charges RUs based on the size in KB. A 1 KB document read costs about 1 RU, while a 1 KB write costs about 5 RUs. The relationship is not perfectly linear but is roughly proportional. Larger items consume more RUs.
Step 3: Assess the consistency level
The selected consistency level at the account or request level impacts RU consumption. Strong consistency requires more RUs because the data must be confirmed across multiple replicas before the operation is acknowledged. Eventual consistency costs the fewest RUs. Bounded staleness and session consistency fall in between.
Step 4: Account for indexing policies
By default, all properties are indexed. Each write operation updates the index for all indexed properties, consuming additional RUs. If you turn off indexing for properties that are never queried, write operations become cheaper. Conversely, adding composite indexes for complex queries can reduce query RU costs.
Step 5: Consider replication and multi-region setup
If your Azure Cosmos DB account is configured for multi-region writes, each write operation must be processed in all write regions. This multiplies the RU cost by the number of regions. For read operations, you can use a local read from the nearest region, which does not incur extra RUs beyond the base read cost.
Step 6: Read the actual RU charge from response headers
After performing an operation, the response headers include x-ms-request-charge. This header tells you exactly how many RUs that specific operation consumed. Use this value for monitoring and optimization. For example, if a query consistently uses 500 RUs, you might add an index to reduce it.
Step 7: Provision throughput accordingly
Based on the estimated RU cost per operation and the expected number of operations per second, you can calculate the required provisioned throughput. For example, if you expect 100 writes per second at 5 RUs each and 200 reads per second at 1 RU each, total = (100*5) + (200*1) = 700 RUs per second. Then you provision 700 RUs or use autoscale with a maximum near that value.
Practical Mini-Lesson
Let us walk through a real-world practice scenario for managing request units in Azure Cosmos DB. Imagine you are a data engineer for a logistics company. You have a Cosmos DB container called 'shipments' that stores tracking information. Each document has fields like shipmentId, origin, destination, status, and estimatedDelivery. The container holds about 1 million documents, each averaging 2 KB in size.
Your application needs two main operations: a point read to retrieve a shipment by its ID, and a query to find all shipments for a given origin city that are still in transit. The point read, because it uses the ID (which is the partition key), costs about 2 RUs per document (2 KB size). The query scans a single partition (if you choose origin as the partition key) but might scan hundreds of documents. With proper indexing on the 'status' field, the query might cost 20 RUs, but without an index, it could cost 500 RUs or more.
To decide on provisioning, you should first use the Azure Cosmos DB RU calculator (available in the Azure portal or as a standalone tool). You can input your document size and operation types to get estimated RU costs. Alternatively, you can run sample operations in a test environment and inspect the x-ms-request-charge header.
Once you know the estimated costs, you forecast your load. You expect 5,000 point reads per second (peak) and 200 queries per second (peak). The point reads cost 2 RUs each, so 5,000 * 2 = 10,000 RUs per second. The queries cost 20 RUs each, so 200 * 20 = 4,000 RUs per second. Total peak throughput = 14,000 RU/s. You should provision at least 14,000 RU/s, or use autoscale with a maximum of 14,000 RU/s.
What can go wrong? If your partition key is something other than origin (like shipmentId), the query for all shipments in a given origin might become a cross-partition query. Cross-partition queries can consume many more RUs because they need to fan out to every partition. In that case, the 20 RU estimate might become 200 RUs or more. Always test your queries in a development environment with realistic data volumes.
Another common issue is using default indexing. If you index every field, each write operation (like updating the status of a shipment) will update many indexes, increasing write RU costs. You might want to exclude rarely-queried fields from indexing, such as internal notes fields that are never filtered in queries. This can reduce write RU costs by 20-30% or more.
Professionals also monitor RU consumption continuously using Azure Monitor metrics and set alerts for when RU consumption approaches the provisioned limit. If you frequently hit 90% of your provisioned RUs, you risk throttling during spikes. You can increase RUs or optimize your workload before errors occur.
Memory Tip
Think of an RU as a 'Resource Unit', it measures the resources needed for each database operation. The smaller the item and simpler the operation, the fewer RUs you use. Remember: Reads are cheap, writes are pricey; point reads are cheapest; queries cost more; and consistency costs extra.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
An AAAA record is a DNS record that maps a domain name to an IPv6 address, allowing devices to find each other over the internet using the newer IP addressing system.
Frequently Asked Questions
What is the minimum number of RUs I can provision for an Azure Cosmos DB container?
The minimum provisioned throughput for a container is 400 RUs per second. For a database with shared throughput, the minimum is also 400 RUs per second.
Can I change my provisioned RUs after creating the container?
Yes, you can increase or decrease the provisioned throughput at any time. However, you cannot decrease to below 400 RUs or below the storage-based minimum (which is 10 RUs per GB of data stored in the container).
What happens if I exceed my provisioned RUs?
Azure Cosmos DB returns an HTTP 429 (Too Many Requests) error. Your application must retry the request after a backoff period. This is called rate limiting.
How do I find out how many RUs a specific query costs?
You can check the x-ms-request-charge response header after running the query. The Azure portal also shows RU consumption for each operation in the metrics blade.
Is there a difference in RU cost between using the SQL API and the MongoDB API?
The underlying RU model is the same. However, the translation of MongoDB operations into the Cosmos DB model may cause slight differences in RU costs. Always test with your specific workload.
Do stored procedures and triggers consume RUs?
Yes, every operation inside a stored procedure or trigger consumes RUs. The total RU cost of the procedure is the sum of all individual operations performed within it.
What is the RU cost of a read operation that uses a change feed?
Reading the change feed itself consumes minimal RUs. However, processing each changed document with additional operations consumes RUs accordingly. The change feed is a low-cost way to track changes.
Summary
A request unit (RU) is a fundamental concept in Azure Cosmos DB that measures the throughput capacity needed to perform database operations. It functions like a token that each read, write, or query operation consumes. The number of RUs consumed depends on several factors: the type of operation, the size of the document, the consistency level, the indexing policy, and whether the operation is replicated across multiple regions. Understanding RUs is critical for both performance and cost management. Under-provisioning leads to HTTP 429 errors and a poor user experience, while over-provisioning wastes money.
For IT certification learners, the RU concept appears in Azure exams such as DP-900, AZ-900, DP-203, and AZ-305. Questions test your ability to calculate required throughput, select provisioning modes, diagnose rate limiting issues, and optimize queries to reduce RU consumption. You must know the minimum provisioned throughput (400 RUs per second per container), the effect of consistency levels, and the importance of proper partition keys.
The key exam takeaway is to always estimate RU costs per operation, use the RU calculator for planning, and monitor actual RU consumption through response headers and Azure metrics. By mastering request units, you can design efficient, scalable, and cost-effective data solutions with Azure Cosmos DB.