AWS DynamoDB Pricing: 13 Tips to Reduce Costs

In this post, Karl Robinson introduces the technical elements of Amazon DynamoDB, and how to calculate DynamoDB Pricing. He also shares 13 invaluable tips on configuration to keep your AWS DynamoDB Costs under control.

What Is Amazon DynamoDB?

Amazon DynamoDB is the AWS fully managed NoSQL database service, enabling AWS customers to build NoSQL databases at a global scale without having to provision or manage any servers. It is a proprietary offering that supports document and key-value data structures.

DynamoDB is an excellent solution for apps that need low latency access to data, including the Internet of Things (IoT), mobile, web and gaming applications.

For more information, take a look at our Amazon DynamoDB vs. MongoDB comparison post, or refer to AWS’s product pages for additional insight on DynamoDB.

Amazon DynamoDB Cost Breakdown

The pricing model for DynamoDB is pretty complicated with many variables. To reduce costs, it’s essential to understand the various elements that AWS bills for.

DynamoDB is available within the AWS Free Tier with up to 25GB of storage and up to 200 million read/write requests per month—anyone with a free tier eligible account can run a completely free proof of concept on DynamoDB.

Beyond the free tier, DynamoDB has two separate pricing models: On-Demand Capacity Mode and Provisioned Capacity Mode. Please note that both capacity modes offer two DynamoDB table classes:

1. DynamoDB Standard: the default table option recommended for most workloads.
2. DynamoDB Standard-Infrequent Access: tables optimized for workloads that store data that is not accessed frequently, where data storage makes up the bulk of the DynamoDB costs.

On-Demand Capacity Mode

On-Demand Capacity Mode charges on a per-request basis for read and write requests that your application makes on your DynamoDB tables, plus some optional chargeable features.

I have summarized all of the different chargeable elements in the table below, together with pricing for the Europe (London) region* so you can get a feel for what the pricing looks like.

*Correct at the time of publishing, and as with most AWS services, pricing does vary by region.

Here’s a glossary of terms used in the above table:

• Read Request Unit: for API calls to read data from your tables. There are three types of read requests:
  1. Strongly Consistent Read Request: returns the most up-to-date data with updates from all prior successful write operations—costs one Read Request Unit, which returns up to 4KB of data. Additional Read Request Units are required for larger items e.g. 8KB data = 2 Read Request Units.
  2. Eventually Consistent Read Request: the response might not reflect the results of a recently completed write operation—0.5 Read Request Units required.
  3. Transactional Read Request: 2 Read Request Units are required (a transactional read or write request guarantees all operations in a transaction set succeed or fail as a set).
• Write Request Unit: standard Write Request Units can write an item of up to 1KB. For larger items, additional per KB units are required. A transactional write request requires two Write Units.
• Replicated Write Request Unit: when using global tables, replicated write requests are automatically written to multiple AWS regions.
• Streams Read Request Unit: a ‘GetRecords’ API call to DynamoDB Streams is a Streams Read Request Unit which can return up to 1MB of data.

Provisioned Capacity Mode

If you know the number of reads and writes per second that you need for your application, you can save money using Provisioned Capacity Mode.

The table below shows the chargeable elements for DynamoDB Provisioned Capacity Mode, together with the pricing in the Europe-London region at the time of writing. With provisioned capacity mode, you’ll need to commit to RCUs and WCUs over a 1 or 3-year term.

Here’s a glossary of terms used in the above table:

• Read Capacity Unit: for API calls to read data from your tables. One RCU can perform one strongly consistent read request per second of items up to 4KB in size and two eventually consistent read requests. Transactional read requests require two RCUs.
• Write Capacity Unit: one WCU can perform one standard write request per second of items of up to 1KB. For larger items, additional WCUs are required. Transactional write requests cost two Write Units.
• Replicated Write Capacity Unit: when using global tables, replicated write requests are automatically written to multiple AWS regions.

Are you still with me? A lot to take in, I know!

DynamoDB Pricing Calculator

When you’re ready to start pricing up your specific use case, head on over to this calculator to calculate your AWS pricing for DynamoDB.

To gain an accurate DynamoDB capacity estimate, ensure you have actual figures or educated estimates for the following variables.

If you want DynamoDB On-Demand pricing, you’ll need to input these variables:

• Data storage size in GB
• Average item size in KB
• Percentage of standard vs. transactional writes
• Total number of writes (either per second, minute, hour, day, month, or million per month)
• Percentage of eventually consistent vs. strongly consistent vs. transactional reads
• Total number of reads (either per second, minute, hour, day, month, or million per month)

If you want DynamoDB Provisioned capacity pricing, this is a little more complex and you’ll need to input these variables:

• Data storage size in GB
• Average item size in KB
• Percentage of standard vs. transactional writes
• Baseline write rate, in writes per second
• Peak write rate, in writes per second
• Duration of peak write activity, in hours per month
• Percentage of baseline writes covered by reserved capacity
• Write reserved capacity term (1 or 3 years)
• Percentage of eventually consistent vs. strongly consistent vs. transactional reads
• Baseline read rate, in writes per second
• Peak read rate, in writes per second
• Duration of peak read activity, in hours per month
• Percentage of baseline writes covered by reserved capacity
• Read reserved capacity term (1 or 3 years)

13 Tips to Reduce DynamoDB Cost

So now you know what makes up the pricing for Amazon DynamoDB and how to use the pricing calculator, let’s take a look at a few tips to ensure that you don’t end up paying more than you should for your Amazon DynamoDB databases.

1. Host Your Database in the Regions With the Lowest Cost

Like all AWS services, pricing does vary by region. Currently, the cheapest regions are in the US (us-east-1, us-east-2, and us-west-2), but beware that you don’t introduce too much read/write latency by setting your database too far away from your app or users.

These regions also seem to be the most outage-prone, so you may wish to avoid them for that reason.

2. Purge Unnecessary or Orphaned Data

As DynamoDB charges for data stored, there is no point in storing any data you don’t need. Data can be automatically purged using the Time to Live (TTL) feature if you know, for example, that specific data only needs to be kept for a set number of days, weeks, or months.

3. Use Queries Before Scans

Data stored in DynamoDB can be read in two ways: queries or scans. A query looks up either the primary or an index key. A scan scans an entire database table looking for a result. If run a query, you are only charged Read Capacity Units for the items returned.

If you run a scan, you will be charged for all rows scanned, regardless of how many items are returned.

4. Keep Your Attribute Names Short

Because RCU/WCUs are size-dependent, it makes sense to make yours as small as possible to avoid consuming too many capacity units.

5. Avoid Strongly Consistent Reads/Transactional Writes

DynamoDB’s eventual consistency model will replicate data across all locations, usually within a second. Strongly consistent reads and transactional writes consume double the capacity units, so they should only be used if necessary.

6. Don’t Store Large Objects in DynamoDB

This will send your storage costs through the roof. Any images or other objects should be stored in S3, and the object URL can be stored in DynamoDB. Alternatively, if you have to store the objects in DynamoDB, compress them as much as possible to minimize storage costs.

7. Use Reserved Capacity When Appropriate

If you consume more than 100 units of provisioned capacity, you will save significantly by purchasing reserved capacity. You could save up to 76% for a 3-year reserved term.

8. Use Provisioned Mode Where You Can

On-demand tables can cost 5-6 times more per request than provisioned tables.

9. Use GSIs (Global Secondary Indexes) Wisely

If you need to use a GSI, be aware that it has its own provisioned throughput settings and no size limit. To stop GSI costs from spiralling out of control, you should only use required attribute projections rather than projecting all.

Doing this will keep both storage costs and read-write expenses as low as possible, as the amount of data accessed and updated is kept to a minimum. Also, don’t create indexes on attributes that are rarely used—you can view the access patterns in DynamoDB metrics.

10. Apply On-Demand Mode to Unused Tables, or Delete Them

Review read/write activity to your DynamoDB tables and either delete them or switch them to on-demand mode—more on that in this AWS blog post.

11. Store Infrequently Accessed Data in Standard Infrequent Access Tables

You can see from the above pricing tables that data storage in Standard IA tables is up to 60% lower than the cost per GB of storage in standard class tables. You can change table classes twice a month without any performance or availability impact.

Just be aware that it does cost more to read and write to the Standard IA tables, so you’ll need to keep an eye on the activity.

12. Use On-Demand Backup Rather Than Continuous Backup

With continuous backup, the read/write operations costs can quickly mount up as Write Capacity Units are constantly consumed when creating backups of your current DynamoDB tables. Read Capacity Units are consumed when restoring the backup tables. This means that the backup tables can keep growing, along with your costs.

The on-demand backup has provisioned capacity, so you’ll always know how much backup storage and RCU/WCUs you will require for your backups. The data storage cost per GB is also lower for on-demand backup, as you can see in the tables above.

13. Use DynamoDB Metrics to Optimize Capacity

Using DynamoDB Metrics with a monitoring tool such as DataDog can help you spot DynamoDB usage trends and make changes accordingly. Keep an eye on ConsumedReadCapacityUnits, and ConsumedWriteCapacityUnits to track provisioned throughput usage.

Conclusion

So there you have it—DynamoDB is an excellent service for globally distributed, fast-growing NoSQL databases, but without proper planning and ongoing monitoring, the costs can accumulate rapidly.

If you need help optimizing your DynamoDB costs or want to learn more about our AWS Cloud Managed services, why not reach out to the Logicata team and book a free discovery call? We’d love to discuss how we can help.