10 Tips to Optimize Your DynamoDB Costs

Because Amazon DynamoDB is a fully managed database where a user does not provision any machines, the pricing is not as straightforward. While our Pricing Calculator can help with forecasting the costs, the pricing optimization techniques are a bit different. Below are 10 tips that can help you lower your DynamoDB costs:

1. Use cheaper regions

If you are not concerned about your data's location because you don't need to meet any regulations or compliance standards, you can provision your tables in regions where it's cheaper. For example, if your table will have 100GB of data, the storage will cost $28.50 per month in Tokyo (ap-northeast-1), $29.72 per month in London (eu-west-2), or even $37.50 per month in Sao Paulo (sa-east-1).

The cheapest regions are us-east-1, us-east-2, and us-west-2, costing $0.25 per GB/month, $0.00065 per WCU/hour, and $0.00013 per RCU/hour.

2. Use shorter attribute names

Because DynamoDB in both On-Demand and Provisioned capacity mode uses size-dependent billing units (1 WCU/WRU = 1KB, 1 RCU/RRU = 4KB), plus, you're paying for storage too, you should always aim to make your records as small as possible. If making attribute values shorter is not an option, try making attribute names shorter. This helps you reduce the amount of storage required for your data. Moreover, when storing dates, you can choose the epoch time format instead of ISO dates because it's shorter too.

3. Be aware of huge blobs

Saving images or large binary objects (blobs) in DynamoDB can quickly skyrocket costs. It's very inefficient, and you should rather store all images or linked assets in S3 and save the URL pointing to it in DynamoDB. If that's not an option, consider using compression algorithms like gzip to make blobs smaller before saving them. Additionally, consider breaking down large blobs into smaller chunks if they must be stored in DynamoDB.

4. Prefer queries over scans

DynamoDB has two ways of fetching a set of records from it: Query and Scan. While the query uses partition and sort key to get the desired piece of data fast and directly, the scan, on the other hand, is "scanning" through your whole table. The difference here is that while in Query, you are charged only for items which are returned, in the case of Scan, you're being charged for all the rows scanned, not the total amount of items returned. Therefore, always prefer queries over scans to minimize read costs.

5. Avoid strongly consistent reads and transactions where possible

DynamoDB uses an eventually consistent data model. It means that updates are propagated across all storage locations, usually within one second or less. However, DynamoDB supports strongly consistent reads too, but with an additional cost. Strongly consistent reads require double the amount of Read request/capacity units than eventually consistent reads. Similarly, transactions also incur additional costs due to the two-phase commit protocol they use.

6. When using GSIs, think about Attribute Projections

Attribute Projections specify which attributes are available when querying for data using Global Secondary Index. Sometimes, when accessing the data using GSIs, not all attributes are needed. Reducing the amount of data available in GSIs by using Attribute Projection KEYS_ONLY or INCLUDES instead of ALL will reduce the amount of data kept in GSI significantly, thereby lowering not only the storage costs but also consuming fewer read/write units when accessing or updating the data.

7. Use on-demand mode wisely

As Yan Cui demonstrated in his blog post, "rough estimate suggests that on-demand tables are around 5–6 times more expensive per request compared to a provisioned table". Conclusion: if your workload has steady utilization without sudden spikes, consider going with provisioned mode with autoscaling enabled. You can simulate costs by using our DynamoDB Pricing Calculator.

8. Use reserved capacity

When using provisioned capacity mode and your capacity is bigger than 100 units, you can also consider purchasing reserved capacity. For a three-year term, reserved capacity provides a 76% discount, and for a one-year term, reserved capacity provides a 53% discount when compared to provisioned throughput capacity. This can lead to significant cost savings for predictable workloads.

9. Remove unnecessary items

To minimize the storage costs, aim to always purge unnecessary data. If your business does not have to keep the events older than X days, you can leverage the TTL functionality. TTL automatically deletes expired items from your table, reducing storage costs.

Moreover, if you have any many-to-many relationships, remember that you need to take care of "orphaned records" on your own. As DynamoDB is not a relational database, it does not have an ON DELETE CASCADE feature like many RDBMS. Regularly auditing and cleaning up orphaned records can help in reducing unnecessary storage costs.

10. Do not overuse GSIs

DynamoDB automatically copies the right set of attributes to any indices where the attributes must exist. This increases the costs of your storage because of the additional space used. In detail, it is a sum of:

• Byte size of table primary key
• Byte size of index key attribute
• Byte size of projected attributes
• 100 byte-overhead per index item

11. Monitor and optimize your usage

Regularly monitor your DynamoDB usage using AWS CloudWatch and other monitoring tools. By keeping an eye on your read/write capacity units, storage usage, and other metrics, you can identify patterns and optimize your usage accordingly. For example, you might find that certain times of the day have higher traffic, allowing you to adjust your provisioned capacity or use auto-scaling more effectively. Additionally, consider using AWS Cost Explorer to analyze your spending and identify areas where you can save costs.