Choosing the Right RDS Instance for the Job

There are a handful of AWS RDS options to choose from when you’re looking to spin up a new database instance. Use these tips to choose the right instance to get the most bang for your buck, and learn how to save even more on RDS with Reserved Instances.

Different database instances for different workloads

RDS instances are very similar to EC2 in that each are broken down into different families that specialize in different kinds of workloads. As of 2017, AWS offers RDS instances in three families:

• T2: for workloads that require burstable performance capacity (see our EC2 T2 examination for details on this burstability compared to general M4 performance)
• M4: for general-purpose database workloads
• R3: for memory-intensive workloads, like in-memory functions, big data analysis, etc.

RDS users can spin up instances and choose from the following database types: AWS Aurora, MySQL, PostGRES, Oracle, SQL Server, and MariaDB.

Finding the right fit

While it’s totally fine to commute to work in a huge commercial grade truck, you’re likely going to save more money choosing a more economical vehicle. Conversely, trying to do commercial grade construction in a hybrid commuter car might prove to be difficult. Choosing the right equipment for the job is essential, as well as cost-effective.

That all said, the database infrastructure for running a blog, news websites or online store full of pricing, tags, and inventory data is going to be different than the setup behind big data analysis or predictive modeling using numerous tables, inputs and variables. Blogs, e-commerce sites, and simple apps can probably get away with using a T2 or M4 RDS instance that fits the usage spec and budget for a particular project. Teams will likely want to start on a T2 database instance if they want an affordable way to kick off a project and build in some buffering for spikes in usage.

Systems running in-memory databases (for immersive real-time app experiences serving a multitude of users, running predictive analyses, data warehouse reporting and analytics or with large-scale data visualization) make the most of the RDS R3 family’s extra memory, as they’ll put working sets of data into system memory, making it faster to interact with the processors between processor and RAM than with processor and general storage. If this is required, then the R3 instances will deliver the best cost efficiency per GB of RAM.

Using AWS Aurora

While any RDS instance can spin up a variety of popular database types, Aurora (AWS’s own MySQL- and PostgreSQL-compatible relational database service) is only accessible on certain RDS instances. AWS’s own database service can be used with any R3 instance and the db.t2.medium. So if using Aurora is a must, you’ll have to rule out the general purpose M4s and T2s other than the db.t2.medium.

If PIOPS is important, look to M4 and most of the R3 instances

RDS users can provision an increased amount of Provisioned IOPS (PIOPS) to accommodate I/O-heavy workloads. However, there’s no PIOPS provisioning available for the T2 RDS instances and a few R3s (the db.r3.large and db.r3.8xlarge).

What do you pay for when using RDS?

For a deeper look at the specific costs incurred with RDS usage feel free to check out this article. Otherwise, here’s a short list of what RDS users will be charged for (which all may vary depending on which family is chosen and which database types are used.

• Database Instance hours
• Storage
• Backup storage
• Data Transfer
• I/O Requests (AWS Aurora has its own rates)
• Provisioned IOPS (AWS Aurora has its own rates)

Depending on the workload, you’ll want to look at what you’re getting and paying for per hour for each of these families.

Why not just run your database on an EC2 instance?

With RDS, AWS lowers the administrative burden of running databases. Comparing the costs of EC2 instances to their database counterparts might show that EC2 instances have cheaper rates. But with those competitive rates, database administrators are on the hook for many more tasks.

For example, the EC2 m4.large running Linux On-Demand costs $0.108 per hour, while the db.m4.large running MySQL costs $0.175 per hour. There’s a 38.3% premium paid by choosing RDS over manually running a database on EC2.

According to AWS documentation, RDS assists with and lowers administrative burdens by providing access to key database metrics, automating patching and updates, simplifying backups and snapshots for all databases and making scalability as easy as possible.

Administrators should consider all these factors and see if the benefits outweigh the extra hourly costs before doing more of the work by hand on EC2.

Specs & pricing breakdown

Here’s a brief comparison of RDS On-Demand MySQL costs on db.t2.medium, db.m4.large and db.r3.large to illustrate cost efficiencies. For more specs and pricing on the other database types across instances, check out the official AWS documentation.

Running MySQL in U.S. West-2 (Oregon)

^{*The computing power of the T2 instances can vary as they are capable of burstable performance.
**If Provisioned IOPS is a must, the db.r3.xlarge is the next size with it available.}

The db.r3.large instance will be a bit more expensive from a CPU cost standpoint, but will provide the best memory cost efficiency. Meanwhile, the db.t2.large is cheaper to operate than the db.m4.large, but its performance will be limited if burstable compute credits are used up. The only option that will allow Provisioned IOPS of this bunch is the db.m4.large.

The bottom line

Choose a T2 RDS instance if: you’re just starting out and need some buffering room for spikes in performance to get a sense of what baseline database performance will be like. But keep in mind that AWS Aurora is only available on the db.t2.medium and that no T2 database instances can have Provisioned IOPS.

Choose the M4 if: your database workload doesn’t run too many in-memory functions, and you have a general sense of your performance. You’ll have more options as far as provisioning increased IOPS with this family as well.

Choose the R3 if: there are memory-intensive workloads to run. It’ll be interesting to see if AWS creates a new R4 fleet of RDS instances now that the R4s are available on EC2. If a project scales beyond the R3 database instance family AWS now has a couple of options on EC2 with the memory-heavy X1 family, but keep in mind that using EC2 means giving up the database management-centric features and benefits of RDS.

Make reservations to save once you find the right RDS fit

According to our previous RDS cost analysis, instance charges are the biggest driver of RDS costs. So once you identify the right kind of RDS instance that your workload needs, use Reserved Instances (RIs) to lock in a lower hourly rate for either a one- or three-year term.

Use a cloud cost management tool like IBM Cloudability to quickly assess how many usage hours of RDS are covered by RI rates or On-Demand. Drill down even deeper to identify specific instances at the resource level that are driving costs or are running consistently enough to make use of additional RI purchases.

When you buy Reserved Instances for RDS, keep in mind that you’re committing to every single hour of the one or three-year term. So keeping an eye on your RDS costs and usage with a cloud cost management tool like Cloudability helps ensure that you’re making the right RDS RI decisions to keep costs in check.

To see this kind of RI insight creation and planning at work, get in touch with one of our RDS experts today. Or try Cloudability for free and dig up new insights on how to spend as efficiently as possible on RDS and your other AWS resources.