In this post, we’ll review the different points to take into consideration when optimizing your RDS resources for cost. The goal is to have the most cost-effective infrastructure without sacrificing performance. We will go over architecture decisions, instance type selection, storage options, scaling options, and finally reserved instance purchases.

There are several points to take into consideration when it comes to architecting a cost-optimized RDS implementation.

First and foremost RDS engine type selection will play into the cost. Without naming names a good majority of the enterprise databases will be quite a bit more expensive than the open source databases such as MySql or Postgres. If you have the opportunity to select your database engine of choice, it's generally more cost-effective to select open-source engines such as Postgres or MySQL.

This is an entire blog post on its own. The idea here is that you should do the homework to make sure that you are using the appropriate database for the job at hand. This could mean that you should use a NoSQL solution like DynamoDB, or a Mongo-compatible database like DocumentDB. Typically, we see unnecessary costs incurred when customers try and use the wrong database for the job.

Along similar lines to the previous topic. Often times we see poor query construction adversely affect the performance of the database. This in turn usually means that databases need to be scaled vertically to accommodate the increased load. AWS has tools like RDS performance insights, additionally, AWS CodeGuru can help in understanding expensive lines of code that may be affecting performance.

Caching in front of a database in order to help increase performance and reduce costs is frequently overlooked. There are three main types of caching.

Plenty more information here on caching.

Compared to the previous section this is a bit more straightforward. There are two main types of instance types to choose from; General Purpose and Memory Optimized. More often than not we end up with a general-purpose instance type but there are some use cases where the memory-optimized instance types make more sense. The best way to understand which is best suited for your use case is to actually test them out in a development environment. Proving infrastructure selections is often an overlooked portion of the development environment. Obviously, running a large production-sized instance in a development environment is ill-advised, but understanding how an application can effect database performance metrics is important.

Once you are able to understand the proper instance type, we will typically pick a Graviton2 processor. We’ve found that the price performance on these CPUs has been outstanding in most cases.

RDS is backed by Amazon EBS. There are three types to choose from; General Purpose SSD, Provisioned IOPS SSD, and Magnetic. General-purpose SSD is a good default choice for most workloads. There are two types for SSD volumes, GP2 and GP3, GP3 typically has better performance, and is a good choice for most workloads. Use provisioned IOPS for workloads that are intensive in i/o. Magnetic EBS shouldn’t be used except for cases where you need backward compatibility.

There are detailed explanations in the RDS User Guide

Similar to all of the other aspects of RDS and Aurora there are plenty of options to consider when talking about how to properly scale RDS. First and foremost we see a lot of customers that have provisioned a reader endpoint yet the application doesn't utilize it.

Aurora has more options for scaling in general and has plenty of options that will allow you to fully optimize your workloads. Some of the options available to you are:

Purchasing reserved instances is the easiest way to save money depending on the commitment you’re willing to make. However, this should be the last step you take after you have optimized the other aspects first. This is pretty straightforward and definitely should be done.