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