* Price calculations using AWS Price List API

In a previous post, I wrote about how to save money on your AWS bill using EC2 Reserved Pricing. Even though Reserved Pricing is mainly known due to EC2, the good news is that many other AWS services offer a way to reduce cost by purchasing reserved capacity.

One of them is Relational Database Service (RDS). Since RDS cost can quickly become an expensive line item in your AWS bill (sometimes even higher than EC2), purchasing RDS Reserved capacity can go a long way towards saving you a lot of money.

In this article I will walk you through some essential concepts and I’m also including live calculations, tips and the steps I follow when purchasing RDS Reserved instances.

Let’s first go through a few basic concepts relevant to RDS and Reserved Pricing…

Relevant Price Dimensions in RDS and Reserved Pricing.

AWS RDS is a managed service that launches and maintains database servers for you. Similar to EC2, the default option is On Demand, which means you pay exactly for the amount of time your servers are running. At the time RDS only supports hourly billing, while EC2 supports per-second billing. But when you purchase RDS Reserved capacity, you commit to a 1-year or 3-year period.

Even though there are many price dimensions that will affect your RDS bill, these are the parameters that will affect your RDS Reserved decision:

• Database Instance Class. RDS launches and manages database servers that run on EC2 instances, so you need to pay for compute time. There are a number of RDS DB instance classes available, such as db.t2.medium, db.m5.large, db.r4.large, etc. They’re basically a subset of available EC2 instance types, but they cost more compared to their EC2 counterparts (anywhere between 40%-70% more depending on instance type, DB engine and license model).
• Database Engine: MySQL, MariaDB, PostgreSQL, Aurora MySQL, Aurora PostgreSQL, SQL Server and Oracle.
• License Model. Some engines are open source while others require you to pay for a license. There are 3 license models supported: license included (you pay for the license through RDS), bring your own license (use a license you’ve already purchased) and general public license (no license fee: MySQL, MariaDB, PostgreSQL and Aurora)
• Redundancy options. You can choose options such as Multi-AZ deployments or read replicas if you’re using a DB engine that supports this feature, such as Aurora, MySQL, MariaDB, SQL Server and PostgreSQL.

It’s important to understand these price dimensions, since they are slightly different compared to EC2 instances, particularly Database Engine and License Model. Not all DB instance classes are available for all DB engines. Also, in most cases bringing your own license or using an open source engine will maximize the amount of savings related to Reserved pricing.

Similar to EC2 Reserved, with RDS Reserved you save money by committing to a 1 year or 3 year period for a particular RDS DB instance class and database engine. The example below shows MySQL running on a db.m5.large DB instance in N. Virginia (us-east-1). You can choose a different instance class/size, region or DB engine from the drop-down.

There are other parameters, such as disk storage, I/O requests, snapshot storage and data transfer, which will have an impact on your RDS bill - but they’re not related to RDS Reserved pricing.

Terms and Payment Options

In RDS you can purchase reserved compute capacity for 1 year and 3 year terms, which are the same parameters you find in EC2.

Also, similar to EC2, you have the following payment options:

• All Upfront. 1-time payment covering the full term (1 year or 3 years)
• Partial Upfront. A portion of the full amount over the chosen term (also 1 year or 3 years). The rest is paid monthly.
• No Upfront. You commit to the full term and pay a regular fee every month.

You save more money if you choose a longer term and if you pay all upfront.

If you look at the different options, you’ll probably notice that in some cases No Upfront vs. All Upfront results in a small price difference (3%-5%). In those cases, it might be a good option to go with No Upfront and pay monthly instead of spending hundreds (or even thousands) of dollars upfront.

But there are also cases where the difference between All Upfront and No Upfront can be about 10%. In those situations, it might be worth paying upfront and get higher savings. It’s up to you and your tolerance for an upfront payment.

TIP: Always calculate cost for All Upfront, Partial Upfront and No Upfront. Choose according to your tolerance for 1-time large payments and the savings difference between All Upfront and No Upfront.

Instance Size Flexibility and Offering Classes

RDS only offers Standard Offering Class and it supports Instance Size Flexibility, which makes things simpler compared to EC2. This means:

• Once you purchase RDS Reserved for a particular DB instance family (i.e. db.m5, db.r4, etc.), you cannot apply that reserved discount to a different instance family. Unlike EC2, RDS doesn’t support Convertible reserved purchases.
• Within a DB instance family, your Reserved discount gets applied to instances of that same family, regardless of size. Let’s say you purchase 1 Reserved db.m5.xlarge instance for RDS MySQL. If you have 2 db.m5.large instances, the Reserved discount will be applied to both of them.
• Instance size flexibility applies to the following engines: MySQL, MariaDB, PostgreSQL, Aurora (MySQL and PostgreSQL) and Oracle Bring Your Own License. Since licensing for commercial products - such as Oracle or SQL Server - often depends on the number of CPU cores in your setup, applying instance size flexibility is not supported for MS SQL Server and Oracle. The only exception is “bring your own license” for Oracle.

Here’s a comparison showing all payment options (don’t forget to try different instance types, regions and to hover on the chart for more details):

Savings vary by AWS Region

Just like other services, you should expect cost to vary by AWS Region. When it comes to RDS Reserved, not only cost but also the percentage of savings compared to On Demand.

The following graph shows the difference between Reserved Standard All Upfront vs. On Demand. You can select a different instance type and DB engine from the drop-down. Hover on the chart to see more details regarding savings.

Avoiding Important Risks in RDS

Inaccurate Provisioning

This is probably the most important risk in any Reserved purchase - RDS or otherwise. Since you’re committing to a long-term purchase, you need to have high confidence that you’ve chosen the right DB instance for your application.

This risk is even more important in RDS given that compute cost is higher compared to an EC2 purchase. Also, since RDS doesn’t offer flexibility between instance families, you have to be sure that you’ve chosen the right instance type based on resource demands from your application (i.e. disk I/O, CPU, memory, networking).

That’s why it’s very important to execute load tests and monitor your application in Production before making an RDS Reserved purchase decision.

Are new RDS Instance Classes cheaper?

Just like EC2 (and all AWS services that involve compute capacity), over time you can expect AWS to release new RDS DB instance classes. For example, db.m5 is an improved generation compared to db.m4. If you’re committing to a 1-year or 3-year term, you want to make sure that you take advantage of the best possible DB instance class for as long as possible.

In the case of RDS, price hasn’t varied that much for newer instance families, as of now. Here are some examples for RDS MySQL:

It’s good to know that based on this historic data, you can commit to 1 year and not expect new instance families to be significantly cheaper compared to the price you’ve already committed to. When it comes to a 3-year commitment, given the higher percentage of savings, new instance families with potentially lower cost are also not a high risk.

That being said, newer generations of instance types often bring improvements in terms of performance and resource optimization. If you commit to 3 years, you’ll likely miss the chance to use a better instance type, but your cost savings will be much greater over time.

RDS Reserved Important Metrics

Similar to EC2 Reserved, the following numbers are relevant to your purchase decision:

• Savings vs. On Demand. Dollar and percentage amount saved by purchasing Reserved compared to On Demand. Calculate for the whole period - 1 year or 3 years.
• Upfront Fee and Savings. This applies to All Upfront and Partial Upfront. Since this fee can result in thousands of dollars spent upfront, it’s important to be clear on what the amount will be and the long-term savings you’ll get in return compared to the No Upfront option.
• Months to Recover. How much time you have to wait before you start to see savings compared to On Demand pricing. This is relevant for All Upfront and Partial Upfront, since No Upfront results in savings from day-1.

Comparing All Options

In the following chart you’ll visualize the different Purchase Options (All Upfront, Partial Upfront, No Upfront) and terms (1 year vs. 3 years). You can select instance type, engine, region and term from the drop-down.

The chart displays how cost accumulates throughout your commitment period and it shows Months to Recover (MtR) as vertical annotations. Hover over the chart to see more pricing details.

A Step-by-Step Process for RDS

Just like any other Reserved purchase, it’s highly recommended to have a repeatable, step-by-step process. This will help you maximize savings. The process is similar to the one I highlighted for EC2 instances, but it has some differences that apply only to RDS.

1. Gather All Relevant Data

Analyze Billing Data

You can get this information in AWS Cost Explorer, but analyzing AWS Cost and Usage Reports can give you more detailed information, so it’s worth the extra effort.

Find the top 10 Usage Types by cost in your AWS bill. Calculate the percentage they represent of your total bill. If RDS is an important part of your AWS bill, confirm that compute cost represents an important portion of your RDS spend, since this is the area where you can lower cost by purchasing RDS Reserved. In most cases, compute is the highest cost for RDS.

Gather and Analyze System Metrics

• If your application is already in Production, make sure it’s been exposed to the type of usage you expect in the long term. You should measure system metrics during periods of steady usage as well as steep spikes.

Analyze the following metrics:

• CPU Utilization
• Memory Utilization
• Disk I/O and Throughput
• Network Usage

Ask the following questions, based on analyzed metrics:

• Is there an RDS DB instance type that could deliver better performance? For example, one with more memory or CPU capacity? Is network an area that should be optimized? You can find more information on DB Instance Classes here.
• Would performance be improved by adding read replicas (if supported by your DB engine)?
• Does your application need a Multi-AZ deployment? Multi-AZ delivers increased availability, at a cost. Enable this feature based on how critical is the stage you’re deploying your application into and your own SLAs and availability requirements.
• Are there RDS database instances that are under-utilized? Can you switch to a smaller instance type without putting your application at risk?

The main objective in this step is to make sure that you’ve chosen the right RDS DB instance type. This way you can commit to a 1-year or 3-year period with good confidence that you’ve chosen the right option.

2. Apply Optimizations and Wait

If you found that you need a different RDS instance type in Production, apply the necessary changes (after you’ve validated them in test environments, of course).

• Monitor system and customer experience metrics for a period of time.
• Confirm you’ve provisioned the right DB instance type and size for your application.
• Confirm there are no RDS DB instances that are under-utilized.

3. Calculate the right amount of RDS Reserved instances and Terms

You can only arrive at this step once you’re confident you’ve chosen the right RDS instance type for your application as well as other features, such as read replicas and Multi-AZ deployments.

Normalization Factors are also important in RDS

If you’re buying Reserved DB Instances with an open source DB engine (i.e. MySQL, MariaDB, PostgreSQL), then your instances are eligible for instance size flexibility. I recommend that you become familiar with normalization factors.

For example, a db.r5.2xlarge is 4 times the size of a db.r5.large, or a t3.large is twice the size of a t3.medium. This relative size is also applied to billing.

A common practice is to buy reservations for the smallest normalization factor. For example, if you conclude that you need 1 db.r5.xlarge, then buy 2 r5.large reservations (assuming your DB engine supports Instance Size Flexibility).

Calculate the payment options

This is the final step. It comes down to choosing:

• All Upfront vs. Partial Upfront vs. No Upfront. Remember that the higher the upfront fee, the higher the savings over the whole term. There are cases where savings are significant depending on the upfront payment - but there are cases where they’re not. It really helps to take a look again at this chart and evaluate your numbers for DB engine, instance type, region and term.
• 1 year vs 3 years. The longer the term, the higher the savings - sometimes up to about 65% compared to On Demand.

To Summarize

This diagram summarizes the steps described in this article:

Do you want to lower your AWS cost?

Avoid overspending on AWS. If you’re not sure how to lower your AWS cost, or simply don’t have time, I can help you save a lot of money. Click on the button below to schedule a free consultation or use the contact form.