My AWS Musings

Recently Amazon launched RDS – Relational Database Service. Before Amazon offered this service, we had a MySQL configured on an ec2 instance. We needed one more database in cloud. Which way did we go? In this article, I have tried to compare both the options.

RDS Pros:
1) No need to maintain MySQL in the cloud. Amazon will maintain it. Amazon will apply all the patches and upgrade the server software.

2) It’s very easy to scale up. All you have to do is execute rds-modify-db-instance command. You can change your db class to the bigger/better machine.

3) Snapshot based backups are very easy to manage.

4) No need to manage an ec2 volume, backup and an ec2 instance separately to run your database in the cloud. RDS combines all the three in one package.

RDS Cons:
1) The biggest problem about RDS is the 4 hour per week maintenance window. I don’t believe that this maintenance takes place every week. They only take down your database when they are applying patches or upgrading the database server. They will take down your database in your specified time only. This time can be changed any time by simply executing an api call. I also believe that in most cases the downtime will be much less than 4 hours. Nevertheless the threat of downtime exists every week!

2) Does not expose my.cnf file of the database. It instead gives you an API to modify the parameters

3) If you are an advanced MySQL user and want to use tweaked MySQL (such as by Percona http://www.percona.com/), RDS is clearly not a solution.

4) As of now, there is no replication support. This means you cannot have any read only slaves. I have read somewhere that they are working on it.

Clearly RDS is not a silver bullet. In fact in many cases where your application cannot run without a database, you may not be able to afford the weekly downtime. I talked to some friends and the 4 hour weekly downtime was their the biggest problem with RDS. I wish that Amazon would declare the downtime whenever the need arises (such as when new MySQL patches are ready) and less frequently (such as once a month).

We did not have a full time system administrator in our team. We were bunch of software engineers trying to manage our ec2 instances by ourselves. Furthermore our application wasn’t dependant on database completely. Most of the data was cached. Thus we could afford an occasional downtime. That is why we chose RDS.