Top 10 Things to Know About Amazon RDS

There has been plenty of hype about Amazon RDS for hosting databases on the internet. It can be confusing at first—and even after you’ve been using it for a while. If this is all new and strange to you, and you’re thinking about moving your database to Amazon RDS, there are many things to consider. Here are ten things you ought to know before you take the leap.

Amazon RDS uses a Patched MySQL

Many people worry that Amazon may not have the expertise for upgrading and maintaining patched versions of MySQL. Even if that was true, Amazon has enough resources and money to justify buying what they need from other vendors with the required expertise. Their patch for version 5.1.38 of MySQL enables it to scale dynamically in the Cloud, besides adding other features.

Connecting the Dots

Amazon RDS DB instances are basically instances of MySQL running on an EC2 platform. Persistent storage, which is used for back-ups and other such things, is allocated in EBS volumes. However, you can neither access the underlying EC2 instance, nor can you use S3 to access your stored database snapshots. Taking it a step further, since you don’t get access to the native EC2 instance, you can’t install additional software on the MySQL host. This means that you can’t use an agent-based monitoring tool. So consider this before investing in one.

No Direct Access to the MySQL Configuration File

If you want to modify the my.cnf or my.ini file, you can’t. Amazon doesn’t give you direct access to the MySQL configuration file. Instead, it provides an API that you can use to make changes (see DB Parameter Groups).

Maintenance Window

Amazon requires you to schedule a regular, weekly 4-hour maintenance window within which the management system will roll out patches for MySQL, back up your data, and perform other such maintenance. If you don’t set the day and starting time that you prefer, they’ll set it for you. Amazon may never need the entire four hours. It may be only minutes where backups are concerned. Still, it could sometimes result in an unacceptable amount of downtime for your database.

Snapshot-Based Back-ups

This feature is by far the most convenient. Your entire database can be backed up to snapshots-on-demand. With the Automatic Backup feature, Amazon promises point-in-time recovery up to the last five minutes. Be aware, though, that snapshots add to your storage and can result in extra charges if you keep too many of them and exceed what’s been allocated to your account.

Replication and Binary Log Access is Disabled

Replication in MySQL may be a little unstable, and human intervention may be required occasionally to recover crashed slaves. So disabling replication may be fine for some to ensure high availability of your database server. Nevertheless, replication can be useful for scaling out read operations, as well as making back-ups without any downtime. It would be nice to have replication.

Given that Amazon promises point-in-time recovery up to the last five minutes, the binary log must be enabled. Regardless, you’re not given access to the binary logs, and you can’t use tools such as the mysqlbinlog for other purposes. That can be frustrating.

User Privileges

Amazon does not grant SUPER and SHUTDOWN privileges even to the master user of the database instance. The primary reason for not permitting SUPER is because they’re blocking direct access to the MySQL configuration. Not permitting SHUTDOWN relates to security: being able to take the server off-line can involve acute security threats.

Although you’re not given SUPER privilege, you can still use the SET statement to change session variables. For most, this is all that is needed. Additionally, the WITH GRANT OPTION privilege is given to the administrator so you that you can add users and grant them privileges.

Network Latency

An inherent drawback of all cloud-based systems is network latency. When you’re located a continent or so away from Amazon’s Cloud data center, you can expect delayed transmission of data. Add to this intra-cloud network latency and network-attached storage latency, and you have a significant slowing of services. This depends largely of course on the quality, stability, and speed of your Internet connection. There seems to be no reason, though, to question the quality of Amazon’s Internet connection.

Monitoring Database Instances

Amazon won’t install a monitoring agent on their server for you. But Monyog provides unique monitoring capabilities that allow you to monitor your MySQL database on Amazon with ease. For more OS specific counters, however, you will have to rely on Amazon’s CloudWatch. Amazon RDS provides the following metrics to CloudWatch to compensate for not providing SSH access to the underlying EC2 instance:

  • CPUUtilization — The percentage of CPU utilized.
  • FreeStorageSpace — The amount of available storage space.
  • DatabaseConnections — The number of database connections in use.
  • ReadIOPS and WriteIOPS — The average number of disk I/O operations per second.
  • ReadLatency and WriteLatency — The average amount of time used per disk for I/O operation.
  • ReadThroughput and WriteThroughput — The average number of bytes per second read from or written to disk.

CloudWatch, though, costs extra. That’s yet another reason why you should use instead a remote monitoring tool like Monyog.


The most important factor of which you should be aware is how the charges are calculated. Be very care regarding this. If you decide to set up a database instance with which to experiment and to learn about Amazon RDS, but never use it, you will still be billed as long as it’s running. Even if there is absolutely no activity on the server, if you let it run for a week, this could result in a bill of one or two hundred dollars. So be careful even when you’re just trying features. Be sure to remove anything you don’t need. And make sure you understand how your bill will be calculated for the things you need before you go too far.


Add yours
    • 2
      Sayan Chaliha

      Hey Mark,

      For all I know you may be correct, and perhaps I came off too strongly with that comment.

      To the best of our knowledge the patch(es) done by Amazon is not open-source. We will all have to judge from functionalities provided as they are proven (or the opposite). That is not much different from the numerous MySQL-based database solutions shipping with a high-profiled closed-source storage engines. MySQL’s dual-licensing model implies that ‘patches’ (understood as ‘source’) may not be available for commercial offers.

  1. 3
    Lachlan Mulcahy

    One of the biggest consequences of not having the SUPER privilege is not being able to access SHOW ENGINE INNODB STATUS at all. This is absolutely necessary for any remotely serious use of the InnoDB storage engine. Without it, troubleshooting and monitoring performance of InnoDB is a pain.

    I guess I should suggest that the privilege requirement should be it’s own, and not tied to SUPER.

  2. 7
    Mark Callaghan

    Regardless, RDS should be useful for some users and MONyog makes it better. It is possible to get SUPER on RDS, so they have a few more patches to apply to prevent that.

  3. 17


    I need to know about the metrics available for RDS. Can we add additional metrics to the existing ones. How many metrics are available for RDS totally and Whats the billing details for those?

    My scenario is, I am able to see 14 metrics for any DB in ‘Show monitoring tab’. But when I chose to retrieve previous data for those DB using relative or absolute, I am not getting all of them but only subset of that 14.

    Do I have to pay for that too?


+ Leave a Comment