Cost savings with DynamoDB On-Demand: Lessons learned
One of my favorite features announced during re:Invent 2018 is DynamoDB On-Demand. With DynamoDB On-Demand, we can use DynamoDB without provisioning capacity. Instead, we pay per request. Sounds amazing? I was excited and re-configured all DynamoDB tables of our SaaS product marbot: cloud-native alerting for CloudWatch via Slack. The result is stunning but misleading.
I shared my excitement on Twitter and today I add what we learned in the following weeks.
Stop fighting your database.
DynamoDB is exploding in popularity. It's fast, scalable, and fully-managed. But it's not your father's database. Data modeling in DynamoDB is different than the relational data model you're used to.
Learn how to properly design your data model with DynamoDB to avoid problems later.
The DynamoDB Book by Alex DeBrie is available now!
Behind the marketing term
What does DynamoDB On-Demand mean? When compared with the provisioned DynamoDB model, on-demand is:
- A table that scales automatically.
- A new cost model where you pay per request.
Scaling takes time if you hit a new peak
DynamoDB On-Demand provisions capacity to handle two times the past peak traffic. Let’s say your previous peak in January 2019 was 10,000 requests/sec. After that new peak, you can go from zero to 20,000 requests/sec at any time without being throttled. However, if all of a sudden you send 30,000 requests/second it takes around 30 minutes for DynamoDB On-Demand to scale up. You see throttles in the meantime! The best way to avoid throttling is to prescale an on-demand table by simulating a new traffic peak before you go live.
Economics
There are cases where on-demand is significantly more expensive compared to provisioned with Auto Scaling. My rule of thumb: The spikier your workload, the higher the savings with on-demand. Workloads with zero requests also benefit. The reason why we saw such significant savings with marbot is our workload that goes down to almost zero requests/second for half of the day in production and is mostly zero for 24/7 in our test environment. My suggestion is to switch to on-demand for one day and compare your costs with the day before.
Michael Wittig
I’m an independent consultant, technical writer, and programming founder. All these activities have to do with AWS. I’m writing this blog and all other projects together with my brother Andreas.
In 2009, we joined the same company as software developers. Three years later, we were looking for a way to deploy our software—an online banking platform—in an agile way. We got excited about the possibilities in the cloud and the DevOps movement. It’s no wonder we ended up migrating the whole infrastructure of Tullius Walden Bank to AWS. This was a first in the finance industry, at least in Germany! Since 2015, we have accelerated the cloud journeys of startups, mid-sized companies, and enterprises. We have penned books like Amazon Web Services in Action and Rapid Docker on AWS, we regularly update our blog, and we are contributing to the Open Source community. Besides running a 2-headed consultancy, we are entrepreneurs building Software-as-a-Service products.
We are available for projects.
You can contact me via Email, Twitter, and LinkedIn.
