Strategies to reduce Amazon RDS Costs
In this article, we will give describe some strategies to reduce Amazon RDS costs. This article is part of our How to reduce AWS Costs article series.
Amazon RDS is a relational database service. The standard approach to deploy a database is by installing it on your OS. Instead, Amazon RDS provides a Database-as-a-Service. And AWS takes care of hardware provisioning, database setup, patching, and backups. Thus Amazon RDS will simplify the operation and maintenance of your DB.
But one of the main problems with relational databases is that they scale vertically. The database grows with time. And you need to use bigger hardware. That makes database costs to increase fast.
For this reason, our objective is to describe some strategies to reduce your Amazon RDS costs. Note that each strategy has to be analyzed with the requirements of your workload. And you should use the strategies that work best for you.
1. Changing the DB engine
Amazon RDS supports 6 different types of relational database engines: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and Amazon Aurora.
These are all relational database technologies. The first 3 ones are open source database technologies. Oracle and Microsoft SQL Server are proprietary database technologies. And the last one, Amazon Aurora, is an AWS proprietary database. But it’s compatible with my MySQL and PostgreSQL.
The following picture compares the monthly price of a db.r5.xlarge OnDemand DB engine in us-east-2 (Ohio) region using Single-AZ configuration.
These 10 DB instances all use the same HW (a db.r5.xlarge instance). But the price has a huge variation based on the DB engine type.
Note that the 3 open source databases (MySQL, PostgreSQL, MariaDB) almost have the same price. And they are the most economical. And Amazon Aurora is a bit more expensive than them.
Amazon RDS engine pricing includes the licensing for the corresponding database engine. So it’s not necessary to bring your license (BYOL) for this service. The cost of Microsoft (or Oracle) database licenses is already included in the RDS service price. For this reason, these are more expensive than the rest.
Changing the database engine is not a simple task. Not only the database data has to change. You have to make sure the code using it could also be changed. And your team has to know how to use it.
But having that said, it’s important to note that the type of database technology will have a big impact on your costs. If you can change the technology of your database, that could avoid the licensing fees. For example, if you change from RDS for Oracle SE2 to Aurora PostgresSQL, you will save 44% monthly.
In case you decide to migrate your database, you can use AWS Database Migration Service. This is a tool that allows you to migrate your database (and schema) to a new engine. And it’s free (you only pay for the EC2 instance to run it).
2. Using Amazon EC2 instead of Amazon RDS
This strategy is probably an option that no cloud specialist will mention. But it’s worth evaluating. As we mentioned before, Amazon RDS has lots of benefits and makes the database administration much easier. But it also brings higher costs.
Let’s compare the cost of a database in EC2 and RDS. We will use an on-demand EC2 r5.xlarge instance which has 4 vCPUs with 32 GiB of memory. It uses the same hardware as the db.r5.xlarge database. Here are the results:
| EC2 AMI | EC2 Price ($) | RDS Price ($) | Savings |
|---|---|---|---|
| Windows Server 2019 with SQL Server 2019 Enterprise | 1393.92 | 1800.72 | 23% |
| Windows Server 2019 with SQL Server 2019 Standard | 659.52 | 1094.4 | 40% |
| Windows Server 2019 with SQL Server 2019 Web | 362.88 | 633.6 | 42% |
| Linux with SQL Enterprise | 1261.44 | 1800.72 | 30% |
| Linux with SQL Standard | 527.04 | 1094.4 | 51% |
| Linux with SQL Web | 230.4 | 633.6 | 63% |
| Linux | 181.44 | 345.6 | 47% |
For example in the first row, the price of Amazon RDS with SQL Server is $1800.72 per month (in Ohio). If we host the in an EC2 instance with Windows Server 2019 with SQL Server 2019 Enterprise AMI, the price is $1393.92 per month. That’s 23% below RDS price. And if we use it on an EC2 with “Linux with SQL Enterprise” the cost will be 30% less.
In the last row, the price of Amazon RDS MySQL-compatible is $345.6 per month. But hosting the database on an EC2 with Linux AMI costs $181.44. That’s 47% less.
Additionally, hosting a database on Amazon EC2 will also bring more flexibility regarding the types of EC2 instances you can choose. For example, there are 254 types of EC2 instances and only 18 RDS database instance types.
You can choose this strategy if you want to reduce your database costs, and you can afford the overhead of deploying and maintaining the database yourself.
3. Right-Sizing your database instance
This strategy consists of choosing the right database instance for your workload. The good point is that there are only 5 families of databases instances: “t”, “m”, “r”, “x” and “z”. And the number of instance types is low as well (compared with the number of AWS EC2 instance types). For example, there are currently 22 database instances for Amazon RDS for PostgreSQL. This makes the decision easier.
How to decide what is the best database instance for my workload? The right approach is to determine your database requirements (including memory, CPU, IOPs, and others). And then choosing the most cost-effective instance that complies with them.
You can start monitoring your database using CloudWatch Metrics for RDS. Metrics like CPUUtilization, FreeableMemory, and ReadIOPS are very useful to understand the utilization of the CPU, memory, and storage. You can also enable Enhanced Monitoring (it has a small fee). This will show how each process in the database is using memory and CPU.
Here is a quick approach to filter database instances. First, you visit EC2 instances info. You choose RDS and your region. Then remove the unnecessary price columns (for example, all price-related columns except “MySQL On-Demand Cost”). And afterward, you add the required GiB in the Memory filter. For example, if your database uses 9 GiB of memory, so might choose 16 GiB. You will get a list with all the instances that match this memory size, and they will be ordered by the lowest cost. For example, after setting the filters, we got only 9 database instances types. And finally, you could choose the right instance according to the estimated CPU usage. Here you have both price and hardware characteristics of the database instances, and this will simplify your decision.
Note that each time you switch to a smaller instance, the database half the previous size (except some specific cases). And you will save 50%. That’s why it’s very important to find the right instance size for your workload.
4. Using Reserved DB Instances
Reserved Instances allows you to save money by committing to use the database instance for 1 or 3 years. You purchase a Reserved Instance plan, and that gives you a discount.
For example, here are current Amazon RDS savings expected for a MySQL database using a db.r5.xlarge DB instance in Ohio.
| Payment Option | Monthly Price (r5.xlarge) | Savings over On-Demand |
|---|---|---|
| On-Demand | 345.6 | |
| Reserved 1 year (No Upfront) | 199.44 | 42% |
| Reserved 1 year (All Upfront) | 186.48 | 46% |
| Reserved 3 year (All Upfront) | 125.28 | 64% |
Purchasing Reserved Instances will allow you to save 30% to 64% (depending on the payment term, region, database engine, and instance type). So you should evaluate if this works for your workload.
5. Stopping and Starting database engines
The database instance is charged proportionally to the time it’s running. You can stop your testing instances after business hours, or when they aren’t used. This can be done using the console. Or you can automate stopping (and restarting) the database instances at certain times of the day.
For example, let’s say that you use some database instances on standard business hours only. That’s 45 hours a week (out of 168 hours). So you will save 73% of the costs of this database instance.
Keep in mind that when your database is not running, you will still pay for the storage and snapshots used. Additionally, a database can be stopped for up to 7 days. After this period, AWS will start it automatically.
Stopping and starting the database instances is available only to instances with Single-AZ configuration and without Read replicas.
6. Using Aurora Serverless
In case you are using Aurora, you can switch to Aurora Serverless. It automatically scales the database instance hardware (assigning up to 488 GiB of memory). AWS charges you proportionally to the provisioned compute in terms of ACUs.
But apart from autoscaling, Aurora Serverless will pause your database if you aren’t using it. When that happens, you will only be charged for storage (but not for the DB instance).
The most important point is that the database instance will scale to accommodates current usage. In contrast, a typical database will be over-dimensioned according to the maximum usage expected. And probably most of the time the real usage will be much lower. So normally, you will be paying unused resources. Aurora avoids resource over-provisioning, and this will reduce your costs.
Note that Aurora Serverless still has limited functionality compared to standard Aurora. But it’s still a great option for an environment with highly variable workloads, or testing environments.
7. Disable Multi-AZ
Multi-AZ is a feature to increase the availability of your database. It creates a secondary DB instance on another Availability Zone (AZ) which synchronously replicates the data from the main engine. It’s in standby mode and doesn’t respond to queries. But in case of a failure of the main instance, RDS service performs a failover to this standby instance.
Note that the Multi-AZ feature doubles the hardware used for database instance and storage. Your cost will duplicate as well. Multi-AZ is a great feature for production workloads. But it’s probably not useful for developing environments.
If there is any database where the price is more important than availability, then you should probably disable Multi-AZ. And you will reduce that instance cost by 50%.
8. Changing the database Region
Some regions are more expensive than others. You should probably find out if it’s worth moving your database instances to a region. Anyway, this won’t have a big impact on the price (except that you are using the Sao Paulo region).
For example, here is the ranking of Amazon Aurora PostgreSQL hourly cost for a db.r5.large (without reservation). You can see that US regions are the most economical, and then European ones.
| Name | Hourly Cost |
|---|---|
| US East (Ohio) | 0.29 |
| US East (N. Virginia) | 0.29 |
| US West (Oregon) | 0.29 |
| Europe (Stockholm) | 0.3 |
| US West (N. California) | 0.32 |
| Canada (Central) | 0.32 |
| Europe (Ireland) | 0.32 |
| Asia Pacific (Mumbai) | 0.33 |
| Europe (Paris) | 0.335 |
| Europe (London) | 0.34 |
| Europe (Frankfurt) | 0.35 |
| Asia Pacific (Seoul) | 0.35 |
| Asia Pacific (Singapore) | 0.35 |
| Asia Pacific (Sydney) | 0.35 |
| Asia Pacific (Tokyo) | 0.35 |
| Middle East (Bahrain) | 0.352 |
| Africa (Cape Town) | 0.381 |
| Asia Pacific (Hong Kong) | 0.385 |
| South America (São Paulo) | 0.6 |
9. Right-Sizing Database Storage
Amazon RDS supports 3 types of storages:
- General Purpose (SSD) Storage
- Provisioned IOPS (SSD) Storage
- Magnetic Storage
The number of input/output operations per second that the storage can perform is called IOPS. General Purpose SSD storage assigns a baseline IOPS performance. And it also has bursting capacity. That means that the storage can respond with higher IOPS than the baseline, but only for short periods.
The baseline performance is proportional to the storage provisioned. So the more GiB you provision in your storage, the more operations per second it can perform. This type of storage is recommended by AWS for most workloads, and it’s the least expensive. And you only pay for the GiB provisioned. Note that Magnetic storage has some limitations, and isn’t recommended.
When your database operations grow, at some point the baseline IOPS rate will be insufficient. If you are using General Purpose SSD, then you should first try increasing the database storage size. This will increase the IOPS baseline proportionally. You get a baseline of 3 IOPS for each GiB that you provision (with a minimum of 100 IOPS, and maximum 16000). For example, for 100 GiB storage, you get a baseline of 300 IOPS. If you provision over 5334 GiB for the storage, then the IOPS rate will keep at a maximum of 16000.
Provisioned IOPS (SSD) Storage is recommended for I/O-intensive workloads. When you use this storage, the cost per GiB used us higher than General Purpose (SDD) storage. You also have to pay for the IOPS provisioned. The minimum storage size is 100 GiB, and the minimum provisioned rate is 1000 IOPS. For all these reasons, this storage type is the most expensive. You should use it only when you need more than the maximum IOPS rate supported by General Purpose (SDD) storage.
When using any type of these storages, you have to right-size them. A low IOPS rate will make your database respond slowly. But a high IOPS rate will generate unnecessary costs. So you should analyze if the provisioned rate is acceptable for your database workload.
You can check current storage usage with Amazon Cloudwatch metrics (for example ReadIOPS, WriteIOPS, ReadLatency, and WriteLatency). And you can also set up alarms to indicate when thresholds are exceeded.
10. Using Storage AutoScaling
When you initially create a database in Amazon RDS, you will assign a certain fixed storage capacity (GiB) for the database. As the database grows, you have to periodically verify that storage free space is enough. To keep up with this growth, you have to manually increase the storage space provisioned. Sometimes the future capacity isn’t well known, and storage could be over-provisioned. But remember that you pay for each GB provisioned, even if it’s not used. So this over-provisioning will cost you money.
Now Amazon RDS supports Storage Autoscaling. This feature automatically expands the RDS storage size when free space is low. So first, you don’t have to check the space used. But also, the storage will grow gradually as needed. And this will allow you to reduce your costs.
11. Reducing Retention Period
You can enable automatic backups setting in Amazon RDS. In this case, AWS will keep performing database backups. And you can restore the database within any point within your retention period (max. 35 days). The storage used from backups is billed according to the Backup Storage rate. AWS has a free storage free tier equal to the storage you provision in your database. For example, if your storage is 100 GiB, you will get 100 GiB free for backups and snapshots. But each GiB over that limit will be charged. So if you reduce the Retention Period, you will use less backup storage, and probably reduce your costs.
12. Removing manual snapshots
Amazon RDS manual snapshots are backups initiated by the user. They aren’t removed by AWS, unless you request it. So if you don’t explicitly remove them, they will become obsolete. You can even remove the database, and the snapshot will still be there. And remember that AWS will charge you according to Backup Storage rate.
It’s a good idea to review old snapshots and remove the unused ones. Snapshots rate is $0.010 / GiB / Month (in Ohio region). So each TiB of will save around ** $10** for each of the following months.
Also, keep in mind that it’s easier to have automatic backups instead. They will be always up to date, and AWS will remove the old automatic backups (which exceed your retention period). Additionally, storage backups (and snapshots) are stored in S3 with redundancy across AZs. That makes them highly available and secure, so you probably don’t need too many additional snapshots.
Summary
There are many alternatives to reduce Amazon RDS costs. We have described some of them, but probably they are not the only ones. You should choose the ones that work best for you. And start implementing them.
We hope you enjoyed the article. And if you find it useful, please share.