This post is provided by App Dev Manager, Ansar Khan who provides an overview of Cosmos DB billing.
Azure Cosmos DB is Microsoft’s globally distributed multi-model database. One of the frequently asked questions about Cosmos DB is around billing. This article is targeted to help unravel the complexity around Cosmos DB pricing. It’s important to note that things tend to change rapidly in the cloud and current Cosmos DB pricing information can always be found here.
Azure Cosmos DB allows elastically scale throughput and storage worldwide, and pay only for the throughput and storage you need. The currency of Azure Cosmos DB is the Request Unit (RU). With RUs, you do not need to reserve read/write capacities or provision CPU, Memory and IOPS. At any scale, you can store data and provision throughput capacity.
Each Cosmos DB container is billed hourly based on the amount of data stored (in GBs) and throughput reserved in units of 100 RUs/second, with a minimum of 400 RUs/second. Unlimited containers have a minimum of 100 RUs/second per partition.
What is Request Unit (RU)?
A Request Unit (RU) is the measure of throughput in Azure Cosmos DB. 1 RU corresponds to the throughput of the GET of a 1 KB item. Every operation in Azure Cosmos DB, including reads, writes, SQL queries, and stored procedure executions has a deterministic Request Unit value based on the throughput required to complete the operation. Instead of thinking about CPU, IO, and memory and how they each impact your application throughput, you can think in terms of a single Request Unit measure. Note that a Request Unit consumed through Provisioned RUs per second or a one-minute bucket is the same. For more information about Request Units and for help determining your container needs, please go here.
How much RU/s capacity does my application need?
Use this calculator to determine the number of request units per second (RU/s) and the amount of data storage needed by your application.
How does Request Units per Minute work?
You can now provision add-on Request Units per Minute in addition to regular provisioned throughput. You can consume these add-on throughput units in a UTC minute window. For every 100 RUs/second provisioned in your container, if Request Units per Minute is enabled, you'll be able to consume an additional 1,000 Request Units per Minute.
For example, if you provision 400 RUs/second, it will allow you to consume an add-on of 4,000 Request Units per Minute. Let’s say at 12:00:00 PM, your application needs more than 400 RUs/second. Starting from 12:00:01 PM to 12:01:00 PM, your application will be able to consume 4,000 additional requests units, while continuing to consume your provisioned throughput of 400 RU/s. Starting at 12:00:01 PM, if you consume all the 4,000 request units before 12:01:00 PM, you can’t consume anymore additional request units until the next UTC minute (starting at 12:01:01 PM). If you don’t consume all the 4,000 in a given minute window, the left-over request units don’t roll over to the next minute window.
Provisioning request units per minute (RU/m)
For Azure Cosmos DB, you can provision throughput on a Cosmos DB container at both, per-second and at per-minute (RU/m) granularities. The provisioned throughput at per-minute granularity is used to manage unexpected spikes in the workload occurring at a per-second granularity.RU/m is billed hourly and is in addition to RU/s.
The goal in mind with provisioning of RU/m is to provide a predictable performance around unpredictable needs (especially if you need to run analytics on top of your operational data) and spiky workloads.
When you provision Azure Cosmos DB at the per second granularity (RU/s), you get the guarantee that your request succeeds at a low latency if your throughput has not exceeded the provisioned capacity within that second.
With RU/m, the granularity is at the minute with the guarantee that your request succeeds within that minute. Compared to bursting systems, we make sure that the performance you get is predictable and you can plan on it.:
The way per minute provisioning works is simple:
- RU/m is billed hourly and in addition to RU/s. For more details, please visit Azure Cosmos DB pricing page.
- RU/m can be enabled at collection level. That can be done through the SDKs (Node.js, Java, or .Net) or through the portal (also include MongoDB API workloads)
- When RU/m is enabled, for every 100 RU/s provisioned, you also get 1,000 RU/m provisioned (the ratio is 10x)
- At a given second, a request unit consumes your RU/m provisioning only if you have exceeded your per second provisioning within that second
- Once the 60-second period (UTC) ends, the per minute provisioning is refilled
- RU/m can be enabled only for collections with a maximum provisioning of 5,000 RU/s per partition. If you scale your throughput needs and have such a high level of provisioning per partition, you will get a warning message
Still complicated. Let’s walk-through an example
Below is a concrete example, in which a customer can provision 10kRU/s with 100kRU/m, saving 73% in cost against provisioning for peak (at 50kRU/sec) through a 90-second period on a collection that has 10,000 RU/s and 100,000 RU/m provisioned:
- 1st “second”: The RU/m budget is set at 100,000
- 3rd “second”: During that second the consumption of Request Unit was 11,010 RUs, which is 1,010 RUs above the provisioned 10k RU/s capacity. Therefore, 1,010 RUs are deducted from the RU/m budget. 98,990 RUs are available for the next 57 seconds in the RU/m budget
- 29th “second”: During that second, a large spike happened (>4x higher than provisioning per second) and the consumption of Request Unit was 46,920 RUs. 36,920 RUs are deducted from the RU/m budget that dropped from 92,323 RUs (28th second) to 55,403 RUs (29th second)
- 61st second: RU/m budget is set back to 100,000 RUs.
How does Request Unit usage show up on my bill?
You're billed with a flat, predictable hourly rate based on the overall capacity (RU/sec) that has been provisioned under your Azure Cosmos DB account during that period. If you create an account in East US 2 using two single partitions with 500 RU/sec and 700 RU/sec, respectively, you would have a total provisioned capacity of 1,200 RU/sec. You would thus be charged 12 x $0.008 = $0.096/hr.
If your throughput needs changed and you increased each partition’s capacity by 500 RU/sec while also creating a new unlimited storage container using 20,000 RU/sec, your overall provisioned capacity would be 22,200 RU/sec (1,000 RU/sec + 1,200 RU/sec + 20,000RU/sec). Your bill would then change to: $0.008 x 222 = $1.776/hr.
In a month of 720 hours, if 500 hours are provisioned at 1,200 RU/sec and 220 hours are provisioned at 22,200 RU/sec, your monthly bill will show—500 x $0.096/hr + 220 x $1.776/hr = $438.72/hr.
Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality. Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.
This post first appeared on MSDN Blogs | Get The Latest Information, Insights, Announcements, And News From Microsoft Experts And Developers In The MSDN Blogs., please read the originial post: here