Start free trial

Central data platform for your serverless environment.

Get full access to all premium features for 14 days. No code changes and no credit card required.

Password: 8+ characters, at least one upper case letter, one lower case letter, and one numeric digit

By signing up, you agree to our Privacy policy and
Terms and Conditions.

Cost-Efficient Ways to Run DynamoDB Tables

Share

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.

Made by Developers for Developers

Our history and present are deeply rooted in building large-scale cloud applications on state-of-the-art technology. Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

10,000+ developers trust Dashbird

Dashbird helped us reduce the time to discovery from 2-4 hours to a matter of seconds. This means we’re saving dozens of hours in developer time, which not only can be funneled into improving the product but also means 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.

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.

Read our blog

AWS Step Functions Input and Output Manipulation Handbook

In this handbook, you’ll learn how to manipulate AWS Step Functions Input and Output and filter this data.

How to Save Hundreds of Hours on Lambda Debugging

Learn simple ways to save a ton of time when scanning logs to debug errors in your Lambda functions.

Why Are Some Engineers Missing The Point of Serverless?

Why are some engineers missing the point of serverless? Let’s have a look at the common critique points, benefits, drawbacks of serverless, and if it makes sense for your use case.

How Dashbird innovates serverless monitoring

What makes an effective serverless monitoring strategy? In this article, we’re discussing the three core ideas that Dashbird’s serverless monitoring tool was built on top and that should be the fundamentals of any effective serverless monitoring approach.

Debugging with Dashbird: Malformed Lambda Proxy Response

A problem that pops up quite frequently when people try to build serverless applications with AWS API Gateway and AWS Lambda is: Execution failed due to configuration error: Malformed Lambda proxy response.Learn what causes it and how to fix it.

Go to blog