What you need to know about AWS RDS

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 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 Relational Database Service (RDS). This added another layer of complexity to your choices when managing your infrastructure. Let’s explore AWS RDS pricing a little bit, and examine some of the features that comes with it.

RDS Basics

AWS RDS offers the ability to directly run and manage a relational database without managing the infrastructure that the database is running on, or a having to worry about patching of the database software itself. Amazon currently offers RDS in the form of MySQL, Aurora (MySQL on steroids), Oracle, Microsoft SQL Server, PostgreSQL, and MariaDB.

The database sizes are grouped into three 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 a different availability zones within AWS. This is often used for production databases. If a problem arises in one availability zone, failover to one of 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.

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 RDS instances in a very similar way to EC2 instances, 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?

RDS vs. installing a database on EC2

Frequently, the choice comes down to 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 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.

One downside of just about every PaaS offering (and RDS was no exception) is that there typically is no "OFF" switch. This means that in non-production environments you are paying for the service, whether your DevOps folks are using it or not. For RDS that was changed recently by AWS. RDS instances in dev/test environments can now be stopped.

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, RDS might not be the right fit for your business.

By knowing the features, benefits, drawbacks, and factors in the cost, you can make the most informed decision for your database needs.

Chris Parlette, Director of Cloud Solutions, ParkMyCloud.

Published under license from ITProPortal.com, a Future plc Publication. All rights reserved.

Photo Credit: Gil C / Shutterstock.com