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.

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 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.