Cost-Efficient Ways to Run DynamoDB Tables

As we all know, the on-demand capacity mode of DynamoDB is great but can be cost-prohibitive in some cases (up to seven times more expensive than the Provisioned Capacity mode).

The Provisioned mode, on the other hand, shifts to the development team the burden of predicting what level of capacity will be required by the application. And it’s not quite as straightforward to achieve the same level of scalability in the Provisioned mode as we enjoy in the On-demand one.

Improving Provisioned mode scalability while cutting costs

There are at least three strategies to improve scalability in the Provisioned mode and keep costs down at the same time.

The built-in auto-scaling feature is an option but requires benchmarking. It usually does not adapt itself very quickly to sharp spikes in demand. It’s important to run some tests with a distribution close to what your system currently gets in order to verify whether auto-scaling would be suitable.

Alternative to read-intensive tables

If you are considering the On-demand capacity for a read-intensive table, maybe the cache service, DAX, can be a more economical alternative

But it really depends on the level of usage. A relatively small DAX instance (t2.medium) would cost the equivalent of more than 200 Million read operations in On-demand mode. In this case, the cost savings are only possible in high-throughput scenarios.

Queue-load leveling for write-intensive tables

Last, but not least, an SQS queue can be an alternative for write-intensive workloads.

A highly coupled architecture with a Lambda function directly connected to the DynamoDB table is very common but this creates uncertainty as to how much capacity will be required on the DynamoDB side.

The SQS load level strategy is about using an SQS queue to handle the high-throughput and unpredictable traffic spikes.

Messages are polled by another Lambda function, which is responsible for writing data on DynamoDB. By setting a throttling limit to this second Lambda function, we make capacity allocation a lot easier on the database side, opening up the opportunity to use the much cheaper Provisioned capacity mode.

Visibility is key

It’s certainly impossible to optimize costs if we are unable to monitor and visualize our cloud stack. Dashbird is a Serverless-first monitoring tool that allows you to keep track of DynamoDB tables, Lambda functions, SQS queues, and more.

It also cross-references our architecture against industry best practices to suggest performance improvements, cost reduction opportunities, and anticipate potential points of failure. Start a free trial right now. It takes only 3 minutes and no credit card is required.

Read our blog

Introducing easy custom event monitoring for serverless applications.

Today we are excited to announce scheduled searches – a new feature on Dashbird that allows you to track any log event across your stack, turn it into time-series metric and also configure alert notifications based on it.

Why and How to Monitor Amazon OpenSearch Service

One of the most vital aspects to monitor is the metrics. You should know how your cluster performs and if it can keep up with the traffic. Learn more about monitoring Amazon OpenSearch Service.

Why and How to Monitor AWS Elastic Load Balancing

Dashbird recently added support for ELB, so now you can keep track of your load balancers in one central place. It comes with all the information you expect from AWS monitoring services and more!

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.