Top 10 Things to Know About Amazon RDS

So you’ve finally caught on with the hype, and you’re seriously considering using Amazon RDS for your database needs. Here are ten things you ought to know before you take the leap.

10. Amazon RDS uses a patched version of MySQL 5.1.38

While several discussions within MySQL forums allude to a growing concern that Amazon may not have the required expertise for upgrading and maintaining patched versions of MySQL, the fact still remains that Amazon has enough resources to just buy them from other vendors who do. The patch enables MySQL to scale dynamically in the cloud, besides adding other features.

9. EC2, EBS, and RDS: Connecting the dots

Amazon RDS DB instances are basically instances of MySQL running on an EC2 platform. Persistent storage (for back-ups, etc.) is allocated in EBS volumes. However, neither can you access the underlying EC2 instance nor can you use S3 to access your stored database snapshots. Taking it a step further, since you do not get access to the native EC2 instance, you cannot install additional software on the MySQL host. This means that you cannot use an agent-based monitoring tool, so think twice before investing in one!

8. No direct access to your DB configuration file

Want to tune your my.cnf/my.ini file? Amazon does not give you direct access to the MySQL configuration file, but instead exposes an API which you could use to achieve the same effect. Read more about DB Parameter Groups here.

7. The maintenance window

You have to define a 4-hour weekly maintenance window (or Amazon will define it for you) within which the management system will roll out patches for MySQL, back up your data, and perform other such maintenance. This could result in a certain amount of downtime of your server (and, probably, that would never be 4 hours, but rather, with the snapshot-based backup system, it would be a matter of minutes where backups are concerned).

6. Snapshot-based back-ups

This feature, dare I say, is by far the most convenient. Your entire database can be backed up in snapshots on demand (extra charges for storage apply), and with the Automatic Backup facility, Amazon promises point-in-time recovery up to the last 5 minutes.

5. Replication is disabled/access to the binary log is disabled

Replication in MySQL may be a little unstable, and human intervention may be required in recovering crashed slaves. So disabling replication seems like necessary evil to ensure high availability of your DB server. But then again, you cannot use replication for scaling out read operations. Given that Amazon promises point-in-time recovery up to the last 5 minutes, you’d expect the MySQL binlog to be enabled. Even if this is true, you have no access to the binlog, and you cannot use tools such as the mysqlbinlog to recover writes to the database between snapshots.

4. User privileges

Sadly, Amazon does not grant SHUTDOWN, and SUPER privileges even to the master user of the DB instance. Not granting SUPER privileges is logically a consequence of not providing direct access to the database configuration. The absence of the SHUTDOWN privilege can be a security risk in rare cases; allowing authenticated users to take the server off-line is the last line of defense against acute security threats. However, without SUPER privilege it is still possible to SET SESSION variables. That is probably an acceptable workaround for the lack of SUPER in most scenarios. Also, GRANT privilege is available so you may add more users with a subset of the master user’s privileges from any MySQL client that is able to connect to the database.

3. Network latency

Now, this is an inherent drawback of all cloud-based systems: What happens when you are located halfway across the globe from Amazon’s cloud data center? The answer: Delayed transmission of data. Add to this the intra-cloud network latency and network-attached storage latency, and you have a significant loss of productive time. This, of course, depends largely on the quality, stability, and speed of your Internet connection: we don’t think there is any reason to question the quality of Amazon’s Internet connection.

2. Monitoring your DB instance

You cannot ask Amazon to install a monitoring agent on the server for you (obviously). But with MONyog‘s unique monitoring capabilities, you can monitor your MySQL database with ease. For more OS specific counters, however, you will have to rely on Amazon’s CloudWatch. RDS exposes the following metrics to CloudWatch to compensate for not providing SSH access to the underlying EC2 instance:

  • CPUUtilization—The percentage of CPU utilization

  • 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 taken per disk I/O operation

  • ReadThroughput and WriteThroughput—The average number of bytes read from or written to disk per second

This is, of course, available only at an extra cost! Consider running a remote monitoring tool, like MONyog, instead.

1. The cost factor

Most importantly, be VERY CAREFUL with the billing. You get billed just to keep the DB instance running, even when there is absolutely no activity on the server. For example, we created an extra large instance just of the purpose of the earlier blog post. We only connected for a few minutes to test it but the server was idle for 99% of the time. At the end of 145 hours (roughly 6 days) the bill was $127. So be careful before you take it out for a spin.


Add yours
  1. 1
    Mark Callaghan

    How does the patch enable RDS to scale MySQL dynamically in the cloud? What is in the patch? Either the patch is really good or that is too heavy on the marketing.

    • 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.

  2. 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.

    • 4
      Sayan Chaliha

      Hi Lachlan,

      Take a look at this bug report. For some time now, SHOW ENGINE INNODB STATUS is bound to the PROCESS privilege, and not the SUPER privilege, so there shouldn’t be any issue in this regard.

  3. 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.

  4. 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