Introducing Amazon RDS - The Amazon Relational Database Service

We are always looking for ways to make it faster, simpler, and more fun to develop applications of all types. Every hour that you don't spend fiddling with hardware, tracing cables, installing operating systems or managing databases is an hour that you can spend on the unique and value-added aspects of your application.

Today I'd like to tell you about our newest service, the Amazon Relational Database Service, or Amazon RDS for short. Now in beta, RDS makes it easier for you to set up, operate, and scale a relational database in the cloud. You get direct database access without worrying about infrastructure provisioning, software maintenance, or common database management tasks.

Using the RDS APIs or the command-line tools, you can access the full capabilities of a complete, self-contained MySQL 5.1 database instance in a matter of minutes. You can scale the processing power and storage space as needed with a single API call and you can initiate fully consistent database snapshots at any time.

Much of what you already know about building applications with MySQL will still apply. Your code and your queries will work as expected; you can even import a dump file produced by mysqldump to get started.

Amazon RDS is really easy to use. I'll illustrate the most important steps using the command-line tools, but keep in mind that you can also do everything shown here using the APIs.

The first step is to create a database instance. Here's how to create a database named mydb with room for up to 20 GB of data:

<dev>: rds-create-db-instance --db-instance-identifier mydb --allocated-storage 20 --db-instance-class db.m1.large --engine mysql5.1 --master-username dbroot --master-user-password dbpass

You can specify any one of five server instance classes:

• db.m1.small (1.7 GB of RAM, $0.11 per hour).
• db.m1.large (7.5 GB of RAM, $0.44 per hour)
• db.m1.xlarge (15 GB of RAM, $0.88 per hour).
• db.m2.2xlarge (34 GB of RAM, $1.55 per hour).
• db.m2.4xlarge (68 GB of RAM, $3.10 per hour).

During the beta you can create up to twenty databases per AWS account, and each one can consume up to 1 TB of storage. You can specify an availability zone (which you should do if you plan to access it from an EC2 instance) or you can let RDS choose one for you.

You can check on the status of your new database at any time:

<dev>: rds-describe-db-instances
DBINSTANCE mydb db.m1.large mysql5.1 20 dbroot    creating 1  us-east-1d 1
    SECGROUP default active
    PARAMGRP default.mysql5.1 in-sync

When the status changes from creating to available your database is ready for use and the command output will include the server name and connection string you use to access the database instance from the command line or your application:

<dev>: rds-describe-db-instances
DBINSTANCE mydb 2009-10-15T22:47:48.037Z db.m1.large mysql5.1 20 dbroot available mydb.cwuz5lta310x.us-east-1.rds.amazonaws.com 3306 us-east-1d 1
    SECGROUP default active
    PARAMGRP default.mysql5.1 in-sync

The final step is to edit the database's security group so that it allows inbound connections. You can enable connections from any (or all) of your EC2 security groups:

<dev>: rds-authorize-db-security-group-ingress default --ec2-security-group-name default --ec2-security-group-owner-id 889135802129

You can also enable connections from a particular IP address or address range using CIDR notation:

<dev>: rds-authorize-db-security-group-ingress default --cidr-ip 198.87.83.201/32

And that's all it takes to create a fully functioning DB Instance of MySQL 5.1 in the cloud. There's nothing to install, nothing to configure, and nothing to tune. The DB Instance will use the InnoDB storage engine.

If you need more storage space, you can expand your instance like this:

<dev>: rds-modify-db-instance mydb --apply-immediately -s 50

If you don't use the --apply-immediately parameter, the expansion will be performed during your DB Instance's maintenance window. The maintenance window opens once per week for four hours. During that time we will apply the latest MySQL patches (if necessary) and take care of any pending scaling operations. Your DB Instance will be unavailable only for the minimum amount of time required to make system changes on your behalf. You should set the maintenance window to a time that will result in the least possible inconvenience and down time for your users.

You can set up a two hour backup window and a retention period for automated backups, and you can also create a database snapshot at any time:

<dev>: rds-create-db-snapshot mydb -s jeffbarr-backup-2009-10-15

You can create new Amazon RDS DB Instances from either type of backup.With the automated backup feature, you can restore to any point in time within your backup retention period, up to the last five minutes.

Each DB Instance exports a number of metrics to CloudWatch including CPU Utilization (percent), Free Storage Space (bytes), and Database Connections (count).

At this point in the post I'd usually talk about the uses for the service, but I think that's pretty obvious! I should point out that RDS enables a lot of really enticing development and test scenarios. You can set up a separate database instance for each developer on a project without making a big investment in hardware.

Once you've deployed RDS for production use, you can easily scale up to larger instance sizes, add additional storage space (up to a total of 1 TB per RDS instance), and make backups with ease. You can easily snapshot a production database and then bring it back to the lab to dig in to a problem.

RDS usage is charged by the DB Instance hour. As noted above, there are five instance sizes and corresponding hourly rates. You'll also pay 10 cents per GB per month for your provisioned storage and 10 cents for every million I/O requests. You get backup space to store 100% of your provisioned storage at no additional charge, with additional space priced at 15 cents per GB per month. The usual AWS charges for data transferred in and out of the cloud also apply.

We have a number of enhancements planned for the future. Here are some of the features planned for the coming months:

• Reserved DB Instances so that you can pay a low one-time fee and then receive a substantial discount on your hourly usage charges.
• A High Availability offering so that you can easily and cost-effectively provision synchronously replicated RDS instances in two different availability zones.

We believe that RDS will make a really nice complement to Amazon SimpleDB and that each of the services has a number of unique features and use cases. A number of our early adopters are planning to use both of the services in their AWS applications.

As always, we have plenty of documentation, libraries, and FAQs. I look forward to seeing how you put RDS to use in your own applications.

-- Jeff;

PS - You may also enjoy reading RightScale's take on today's releases.

Comments

[ben]

This is awesome!

One question, though. Up to how many transactions per sec will this service support?

[Dean Asor]

"The DB Instance will use the InnoDB storage engine."

Since InnoDB will be the default storage engine for an instance of MySQL Database, can i change it to MyISAM storage engine (if available)? If not, is there any plans to support MyISAM storage engine in the future?

[iolaire]

Does this mean that there is some sort of DB config tuning as part of the service? I.e will it help to select the appropriate my-huge.cnf, my-large.cnf, my-medium.cnf and my-small.cnf based on usage or something?

[Ted Pennings]

Are there any plans to offer a more shared, pay-per-*use* approach to this? Billing by CPU hours used, not instance hours, would make this service far more appealing and position it in better competition with, say, Google's App Engine.

[Jens Riboe]

When will this service be available from the AWS Management Console and/or the ElasticFox plugin?

[Paul Morel]

Can you add a python library for RDS?

Will the high availability option (coming soon) have an automatic failover capability? It would really seal the deal if there was a way to monitor RDS instance health and automatically failover to another synced instance. Even better would be a MySQL cluster option.

[Prathapan Sethu]

How fast would be the connection to RDS from EC2 server? Would that be over a high-speed network or would it have to go over Internet?

[jules]

Any chance that Amazon will offer a version of RDS on top of Postgres/PostGIS in the near future, instead of MySQL ? The MySQL spatial support is not optimal...

[Daniel]

What does 'charging per DB instance hour' exactly mean? Even if the database is not being used you will have to pay 0.11 cents per hour?
So that will make 0.11 * 24 * 265 = $963.60 per year??

[Kelvin Nicholson]

This news really brings down the barrier to entry for using EC2 as a web platform. The biggest question I have is: how much will the reserved instances be, and when can I buy one?

[Derek]

As a newbie... to AWS there seems the be a step missing or general concept that I'm missing with AWS.

I'm reading documentation that I can use all my standard tools but at the same time the PDF document says I have to use a AWS JAVA tool (which by the way doesn't tell us where to download).

So, if I can use all my existing tools, why can't I setup a shell and use my php tools to create a database instance?

Also, can someone answer Daniel's question about being charged for a database if its not used? (posted Oct 28th, 2009)

Help! :-)

[Randal]

I am interested in connecting to the database with Microsoft Access using ODBC for MySQL. Will that work?

More specifically, the issue I have with most MySQL hosts is the value of a parameter called wait_timeout. This is the time of inactivity allowed before the ODBC database connection is closed. This is set to less than a minute for most hosts; it needs to be more like 30 minutes. Will I be able to change such variables?

If I use this technique, will I be billed for the entire time the ODBC connection is maintained. Even, as suggested in a comment above, I get charged for an instance 24 x 7, that's not very much. However, if I have a multi-user application, I could get hit for an instance for every user.