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.
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 1,000 requests/sec. After that new peak, you can go from zero to 2,000 requests/sec at any time without being throttled. However, if all of a sudden you send 3000 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.
Published on and updated on
