How to Evaluate AWS RDS Pricing and Features

8 min readOct 18, 2019

AWS RDS pricing — like all Amazon cloud pricing — can be a bit confusing. In this post, we’ll walk through how RDS pricing works and other features of RDS you should know about.

Since its release, Amazon’s Relational Database Service (RDS) has become increasingly popular among organizations that are looking to simplify setting up, operating and scaling relational databases in AWS. An RDS is an automated service, which when implemented, will take over time consuming, mundane tasks. The ability to automate relational databases in the cloud has made RDS a cost-efficient option for those looking to control their cloud spend.

Traditional systems administration of servers, applications, and databases used to be a little simpler when it came to choices and costs. For a long time, there was no other choice than to hook up a physical server, put on your desired OS, and install the database or application software that you needed. Eventually, you could choose to install your OS on a physical server or on a virtual machine running on a hypervisor. Then, large companies started running their own hypervisor and allowed you to rent your VM for as long as you needed it on their servers.

In October 2009, Amazon started offering the ability to rent databases directly — without having to worry about the underlying OS — in a platform as a service (PaaS) offering called RDS. This service quickly became one more thing systems administrators should take into consideration when looking at their choices for infrastructure management. Let’s take a look at some of the features that come with AWS RDS and explore RDS pricing to get a better understanding of all the RDS costs.

RDS Basics

AWS RDS gives users the ability to run and manage cloud relational databases, changing the way users once interacted with cloud infrastructure. A great thing about RDS is that users don’t have to manage the infrastructure that the database is running on, RDS will take over many of the once tedious tasks that were necessary to manage an AWS relational database. This allows system administrators to focus their time on other, more important projects. Another great feature is that you don’t have to worry about patching off the database software itself.

The most essential part of Amazon RDS is an AWS DB instance. These instances are isolated database environments in the cloud. The computation and memory capacity of an RDS DB instance depends on its DB instance class. In AWS RDS, you can choose to use on-demand instances or reserved instances. Pricing and features will vary depending on the database engine and instance class you use.

You can currently run RDS on six database engines; MySQL, Aurora (MySQL on steroids), Oracle, Microsoft SQL Server, PostgreSQL, and MariaDB. The database sizes are grouped into 3 categories: Standard (m4), Memory Optimized (r3), and Micro (t2). Each family has multiple sizes that have varying numbers of vCPUs, GiBs of memory, levels of network performance, and can be input/output optimized.

Each RDS instance can be set up to be “multi-AZ”, leveraging replicas of the database in different availability zones within AWS. This is often used for production databases. If a problem arises in one availability zone, failover to one of the replica databases happens automatically behind the scenes. You don’t have to manage it. Along with multi-AZ deployments, Amazon offers “Aurora”, which has more fault tolerance and self-healing beyond multi-AZ, as well as additional performance features.

It’s important to ensure that you’re matching your workloads to the instance types that best meet their needs, so you have the best and most cost-efficient option for your database. There are different pricing options for the different rds instance sizes and the databases they are being run on. Here’s a breakdown of AWS RDS Instances types:

General Purpose

T3 instances — the latest burstable, general purpose instance type that provides a baseline level of CPU performance, plus the ability to burst CPU usage. Balance of compute, memory, and network.
T2 instances — similar to T3, T2 instances are burstable general-purpose performance instances that provide a baseline level of CPU performance with the ability to burst.
M5 instances — the latest general purpose instances with a balance of compute, memory, and network resources.
M4 instances — balance of compute, memory, and network resources.

Memory Optimized

R5 instances — latest generation of memory-optimized instances.
R4 instances — previous generation of memory-optimized instances.
X1e instances — optimized for high-performance databases, offering one of the lowest prices per GiB of RAM.
X1 instances — optimized for large-scale, enterprise-class and in-memory applications.

RDS Pricing

RDS is essentially a service running on top of EC2 instances, but you don’t have access to the underlying instances. Therefore, Amazon has set the pricing for an RDS instance in a very similar way to an AWS EC2 instance, which will be familiar once you’ve gotten a grasp on the structure that is already in place for compute. There are multiple components to the price of an instance, including: the underlying instance size, storage of data, multi-AZ capability, and sending data out (sending data in is free for the transfer). To add another layer of complexity, each database type (MySQL, Oracle, etc) has different prices for each of the factors. Aurora also charges for I/O on top of the other costs.

When you add all this up, the cost of an RDS instance can go through the roof for a high-volume database. It also can be hard to predict the usage, storage, and transfer needs of your database, especially for new applications. Also, the raw performance might be a lot less than what you might expect running on your own hardware or even on your own instances. What makes the price worth it?

What are the Actual Costs?

AWS offers a number of instances that are fit for different engines/databases. Once you determine which instance you want, and what engine you will be running your instance in, you can find a more specific price for your instance. With AWS RDS you only pay for what you use. You can try AWS RDS for free with the AWS Free Tier for no additional fees.

Pricing of instance types depend on the RDS database engine you are running it on. To give an example of AWS RDS instance pricing, here’s what a memory-optimized R4 large compares to an R4 Extra Large across engines as one example. This is pricing for the US East (N. Virginia) region:

You can see how the cost of an AWS RDS instance doubles, or more, just by going up one size — this is the same across instance types, sizes, and regions.

To further break down what you would be paying, here’s what Amazon will bill you based on:

DB instance hours
Storage (per GB per month)
I/O requests per month
Provisioned IOPS per month
Backup Storage
Data transfer

You can use this AWS Monthly Calculator to help calculate what your costs would be.

RDS vs. Installing a Database on EC2

We often see that the choice comes down to either using RDS for your database backend, or installing your own database on an EC2 instance the “traditional” way. From a purely financial perspective, installing your own database is almost guaranteed to be cheaper if you focus on AWS direct costs alone. However, there’s more to factor into the decision than just the cost of the services.

What often gets lost in the use of a service is the time-to-value savings (which includes your time and potentially opportunity cost/benefit for bringing services online, faster). For example, by using RDS instead of your own database, you avoid the need to install and manage the OS and database software, as well as the ongoing patching of those. You also get automatic backups and recovery through the AWS console or AWS API. You avoid having to configure storage LUNs and worrying about optimizing striping for better I/O. Resizing instances is much simpler with RDS, both going smaller or bigger if necessary. High-availability (either cold or warm) is available at the click of a button. All of this means less management for you and faster deployment times, though at a higher price point. If your company competes in a highly competitive market, these faster deployment times can make all the difference in the world to your bottom line.

Keep in mind that, as of fall 2017, you can start/stop RDS instances, which is particularly useful for dev/test environments. With this functionality, businesses will be able to stop RDS instances so they are not running 24/7. However, while they are not getting charged for database hours, you will still have to pay for provisioned storage, manual snapshots, and automated backup storage.

How to Manage RDS with ParkMyCloud

ParkMyCloud has made “parking” — a.k.a starting and stopping on a schedule — public cloud compute resources as simple as possible. Included is the ability to park RDS instances, helping you save money on non-production databases.

By using our Logical Groups feature, you can create a simple “stack” containing both compute instances and RDS databases to represent a particular application. A logical group can be used to manage all the constituent parts of an application.

The start/stop times can be sequenced within the group and a single schedule can be used on the group for simplified management. If access is needed during scheduled stop times, then you can override the schedules as needed, through the web app or commands through your chat provider like Slack or Microsoft Teams. You can also set start or stop delays within the Logical Group to customize the order, so if databases need to be started first and stopped last, then you can set that level of granularity. This helps with cost optimization because you have the ability to organize and manage your RDS instances in one place, at one time.

Conclusion

AWS RDS pricing can get a bit tricky and really requires you to know the details of your database in order to accurately predict the bill. However, there are a ton of benefits to using the service, and can really help streamline your systems administration by handling the management and deployment of your backend database. For companies that are moving to the cloud, or born in the cloud, RDS might be your choice when compared to running on a separate compute instance or on your own hypervisor, as it allows you to focus on your business and application, not on being a database administrator. For larger, established companies with a large team of DBAs and well-established automation or for IO-intensive applications, an alternative service may be a better option. By knowing the features, benefits, drawbacks, and factors in the cost, you can make the most informed decision for your AWS database needs.

Originally published at www.parkmycloud.com on October 4, 2019.