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.
Please support our work!
We have published 327 articles, 41 podcast episodes, and 15 videos. It's all free and means a lot of work in our spare time.
Thanks to Alan Leech, Alex DeBrie, e9e4e5f0faef, Goran Opacic, jhoadley, Shawn Tolidano, Thorsten Hoeger, Todd Valentine, Vince Fulco, and all anonymous supporters for your help! We also want to thank all supporters who purchased a cloudonaut t-shirt. It gives us great pleasure to send our t-shirts all over the world.
With your help, we can continue to produce independent & high-quality content focused on AWS. Please support us!
Support usBehind 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 launched cloudonaut.io in 2015 with my brother Andreas. Since then, we have published hundreds of articles, podcast episodes, and videos. It’s all free and means a lot of work in our spare time. We enjoy sharing our AWS knowledge with you.
Have you learned something new by reading, listening, or watching our content? If so, we kindly ask you to support us in producing high-quality & independent AWS content. We look forward to sharing our AWS knowledge with you.
Feedback? Questions? You can reach me via Email, Twitter, or LinkedIn.
