DynamoDB Pricing Calculator

DynamoDB cost optimization: ten practical checks

Start with the largest line items on your bill: throughput, table and index storage, then backups and optional services. These ten checks help reduce costs without changing the application's consistency requirements.

1. Use cheaper regions

Compare Regions only after checking application latency, data residency and transfer charges. For 100 GB-month of Standard storage before the free tier, the listed rates give $28.50 in Tokyo, $29.72 in London and $37.50 in São Paulo. The calculator applies any unused allowance separately. Among its supported Regions, US East (N. Virginia), US East (Ohio) and US West (Oregon) use $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 shortening attribute values 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 numeric epoch seconds instead of ISO dates when appropriate. It also makes your items compatible with DynamoDB's TTL feature.

3. Be aware of huge blobs

Saving images 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 DDB. If that's not an option, consider using compression algorithms like gzip to make blobs smaller before saving them.

4. Prefer queries over scans

Query reads items matching a partition key and an optional sort-key condition. Scan examines the whole table or index unless you stop it early. Both operations charge for items evaluated before applying a filter, not just the items returned. Query usually costs less because its key condition narrows the data evaluated; projection and filter expressions do not reduce that read charge.

5. Avoid strongly consistent reads and transactions where possible

Eventually consistent reads consume half the units of strongly consistent reads for the same item size. Use strong reads when the application must see the latest successful write, and transactions when it needs their atomicity guarantees. Transactional reads use twice the units of ordinary strong reads, while transactional writes use twice the ordinary write units. Global secondary indexes offer eventual reads only.

6. Choose GSI attribute projections carefully

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 INCLUDE instead of ALL will reduce the amount of data kept in GSI significantly, which lowers storage costs and consumes fewer read/write units when accessing or updating the data.

7. Compare capacity modes with current rates

AWS recommends on-demand for most workloads after its November 2024 price cut. At full utilization in US East (N. Virginia), on-demand unit cost is about 3.5 times ordinary provisioned capacity, with a break-even near 29% utilization before allowances and discounts. Provisioned capacity can save money for steady demand, but include auto scaling headroom and idle hours in the comparison.

8. Evaluate reserved capacity and Savings Plans

For a predictable Standard provisioned baseline, reserved capacity is sold in blocks of 100 RCUs or WCUs, with savings of up to 54% for one year or 77% for three years in eligible Regions. Compare the upfront and recurring costs, and avoid committing capacity you will not use.

Database Savings Plans offer up to 18% off eligible on-demand throughput or 12% off provisioned throughput for a one-year commitment, with flexibility across eligible database services and Regions. Reserved capacity is applied first; discounts do not stack on the same usage.

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 use the TTL functionality.

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.

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 and index maintenance writes. Keep indexes that serve actual access patterns, and measure projected item sizes. Index storage contains the following, counting overlapping key attributes only once:

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