Eight ways to lower your DynamoDB costs
When it comes to hosted NoSQL database services, look no further than Amazon DynamoDB. Fully managed, fast, and boasting powerful horizontal scaling capabilities, DynamoDB has been one of the most talked about AWS services since its release in 2012 as the implementation of Amazon’s own Dynamo principles.
It’s a powerful tool, but making the most of DynamoDB depends on cost-effective implementation. Here are eight of the most effective practices we’ve found for optimizing your spending on DynamoDB.
1) Understand how DynamoDB is priced
The first step of optimizing your DynamoDB costs is understanding how the service is billed.
When using DynamoDB, you pay a flat, hourly rate based on how much capacity you have provisioned. Capacity is provisioned according to a number of Write Capacity units, and a number of Read Capacity units. Each Write Capacity unit can perform up to 36,000 writes per hour, and each Read Capacity unit can perform up to 180,000 strongly consistent reads per hour, or 360,000 eventually consistent reads per hour. There is a different price for Write Capacity units than there is for Read Capacity units, and these prices differ based on Region.
With this billing model in mind, many of your primary considerations when cost-optimizing your DynamoDB usage will be related to lean, strategic provisioning.
Watch our free webinar: Mastering the Fundamentals of AWS Cost Management to learn more about controlling your AWS costs
2) Choose a cost-effective Region
As we know, cross-regional data transfer can be a major cost driver. So don’t rely solely on Write Capacity and Read Capacity unit pricing when determining the most cost-effective Region for your DynamoDB database. Remember that you’ll pay extra if you’re regularly transferring data across Regions, and weigh whether those extra fees will render a seemingly cheap Region the more expensive option.
3) Don’t discount Eventually Consistent Reads (unless you have to)
For the same price, AWS allows you to do more Eventually Consistent Reads per hour than Strongly Consistent Reads. This means that you can get a lower price-per-read by selecting the Eventually Consistent Reads option, if Eventually Consistent Reads will satisfy your read demands.
When determining whether your needs will be sufficiently served by Eventually Consistent Reads, consider the difference between Eventually Consistent Reads and Strongly Consistent Reads and the impact that an inconsistent read would have on your business. Whereas Strongly Consistent Reads will guarantee read-write consistency, Eventually Consistent Reads will result in slightly out-of-date data. How severe of an issue would the delivery of slightly out-of-date data be? Is your data so voluminous that even old data will be accurate within significant digits? It’s possible that Eventually Consistent Reads will be more than sufficient for your needs, in which case you can achieve a lower price-per-read.
4) Provision properly
Capacity planning is obviously a huge aspect of ensuring cost efficiency for DynamoDB. You’ll need to anticipate how many writes and reads your application will need to perform per day, and provision the corresponding number of Write Capacity units and Read Capacity units (recalling that each Write Capacity unit can perform up to 36,000 writes per hour, and each Read Capacity unit can perform up to 180,000 strongly consistent reads per hour, or 360,000 eventually consistent reads per hour).
Unlike RDS, DynamoDB allows you to uniquely provision reads and writes. This means that you can more efficiently tailor your capacity to your needs by favoring more reads or more writes if necessary—be sure to take advantage of this fact in order to minimize unnecessary spending.
5) Know how and when to scale
It’s important to note that you can’t autoscale with DynamoDB; any scaling you want will involve some manual reprovisioning or some coding. Either way, you’ll want to understand your read and write trends over time to determine the necessity of scaling. Is your workload seasonal? Are demands significantly higher from 9-5?
Before you start forming your scaling battle plan, note that DynamoDB does offer something called burst capacity. When you don’t fully utilize your provisioned capacity, a portion of that unused capacity gets reserved for use during later spikes. DynamoDB currently reserves up to 5 minutes of unused read and write capacity, and there’s no guarantee that burst capacity won’t be used by Amazon for other tasks, but if you experience occasional bursts that aren’t too dramatic, your burst capacity can likely cover it.
6) Stay on top of things with CloudWatch
Monitoring your DynamoDB usage is key to ensuring that you’re provisioned properly (and to taking advantage of Reserved Capacity, but more on that below). Fortunately, DynamoDB and Amazon CloudWatch are integrated, which allows you to gather and analyze performance metrics within CloudWatch based on one- or five-minute intervals. You’ll want to regularly monitor your DynamoDB usage to ensure that you’re properly provisioned; should you find that you regularly have excess capacity, reprovisioning your Read Capacity units and Write Capacity units to match your demands will allow you to cut some wasteful spending.
7) Take advantage of Reserved Capacity
In addition to provisioning normal capacity, DynamoDB users can choose to provision Reserved Capacity. Much like an EC2 Reserved Instance, DynamoDB Reserved Capacity offers savings over the normal price of DynamoDB in exchange for paying for the capacity in advance. In other words, you can choose to commit to using a certain amount of Write Capacity and Read Capacity units in exchange for a lower price for those units. Should you not use those units, however, too bad for you—you still have to pay for them.
Taking advantage of Reserved Capacity can represent a huge source of savings over paying standard prices. You’ll just have to be sure how much capacity you’ll use. Reserve too little capacity, and you’ll end up paying standard prices where you could have had a discount. Reserve too much, and you’ll pay for capacity that goes unused.
You can determine how much capacity you can safely reserve by referencing your DynamoDB CloudWatch metrics. However, it’s very important to note that these CloudWatch metrics are based on one- or five-minute samples. You can achieve a more reliable understanding of your usage patterns by examining many of these samples over time in order to even out potentially misleading peaks or valleys in demand.
8) Monitor, adjust, repeat
Each of the above considerations can help you trim your bill, but ensuring long-term cost-efficiency for DynamoDB is an ongoing process. Fortunately, it’s not a very complicated one. Simply check your performance metrics regularly to ensure that your provisioning is aligned to your needs; Cloudability users might want to reference reports such as DynamoDB Last Month Total Invoice Cost for RW in All Regions and DynamoDB Last Month Data Transfer Costs Across Regions. Should you discover a shift in alignment, just adjust your provisioned capacity accordingly in order to ensure ongoing cost-efficiency.
Want to learn more about optimizing your spending across AWS services? Subscribe to receive more tips, tricks, and strategies delivered straight to your inbox.