AWS DynamoDB is the go-for database for any serverless application. It is fully managed, infinitely scaled, and irresistibly simple and cute. We in the Company™ love it, the community loves it, you must also go and try it, as it is AWS Free Tier eligible. No reason not to, right?
Right, except that Amazon is not a charity organization. It wants your money and it wants it bad. Yes, there is a free tier, but that’s just for playing. How about production usage and how expensive it is? A confusing topic for AWS beginners, as there were so many times people would gasp at their AWS bills because they did not read the rules.
In this article, I would like to touch on one and probably the most critical aspect of DynamoDB pricing — paying for read and write requests. By the end of the article, I hope you will have a clear understanding of how it works, what you pay for, and how to optimize your bills. Let us start with the basics of the pricing for reading and writing data with DynamoDB.
Basics
DynamoDB charges you for reading and writing data. Sounds pretty simple, eh? Well, not really. There are multiple different modes you can toggle for your DynamoDB which would if used ineffectively, completely transmute your money into dust. Let us avoid that, let us see what we have. There are two major options available: On-demand capacity mode and Provisioned capacity mode.
On-demand capacity mode
If you enable this mode for your DynamoDB — you will pay as you go. If you had only 100 read queries to your table this month — you will pay just for those 100 read queries.
Also, this mode scales your tables up and down as soon as the amount of requests goes up and down. This means, that you do not need to do a thing, it is all managed, it is all good. If it is Black Friday and your online shop is under a massive attack DynamoDB will take the hit and it will do it graciously — in On-demand mode, it will guarantee you that your data will be available and it will be available fast. If you have an online restaurant and every lunchtime the traffic spikes — DynamoDB On-Demand can handle it with no problems.
This convenience comes at the price — On-demand capacity mode is the most expensive mode if your traffic is sustainably high. It is best used for low traffic scenarios or when your traffic is incredibly spiky.
Pros
- Easy to use, everything is managed.
- Incredibly cheap (free on free-tier) for low traffic apps.
- Great at handling spiky traffic.
Cons
- Becomes ridiculously expensive at sustainable high volume traffic. Using On-Demand for production traffic with millions of requests per second will raise your eyebrows.
Provisioned capacity mode
Okay, so you reached a point when On-Demand capacity is not working for you anymore. What do you do? The other option that you have for DynamoDB is to set it up statically. It will not be managed by AWS for you — you will be the boss.
When you statically provision capacity what you basically say is: ”Okay, I need to make sure that my database works smoothly for X requests per second”, where X is configured by you. You must know how many requests come to the Dynamo, otherwise, you will underprovision or overprovision. If you underprovision your tables will start throttling. If you overprovision — well, you will be paying for nothing.
For simplicity, let us assume you want top performance for your DynamoDB. In this case, you must set X to the peak of your requests. If your daily traffic grows over time until noon and then slowly degrades back then you must set provisioned capacity to cover even the peak of your traffic. Only by doing so, you guarantee top performance.
Let’s take a look at the chart:
The volcano-like blue area represents daily traffic. As you see, it grows over the day, peaking at about noon and then starts to go down. Imagine a big online restaurant that has a lot of orders during lunchtime.
The horizontal line on top of this volcano is X — the number of requests statically provisioned. In this example, X is around 800 Units.
Now, take a look at the red area. Since the traffic is not linear there are times at nights and mornings when you don’t need as much capacity but you still provision it. This area is a waste of the statically provisioned capacity. In other terms — it is a loss of money. You pay for the capacity but you don’t always use it. Before we go about how to address that, let us break down the pros and cons.
Pros
- Cheaper than On-Demand at certain traffic volume.
- Perfect for linear, stable traffic patterns.
- Very easy to set up — simply say how many reads and writes you want.
Cons
- Not flexible, if the traffic changes over time either performance are sacrificed or a significant amount of paid provisioning is wasted.
- Can be more expensive than On-Demand if used on low traffic volumes.
What does DynamoDB have to offer to address this?
Autoscaling
Autoscaling is a mechanism that is relatively easy to set up for the DynamoDB tables. This mechanism changes the number of provisioned units over time dynamically. It looks a lot like On-Demand capacity, but you have more control. For instance, you can set up thresholds when the provisioned capacity must be increased or what is the minimum provisioned capacity ever available. Autoscaling applied to the example above gives you the following picture:
It looks nice, it looks like we have got the best from both modes — we have got a very cheap provisioned mode, but we also scale it up and down automatically when needed.
Pros
- Reduces static provisioning wastes automatically.
- Best for traffic that predictably changes over time.
- Cheaper than On-Demand but plays in the same field.
Cons
- Autoscaling strategy configuration can be complex. The strategy you have today might not work for you tomorrow if your traffic behavior changes.
So, is it best we can do? There is one more thing we can add to the equation.
Reserved Capacity
As well as for EC2s you can reserve capacity for DynamoDB. If you are unfamiliar with reservations in AWS it is best explained by an example. Imagine you have a DynamoDB and the traffic to it is ~1000 reads per second. You can buy a discount coupon for that traffic (or part of that traffic) from AWS. By buying the discount you effectively say: “I know my business and I know it is going to be using DynamoDB for at least one or three years with a certain volume of traffic”. Once you purchased the discount you will be paying less than the normal price for your provisioned capacity. And by less I mean significantly less, up to 75% less. So, it will be cheaper for you overall, but you will have to commit to two things:
- An upfront price you need to pay for the discount.
- The discount lasts for either one or three years and you cannot get rid of it if you no longer need it.
This brings us to an interesting question — how much traffic you should reserve? If the traffic is linear and stable, then just reserve all of it — that will be the most cost-efficient. You will be saving a lot of money. But what if your traffic is as an example above when it changes over time? Let us take a look at the picture below:
The yellow line on the chart shows how much traffic we covered by the discount, it delineates three areas:
- Green area — traffic covered by the discount.
- Blue area — traffic that is not covered by the discount.
- Gray area — this is a waste of the discount. We don’t have enough traffic at times to be using all the reserved capacity that we have.
Smells similar? You are right — reserved capacity is also static. You cannot have 500 units under discount at 3 am and 100 units at midnight. This means that you must calculate very precisely how many reserved units are the most cost-efficient and what is best left uncovered by the discount to minimize the waste.
Pros
- The traffic under the discount is the cheapest traffic you can have in DynamoDB.
- Best for stable linear traffic.
Cons
- Comes with commitments.
- Static by nature and cannot be auto-scaled up and down, making it difficult to figure out how much of your traffic to cover by the discount and what is better left to be autoscaled up and down.
Math is hard
First, I would like to congratulate you if you read up to this point — you know what is there for DynamoDB payments and what would be a general strategy to optimize it.
I explicitly avoided as much as I could all of the nitty-gritty technical details like the difference in prices for transactional and eventually consistent reads. Those are important, but the picture stays the same.
Speaking of details, how does one decide when to switch from On-Demand to Provisioned (or back)? At what specific traffic it is going to better? Or what is the most optimal reserved capacity that you need to buy for your business?
Finding answers to these kinds of questions is really hard. There are so many factors in the equation that it is very easy to overlook something or calculate incorrectly and disappoint yourself with a huge AWS bill.
Meet RASCAR-D
The good news is that we developed a solution for this. We created a special service that analyzes your DynamoDB traffic and gives you a breakdown of different prices recommending the best mode for you. It is based on the past usage of your tables and it tells you if it is time to switch to the Provisioned mode. It tells you what is the best reserved capacity for you and what savings you can get. It tells you if autoscaling is something that you need or not. It tells you if you should autoscale a part of your traffic and reserve the rest. It gives a bunch of insights that optimize your DynamoDB bills! You can check some details here: RASCAR-D. It is yet to be public, but even in the Company™, it saves us a ton of money.
Apply it to your DynamoDB and the recommendations it gives will not disappoint!
