michelangelus - Fotolia
Developers use Amazon DynamoDB, AWS' popular NoSQL database, to create tables in the cloud and immediately insert and retrieve data using the AWS SDK. Even though a DynamoDB table can technically scale to virtually any volume, there are important considerations regarding read and write capacity allocations for DynamoDB tables.
For example, if usage exceeds the allocated capacity, the application will return errors. On the other hand, if capacity is over-provisioned, application owners will pay an unnecessary amount of money. For high-traffic applications, the cost of a DynamoDB table can easily reach hundreds, even thousands of dollars per month. Therefore, it's important to make sure capacity is allocated properly.
First, understand the two ways DynamoDB defines capacity:
- Read request units. One strongly consistent read or two eventually consistent reads for a data block of up to 4 KB.
- Write request units. One write request for a data block of up to 1 KB.
DynamoDB offers two types of capacity allocation: on-demand and provisioned. With on-demand capacity, pricing is based on the amount of read and write request units the application consumes throughout the month.
Application owners don't have to explicitly configure read/write capacity. DynamoDB can immediately serve all incoming read/write requests, regardless of volume -- as long as traffic doesn't exceed twice the amount of the highest recorded level. If volume exceeds this limit, capacity is eventually allocated, but it can take up to 30 minutes to be available.
With provisioned capacity, developers assign read/write capacity units and pay based on the allocated capacity. This usage is billed hourly, regardless of how much of that capacity was consumed. If the application exceeds the provisioned capacity, AWS throttles the requests, and the application won't be able to read or write data during those periods.
Price and use for DynamoDB on-demand vs. provisioned capacity
On-demand is a good option for applications that have unpredictable or sudden spikes, since it automatically provisions read/write capacity. Provisioned capacity is suitable for applications with predictable usage. And, in combination with DynamoDB Auto Scaling, the provisioned capacity variant can dynamically adjust capacity during periods of high usage. Keep in mind that Auto Scaling reacts to usage metrics, so there's typically a delay of at least one minute before adjustments can be applied to a table, which might not be fast enough to prevent application errors during steep usage spikes.
While on-demand delivers the best fit for scalability, the cost is approximately seven times higher than provisioned capacity. In addition, provisioned capacity offers the option to purchase reserved capacity, which can save between 40% and 80% compared to non-reserved provisioned capacity. This means on-demand could cost between 15 times and 20 times more than reserved provisioned capacity for some configurations. For small applications, the flexibility of on-demand may be worth the extra cost, but for large applications, it can mean spending hundreds or thousands of dollars more per month.
The choice between DynamoDB on-demand vs. provisioned capacity depends on which is the better fit for your applications. On-demand is good for small applications or for large applications with steep and unpredictable spikes that DynamoDB Auto Scaling cannot react to fast enough. For most other applications, provisioned capacity is likely a better option when factoring in cost.
Dig Deeper on AWS cloud platform
Related Q&A from Ernesto Marquez
When it comes to data stream processing and analysis, AWS offers Amazon Kinesis or a managed version of Apache Kafka. Compare these two options to ... Continue Reading
Lambda and VPCs are essential to many AWS architectures, but they don't come together as intuitively as you might think. Learn how to configure ... Continue Reading
Before choosing between Aurora Serverless and Amazon RDS, consider each service's benefits and limitations to ensure you find the right use case and ... Continue Reading