AWS DynamoDB Pricing: 13 Tips to Reduce Costs

Voiced by Amazon Polly

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 Amazon DynamoDB Costs under control.

Abstract Amazon DynamoDB

 

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, you can check out this earlier blog post comparing Amazon DynamoDB and MongoDB or the AWS product pages for DynamoDB.

Amazon DynamoDB Pricing

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.

Dynamo DB 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 2 Dynamo DB table classes:

DynamoDB Standard – the default table option recommended for most workloads.
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 summarised all of the different chargeable elements in the table below, together with the pricing in the Europe (London) region* so you can get a feel for what the pricing looks like (*correct at time of publishing, and as with most AWS services, pricing does vary by region):

Dynamo DB FeatureBilling UnitPrice in Europe (London)
Write Request (Standard Table Class)Write Request Unit$1.4846 per million write request units
Read Request (Standard Infrequent Access Table Class)Read Request Unit$0.297 per million read request units
Write Request (Standard Infrequent Access Table Class)Write Request Unit$1.8558 per million write request units
Read Request (Standard Table Class)Read Request Unit$0.371 per million read request units
Data Storage - Standard Table Class GBFirst 25 GB stored per month is free using the DynamoDB Standard table class
$0.29715 per GB-month thereafter
Data Storage - Standard Infrequent Access Table Class GB$0.11886 per GB-month
Continuous BackupGB-month$0.23772 per GB-month
On-demand BackupGB-month$0.11886 per GB-month
Restore from BackupGB$0.17829 per GB
Global Tables Standard Table ClassReplicated write request unit$2.227 per million replicated write request units
Global Tables Standard Infrequent Access Table ClassReplicated write request unit$2.784 per million replicated write request units
Change Data Capture for Amazon Kinesis Data StreamsChange Data Capture Unit$0.1188 per million change data capture units
Change Data Capture for AWS Glue Elastic ViewsChange Data Capture Unit$0.10 per million change data capture units
Data export to Amazon S3GB$0.11886 per GB
DynamoDB Accelerator (DAX)Node-hour (18 Node Types available from 2 vCPU 2GB RAM to 64 vCPU 488GB RAM)$0.044 - £10.0544288 per hour
DynamoDB StreamsStreams Read Request UnitEvery month, the first 2,500,000 DynamoDB Streams read request units are free
$0.0237 per 100,000 DynamoDB Streams read request units thereafter
Data Transfer OutGB$0.05 to $0.09 per GB depending on volume as per standard AWS transfer out fees

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

  1. 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 requests units required (a transactional read or write request guarantees all operations in a transaction set succeed or fail as a set).
  2. 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.
  3. Replicated Write Request Unit – when using global tables, replicated write requests are automatically written to multiple AWS regions.
  4. Streams Read Request Unit – a ‘GetRecords’ API call to Dynamo DB 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.

Dynamo DB FeatureBilling UnitPrice in Europe (London)
Provisioned Write Capacity (Standard Table Class)Write Capacity Unit$0.000772 per WCU
Provisioned Read Capacity (Standard Infrequent Access Table Class)Read Capacity Unit$0.0001544 per RCU
Provisioned Write Capacity (Standard Infrequent Access Table Class)Write Request Unit$0.000965 per WCU
Provisioned Read Capacity (Standard Table Class)Read Request Unit$0.000193 per RCU
Data Storage - Standard Table Class GBFirst 25 GB stored per month is free using the DynamoDB Standard table class
$0.29715 per GB-month thereafter
Data Storage - Standard Infrequent Access Table Class GB$0.11886 per GB-month
Continuous BackupGB-month$0.23772 per GB-month
On-demand BackupGB-month$0.11886 per GB-month
Restore from BackupGB$0.17829 per GB
Global Tables Standard Table ClassReplicated write capacity unit$0.001158 per rWCU per hour
Global Tables Standard Infrequent Access Table ClassReplicated write capacity unit$0.0014475 per rWCU per hour
Change Data Capture for Amazon Kinesis Data StreamsChange Data Capture Unit$0.1188 per million change data capture units
Change Data Capture for AWS Glue Elastic ViewsChange Data Capture Unit$0.10 per million change data capture units
Data export to Amazon S3GB$0.11886 per GB
DynamoDB Accelerator (DAX)Node-hour (18 Node Types available from 2 vCPU 2GB RAM to 64 vCPU 488GB RAM)$0.044 - £10.0544288 per hour
DynamoDB StreamsStreams Read Request UnitEvery month, the first 2,500,000 DynamoDB Streams read request units are free
$0.0237 per 100,000 DynamoDB Streams read request units thereafter
Data Transfer OutGB$0.05 to $0.09 per GB depending on volume as per standard AWS transfer out fees

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

  1. 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.
  2. 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.
  3. 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

DynamoDB Pricing Calculator

When you’re ready to start pricing up your specific use case, head on over to the AWS Pricing Calculator for DynamoDB.

To gain an accurate DynamoDB capacity estimate, make sure 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)

DynamoDB Cost Reduction

13 Tips to Reduce Dynamo DB 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 siting 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 2 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 best you can 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 three-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 spiraling 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 beware 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 OnDemand backup has provisioned capacity, so you’ll always know how much backup storage and RCU/WCU’s 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 Dynamo DB usage trends and make changes accordingly. Keep an eye on ConsumedReadCapacityUnits, 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 very quickly mount up.

If you need help to optimize your DynamoDB costs, why not reach out to the Logicata team and book a free discovery call? We’d love to discuss how we can help.

You Might Be Also Interested In These...

AWS Snowball

AWS Snowball: What Does Amazon’s Import/Export Appliance Cost?

AWS Import Export with Snowball Originally a single device used for migrating data into AWS, Snowball is now part of the AWS Snow family of services used for both speeding up data import and export to and from AWS, and for secure edge computing. The AWS Snowball family includes: AWS Snowball Edge Storage Optimized AWS […]

View Post
AWS Snowball

5 Ways to Get Your Data into AWS.

So, you’re ready to take the plunge and migrate workloads into AWS.  But you have terabytes or petabytes of data – how are you going to get this from your on-premises datacentre into the AWS cloud?  Don’t worry, of course AWS have a bunch of services that can help you, but which is the right […]

View Post
hacker cybersecurity data

Logicata Comment: AWS Must Come Clean On Role In SolarWinds Hack

Solution providers have urged Amazon Web Services to publicly explain how the cloud computing giant’s technology was used by the SolarWinds hackers in their campaign.   “I do wonder whether AWS has made a judgment error in not coming out to publicly defend their position in this high-profile case with such far reaching consequences,” said […]

View Post
ebook featured image

5 Steps to a Successful

AWS Migration

DOWNLOAD FREE EBOOK