DynamoDB charges for three main things: read consumption, write consumption, and storage. Read consumption is measured in 4 KB increments for each read operation, while write consumption is measured in 1 KB increments for each write operation. Storage is measured in GB-months and represents the amount of data stored in the table or index.

The pricing is predictable, as you only need to consider the data you’re reading, writing, and storing. The cost calculation can be easily done using simple math, even during the data modelling phase.

‍

Some important points to note about DynamoDB pricing include:

• Read and write consumption is charged in increments, even if you don’t use the full increment.
• DynamoDB Query allows reading multiple items in a single request, reducing the number of RCUs consumed compared to reading each item separately.
• E.g., using a Query to read 100 items of 100 bytes each will cost you 3 RCUs (10 KB / 4 = 2.5, rounded up to 3). If you had read each of those 100 items separately, it would have cost you 100 RCUs!
• There are two types of read requests: strongly consistent and eventually consistent. Eventually consistent read requests consume half as many read capacity units (RCUs) as strongly consistent requests.
• DynamoDB charges for the data actually read, not the data returned to the client. Filter expressions don’t affect the cost.

‍

Improving Write Cost

DynamoDB writes are charged in 1 KB increments. If you write 100 bytes, you pay for 1 KB. 1.1 KB will be rounded up to 2 KB. Writing exactly 1 KB of items costs $1.25/GB (on-demand) but 100 byte items cost $12.5/GB (on-demand) to write to DynamoDB. 1.1 KB items cost $2.27/GB to write. A 100 byte item with 1 GSI costs $25/GB to write (on-demand).

The biggest optimization is to reduce 1.2 KB objects to reliably be under 1 KB.

This is easier than it sounds!

1. Use binary data types and compression

2. Use numbers or bytes to express dates

3. Use shorter attribute names

• Write operations are charged based on the larger size of the item before or after the operation.
• Condition expressions that fail still incur write capacity unit (WCU) charges.
• Using DynamoDB Transactions doubles the WCU usage due to the two-phase commit mechanism.

We can use a funky tool to calculate the size of a DynamoDB item.

‍

‍

Improving Read Cost

Reads are measured in 4 KB increments. This is why, even though write requests are 5 times more expensive than read requests, perfectly sized reads (4 KB) are 20 times cheaper than perfectly sized writes (1 KB).

‍

Choosing Billing Mode

When choosing between provisioned and on-demand billing modes, on-demand provides a fixed price for reads and writes, making cost calculations straightforward. However, for high-traffic workloads or situations where cost optimization is crucial, provisioned capacity can be considered. On-demand billing is approximately 6.94 times more expensive than fully-utilized provisioned capacity, but achieving full utilization is unlikely. Still, cost savings of around 71% can be achieved with 50% utilization.

‍

Calculation is provided below:

For 50% utilization:

0.00074$ = Price of RCU/hr

Number of units read per hour = Utilization * Max RCUs = 0.5 * (1 * 60 * 60) = 1800

Price for 1800 units = 0.00074$

Price for 1000000 units = 0.41111111111$

Price of on-demand = 1.4231$ per million records

Saving ratio = (1.4231–0.411111111)/1.4231 = 0.71111579579 ~ 71.111%

‍

‍

Ways to monitor and control DynamoDB costs:

1. Tracking view counts: Calculating the cost of incrementing a counter for each page view. By estimating item sizes and traffic, the cost can be roughly determined, helping to decide if optimization is necessary.

2. Avoiding unnecessary secondary indexes: Exploring scenarios where skipping global secondary indexes (GSIs) can save costs. Over-reading data and filtering in the application code can be more cost-effective than creating multiple GSIs.

3. Complex filtering: Dealing with scenarios where filtering a dataset by multiple optional attributes can be challenging in DynamoDB. Using index projections and reducing item size for filtering attributes can significantly reduce costs.

‍

This article demonstrates the importance of understanding item sizes, access patterns, and the trade-offs involved in designing DynamoDB data models to optimize costs.

‍