DynamoDB is one of AWS’s widely used services. Most of the clients we have worked with utilize Dynamo for some part of their system. Given that Dynamo is a fully managed service, many consumers can mistakenly think they have little ability to optimize it for cost efficiency.
In this post we share some recommendations that if applied can show significant cost reduction if you are using dynamo at scale and if you have a table with only a thousand records in it, applying these tips won’t hurt.
Before talking about the adjustments that can be done. Let’s understand how AWS charges its customers for using Dynamo. Each DynamoDB cost consist of primarily three components:
- utilized Capacity: this is the WCU, and RCU you have either provisioned or consumed .
- Storage: the total amount of data you store in a single Dynamo table.
- Data Transfer Out: the data that gets sent out from Dynamo to the internet or other regions. In most use-cases nothing is charged for DTO, since DynamoDB usually sits behind an app that is often running in the same aws region on some form of compute, either EC2, ECS, Labmda, etc.. But if your Dynamo table communicates across regions or with the internet directly, then it’ll incur DTO charges.
there are some other costs associated with Dynamo such as Backups and Point-in-time Recovery, which we skip and focus on how to optimize “ capacity consumption” and “Storage”.
1. Check if you’re using strong consistency and if it’s necessary
When performing READ operation against a table in Dynamo through api calls such as Query or GetItem by default it uses eventual consistency. However, We have seen cases where developers used ConsistentRead mode when retrieving records from Dynamodb for scenarios that eventual consistency would suffice. The side-effect of using ConsistentRead is that it will take double RCU for every READ operation as compared to eventual consistency thus leading to higher cost. So double check if you are using Strong consistency mode and if so verify if it’s really needed.
2. Check if you can benefit from Infrequent Access Storage mode
In some rare but probable cases you can reduce your Dynamodb Storage cost by moving to Infrequent Access (IA) storage mode which offers the exact same performance, but at 60% lower storage cost. from our experience two requirements has to be met in order for you to save money by moving to IA:
- Your DynamoDB storage costs account for 40% or more of the total DynamoDB expenses. To find out how much do you pay for storage cost, you can go to Cost explorer, and in the filter section, select “DynamoDB” as the service then select [REGION]-TimedStorage-ByteHrs (GB-Month) under “Usage Type” filter.
- Your workload is heavier on WRITE than on READ. as the name “Infrequent Access” implies, it is designed for use-cases where you don’t access records frequently. in “IA” mode you pay 25% higher than standard storage mode for RCU, thus it’s suitable for use-cases that read operations are less frequent.
3. Verify which consumption mode suites your workload the most
On demand is the default mode when using DynamoDB but moving to provision capacity can unleash significant cost reduction under certain circumstances.
Our recommendation is that you should stick to default on demand mode if:
- Your workload has unpredictable traffic.
- The variability in your traffic is large, meaning it can spike up or down by order of magnitude.
- There are times during day/week where there is zero or near zero traffic in your workload
if your workload look is similar to this, you are better off with on-demand mode. (Source AWS official guide)
On average if you consume 80% of your provision capacity, then provision capacity is going to be cheaper than On demand. but it requires your workload to be predictable.
In the event of using provision capacity, remember that you can leverage capacity reservation and get a significant cost reduction on top. capacity reservation is somewhat similar to EC2 reserved instance.
