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.

[wpcc-element _tag=”source” type=”image/webp” srcset=”/images/2019/02/cost-savings@730w.webp 730w, /images/2019/02/cost-savings@730w2x.webp 1460w, /images/2019/02/cost-savings@610w.webp 610w, /images/2019/02/cost-savings@610w2x.webp 1220w, /images/2019/02/cost-savings@450w.webp 450w, /images/2019/02/cost-savings@450w2x.webp 900w, /images/2019/02/cost-savings@330w.webp 330w, /images/2019/02/cost-savings@330w2x.webp 660w, /images/2019/02/cost-savings@545w.webp 545w, /images/2019/02/cost-savings@545w2x.webp 1090w” sizes=”(min-width: 1200px) 730px, (min-width: 992px) 610px, (min-width: 768px) 450px, (min-width: 576px) 330px, 545px” _close=”0″]

Today, I add what we learned in the following weeks.

[wpcc-element _tag=”source” type=”image/webp” srcset=”/images/2019/02/dynamodb-on-demand-cost-savings@730w.webp 730w, /images/2019/02/dynamodb-on-demand-cost-savings@730w2x.webp 1460w, /images/2019/02/dynamodb-on-demand-cost-savings@610w.webp 610w, /images/2019/02/dynamodb-on-demand-cost-savings@610w2x.webp 1220w, /images/2019/02/dynamodb-on-demand-cost-savings@450w.webp 450w, /images/2019/02/dynamodb-on-demand-cost-savings@450w2x.webp 900w, /images/2019/02/dynamodb-on-demand-cost-savings@330w.webp 330w, /images/2019/02/dynamodb-on-demand-cost-savings@330w2x.webp 660w, /images/2019/02/dynamodb-on-demand-cost-savings@545w.webp 545w, /images/2019/02/dynamodb-on-demand-cost-savings@545w2x.webp 1090w” sizes=”(min-width: 1200px) 730px, (min-width: 992px) 610px, (min-width: 768px) 450px, (min-width: 576px) 330px, 545px” _close=”0″]

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.