1
votes

After reading AWS docs and answers to other similar questions, DynamoDB Provisioned Capacity model pricing still remains somewhat unclear to me.

As stated in AWS documentation: "You will be charged for the throughput capacity (reads and writes) you provision in your Amazon DynamoDB tables, even if you do not fully utilize the provisioned capacity. The actual reads and writes performance of your DynamoDB tables may vary and may be less than the throughput capacity that you provision."

Accordingly to the last part of this answer on one of the similar questions: "Lastly, with Dynamo you pay for the capacity that you reserve, not what you consume. So as long as your table is not being throttled, even when you go slightly over the provisioned capacity (which Dynamo allows in certain cases) you will not be charged extra.".

However, nowhere did I find a simple explanation of how is pricing based on data read/write rates that can exceed current Read/Write Capacity Unit values set for a table or what happens if the table read/write operations are throttled upon request. If I create a table and set both Read Capacity Unit and Write Capacity Unit to 5 with the auto-scaling feature disabled, will the charges for DynamoDB service under all circumstances be calculated by the following equation?

charges = (provisioned RCU * Hours used + provisioned WCU * Hours used) + Storage costs

That means, regardless of RCU/s and WCU/s usage and throttling.

An example: from my understanding Scan request that will return all items in the aforementioned table that contains, say, 80 items will exceed provisioned throughput (with the size of each item less than 4 KB and a total size of all items in a table around 160 KB), so it will either take around 8 seconds to fetch the data (160 KB / (5 Read Capacity Units * 4 KB)) with the request being throttled or DynamoDB will allow for burst capacity consumption and process the scan somewhat faster.

But in neither case, that request will be additionally charged as provisioned read capacity overuse because provisioned capacity is basically a method to limit read/write operations rates. Is that assumption correct? Or is table throttling a subject for additional charges? And what are the ways to force the data read/write rates limit then?

1

1 Answers

3
votes

You can find a very good presentation about how DynamoDB's provisioned pricing is implemented (and a lot of other interesting stuff) in this AWS re:invent 2018 talk.

The short answer is that if you used provisioned pricing (and disable autoscaling), you'll be paying exactly what you provisioned (plus other charges like disk and network) - not more and not less. Amazon will throttle you so you wouldn't be able to get (on average) more than the request rate you are paying for. Amazon will also make an effort (described in the above talk) to make sure you don't get less than what you are paying for (the talk explains why this wasn't easy to achieve, and in the past users did complain about it). Even if you do manage to get more requests per second than you have provisioned for, you won't be charged extra. Amazon will just remember that it served you more, and you may potentially get fewer requests served in the following seconds.

Amazon has several ways in which it can throttle you: It can delay requests, it can fail a request with ProvisionedThroughputExceededException, it can return fewer items from a Scan, or it can return a partial success from batch operations such as BatchGetItem. In all these cases, your client library will help you and automatically complete the request later, with exponential backoff.

You mentioned auto-scaling as an option you aren't using. But you might still be interested to learn what it does. Since provisioned capacity can be changed at any moment, Auto-scaling helps you pick the right provisioned capacity for your current needs, by growing your provisioned capacity when you're nearing the limit, or lowering it when you're far from the limit. This blog post is an interesting look into how you can combine auto-scaling, and also reserved capacity (where you commit to some provisioned capacity for a full year) and on-demand capacity (where you don't need to provision at all), to get what they claim are better prices.