Running MySQL on Amazon EC2 with EBS (Elastic Block Store)

Articles & Tutorials>Running MySQL on Amazon EC2 with EBS (Elastic Block Store)
This tutorial describes one approach to using Amazon EC2's Elastic Block Store (EBS) as a persistent storage mechanism for a production MySQL database server, including snapshot backup and restore.


Submitted By: Eric Hammond
AWS Products Used: Amazon EC2
Created On: August 20, 2008 8:49 PM GMT
Last Updated: March 23, 2010 1:13 AM GMT

By Eric Hammond, Internet Startup Technologist (@esh on Twitter)

This guide covers:

  • Benefits of using EBS for MySQL
  • Setting up an EBS volume on an EC2 instance for use with MySQL
  • Configuring MySQL to use the EBS volume for data files and binary logs
  • Snapshotting the database
  • Restoring the snapshotted database on a second EC2 instance
This explicitly does not cover:
  • How to set up an Amazon EC2 account
  • How to use MySQL
  • Advanced multi-host redundancy, master/slave, failover, scaling, clusters

The focus here is on simplicity and to help the reader get a feel for the basics of what EBS offers to database servers.

Benefits of using EBS for MySQL

There are numerous reasons why you will want to run your MySQL database on EBS. Some of them are obvious and some are wonderful. They include:

Persistent storage in the event of instance failure - If an EBS volume is used as the storage for a MySQL database, then the data is protected from instance termination or failure. You can simply attach/mount the volume on another instance and MySQL will run its normal recovery procedures to bring the database up to date with the binary logs.

Safety & Replication - According to Amazon, "EBS volume data is replicated across multiple servers". This makes your data safer than the default instance storage.

Improved performance - Early reports from studies on random access disk IO performance indicate that EBS IO rates can be faster than ephemeral storage and even local disk IO. This has obvious benefits for databases which are often IO bound.

Large data storage capacity - EBS volumes can be up to 1TB in size. You can go larger with LVM or RAID across EBS volumes, or by placing different databases or table files on different EBS volumes.

Instance type portability - If you find that your current small EC2 instance is not able to handle your growing demand, you can switch the EBS volume holding your MySQL database to a running extra large instance in a matter of seconds without having to copy the database across the network. Downgrade instance types later to save money.

Fast and easy backups - EBS snapshots alone can be a sufficiently attractive reason to move a database server to Amazon EC2. Being able to take live, consistent, binary snapshots of the database in just a few seconds is a thing of beauty. Add in the ability to create a new EBS volume from a snapshot so another EC2 instance can run against an exact copy of that database... and you've opened up new worlds of possibilities.

Technology choices

This guide shows examples using the Amazon EC2 API command line tools which are assumed to be installed on your local system. Many of the same results can be accomplished with the AWS Console, the Firefox EC2 plugin or with some of the 3rd party web management interfaces to Amazon EC2 such as RightScale.

This guide shows examples using Ubuntu 9.10 (Karmic). The same concepts would apply with slight modifications on Debian, Fedora, Red Hat, CentOS, and other Linux distributions. The latest versions of the Ubuntu AMIs can be found on the following page maintained by the author:

This guide shows examples using the XFS file system. Besides being a stable, modern, high performance, journaling file system, XFS supports file system freeze/thaw which is extremely useful for ensuring a consistent state during EBS snapshots. XFS also supports file system growth which can be used if your database and other data are reaching the limits of your current volume size.

Setting up an EBS volume on an EC2 instance for use with MySQL

To get started, we'll run an EC2 instance, create an EBS volume, and attach the volume to the instance. You can run the instance in any availability zone, just make sure to create the volume in the same zone so it can be attached to the instance.

As mentioned in the previous section, we assume that you have installed the EC2 API command line tools on your local system.

Run an instance of Ubuntu 9.10 Karmic base install specifying your ssh keypair name. Make a note of the instance id (say, i-IIII1111). Check to see if the instance is running (might take a minute) and make a note of the external hostname (say, HOST1111).

ec2-run-instances -z us-east-1a --key YOURKEYPAIR ami-1515f67c

ec2-describe-instances i-IIII1111

Create a new 10 GB EBS volume and make a note of the volume id (say, vol-VVVV1111). Check to see if the new volume is available (might take a few seconds).

ec2-create-volume -z us-east-1a -s 10

ec2-describe-volumes vol-VVVV1111

Once it's available, attach the EBS volume to the instance as /dev/sdh

ec2-attach-volume -d /dev/sdh -i i-IIII1111 vol-VVVV1111

Now we can set things up on the instance itself, so connect to it and install the necessary software on the instance. Enter and record a secure MySQL root password when prompted.

ssh -i YOURSSHKEYFILE ubuntu@HOST1111

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install -y xfsprogs mysql-server

Create an XFS file system on the EBS volume and mount it as /vol

grep -q xfs /proc/filesystems || sudo modprobe xfs
sudo mkfs.xfs /dev/sdh

echo "/dev/sdh /vol xfs noatime 0 0" | sudo tee -a /etc/fstab
sudo mkdir -m 000 /vol
sudo mount /vol

You now have a 10 GB (or whatever size you specified) EBS volume mounted under /vol with an XFS file system, and it will be automatically mounted if the instance reboots.

Anything you store under /vol (including MySQL files) will persist beyond the life of the current instance, and you can take snapshots of this volume for backup or replication.

Configuring MySQL to use the EBS volume

Now that we have an EBS volume mounted on the instance with a good file system, let's put the MySQL database on that volume and tell MySQL where it is.

Stop the MySQL server.

sudo /etc/init.d/mysql stop

Move the existing database files to the EBS volume. Point MySQL to the correct database files on the EBS volume using mount bind.

sudo mkdir /vol/etc /vol/lib /vol/log
sudo mv /etc/mysql     /vol/etc/
sudo mv /var/lib/mysql /vol/lib/
sudo mv /var/log/mysql /vol/log/

sudo mkdir /etc/mysql
sudo mkdir /var/lib/mysql
sudo mkdir /var/log/mysql

echo "/vol/etc/mysql /etc/mysql     none bind" | sudo tee -a /etc/fstab
sudo mount /etc/mysql

echo "/vol/lib/mysql /var/lib/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /var/lib/mysql

echo "/vol/log/mysql /var/log/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /var/log/mysql

Restart the MySQL server.

sudo /etc/init.d/mysql start

You are now running MySQL with all of the data and binary log files persistently stored on a high performance, redundant EBS volume!

To prove to yourself that a later snapshot saved your database changes, you might want to load some data or simply create a placeholder database with a SQL statement like:

mysql -u root -p -e 'CREATE DATABASE tutorial_sample'

Your data is pretty safe here, but let's make it even safer with snapshot backups.

Snapshotting the database

An EBS snapshot is a point in time copy of the complete EBS volume. It will save the current state of all files that were placed on that volume at a block level including the MySQL database data and binary logs. Snapshots are saved to Amazon S3 which is even more secure than EBS in that it is archived in multiple geographic locations.

Since file systems and databases often have things in memory on their way to disk and active processes can be changing the state of the disk so that it isn't always entirely consistent with itself, we take pains to flush, lock, and freeze the database and the file system for the few moments that it takes to create the EBS snapshot. This may cause a slight pause in activity on that system, but if the process is automated, it tends to be sufficiently short that most folks won't notice.

To be able to type all the required commands in a single connection to the EC2 instance, this example uses the mysql "SYSTEM" statement to run command line programs, but these commands don't really have to be run from inside MySQL to be effective.

Start a MySQL session on the instance, using the password you set above.

mysql -u root -p

In the mysql session, flush the tables to disk and acquire a lock. Flush the file system to disk and freeze it. Do not exit the MySQL session or you will lose the lock and snapshot potentially inconsistent database files!

SYSTEM sudo xfs_freeze -f /vol

Note: The output from SHOW MASTER STATUS can be handy if you later want to start a slave database from the snapshot.

On your local system (which has the EC2 API command line tools installed) create a snapshot of the EBS volume. Make a note of the snapshot id (say, snap-SSSS1111).

ec2-create-snapshot vol-VVVV1111

Back in the same MySQL session on the instance, unfreeze the file system, release the database lock, and you're done!

SYSTEM sudo xfs_freeze -u /vol

Though the ec2-create-snapshot command returns quickly, the actual snapshot may take a while to complete writing to S3. Have no fear, it will be consistent as of the time the snapshot was initiated above and no further database or disk writes on the instance will affect it.

You can monitor the progress of the snapshot with this command:

ec2-describe-snapshots snap-SSSS1111

Note: If you have a busy database with some long running statements, then acquiring a database lock may be difficult without interfering with operations. However, if all of your tables use the InnoDB engine, then you may skip the LOCK/UNLOCK statements above. MySQL will restore the database to a consistent state when it is run against the binary backup.

Automated snapshot program

The above sequence of MySQL statements and shell commands can be a bit of a hassle when performed manually, not to mention that database activity will be blocked while you are typing, so...

The ec2-consistent-snapshot program automates the appropriate flushing and locking of MySQL and XFS file systems while the EBS snapshot is initiated. To install this on Ubuntu, use the following steps:

codename=$(lsb_release -cs)
echo "deb $codename main"|
  sudo tee /etc/apt/sources.list.d/alestic-ppa.list    
sudo apt-key adv --keyserver --recv-keys BE09C571
sudo apt-get update
sudo apt-get install -y ec2-consistent-snapshot
sudo PERL_MM_USE_DEFAULT=1 cpan Net::Amazon::EC2

The documentation can be accessed using:

man ec2-consistent-snapshot

This program can be run from a scheduled cron job on the EC2 instance to automate backup snapshots while you sleep.

Since each snapshot only takes up space based on which blocks have changed since the last snapshot and since there may be additional compression applied, the incremental cost of frequent snapshots can sometimes be small.

Restoring the snapshotted database

So you want to check out the snapshot of your MySQL database to see if it really has the right data. Or, you'd like to test some code on an instance which has nearly current production data without risk to the live production database. Or, you want to start a MySQL replication slave. Or, you need to recover from an unfortunate DELETE statement without a WHERE clause...

We'll start another EC2 instance to run the second database server. It is not necessary to terminate the original instance; both can be running in parallel. The second instance and volume must be together in the same availability zone, though it does not have to be where the first instance/volume reside.

Run a second instance, making a note of the instance id (say, i-IIII2222). Check to see if the instance is running (might take a minute) and make a note of the external hostname (say, HOST2222).

ec2-run-instances -z us-east-1b --key YOURKEYPAIR ami-1515f67c

ec2-describe-instances i-IIII2222

Create a second EBS volume based on the snapshot of the original volume and make a note of the volume id (say, vol-VVVV2222). Check to see if the second volume is available (might take a while).

ec2-create-volume -z us-east-1b --snapshot snap-SSSS1111

ec2-describe-volumes vol-VVVV2222

Once it's available, attach the second EBS volume to the second instance as /dev/sdh

ec2-attach-volume -d /dev/sdh -i i-IIII2222 vol-VVVV2222

Note: If the original instance had crashed or been terminated, we could skip the creation of a second volume from a snapshot and simply attach the original volume to the second instance. The remainder of these instructions would apply just the same for getting up and running with that original volume, though you might want to run xfs_check just before mounting to make sure the file system is in a consistent state after the crash.

Now, hop on to the second instance, install the required software, and mount the attached EBS volume. (The MySQL password does not matter here because we will be using a pre-existing database.) We also make sure the files are owned by mysql, just in case UIDs are different on the new instance.

ssh -i YOURSSHKEYFILE ubuntu@HOST2222

sudo apt-get update && sudo apt-get upgrade -y
export DEBIAN_FRONTEND=noninteractive
sudo -E apt-get install -y xfsprogs mysql-server

echo "/dev/sdh /vol xfs noatime 0 0" | sudo tee -a /etc/fstab
sudo mkdir -m 000 /vol
sudo mount /vol

sudo find /vol/{lib,log}/mysql/ ! -user  root -print0 | 
  sudo xargs -0 -r chown mysql
sudo find /vol/{lib,log}/mysql/ ! -group root -a ! -group adm -print0 |
  sudo xargs -0 -r chgrp mysql

Point MySQL to the correct database files on the EBS volume.

sudo /etc/init.d/mysql stop

echo "/vol/etc/mysql /etc/mysql     none bind" | sudo tee -a /etc/fstab
sudo mount /etc/mysql

echo "/vol/lib/mysql /var/lib/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /var/lib/mysql

echo "/vol/log/mysql /var/log/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /var/log/mysql

sudo /etc/init.d/mysql start

You now have a second machine running against an exact copy of the first database at the time of the snapshot. Imagine the possibilities and smile!

You can verify this by looking for the "tutorial_sample" database you created earlier.

mysql -u root -p -e 'SHOW DATABASES'

Note: Each of these instances has mounted a different volume and is using a different set of database files. Though they would have started out sharing similar values in the database, any changes made in one will not be reflected in the other.


If you followed the above steps, you will have created resources which will continue to be charged against your EC2 account until you release them. Here are the steps to shut down and delete everything created in this tutorial. The first commands run on the instances:

Unmount the EBS volume file systems on each of the EC2 instances.

sudo /etc/init.d/mysql stop
sudo umount /etc/mysql /var/lib/mysql /var/log/mysql /vol

The rest of the commands should be run on your local system (which has the EC2 API command line tools installed):

Detach EBS volumes from EC2 instances, delete the volumes, delete the snapshots, and shutdown the instances.

ec2-detach-volume vol-VVVV1111
ec2-detach-volume vol-VVVV2222

ec2-delete-volume vol-VVVV1111
ec2-delete-volume vol-VVVV2222

ec2-delete-snapshot snap-SSSS1111

ec2-terminate-instances i-IIII1111
ec2-terminate-instances i-IIII2222

Verify that it's all gone.



Please send feedback, corrections, and recommended enhancements to the author:
Eric Hammond <>

Questions may be posted to the Amazon EC2 Forum so others can pitch in with and benefit from answers.

I am especially interested in notes about what specific steps you changed to get this guide to work on other Linux distributions. These may be included in an update to this tutorial.

Thanks for ideas, code, and suggestions: Mark Callaghan, petterim, Rodney Quillo, smarttux, B. True, nrforum, mattjive



The following information has come out since the original publication of this tutorial:

  • The ext3 and other file systems can also be used to create consistent snapshots with EBS if they are layered on top of LVM or dmsetup. The "dmsetup suspend" and "dmsetup resume" commands take care of the file system freezing. [more info about setting up], [more info about suspending/resuming]

    • Upgrade sample commands to work with Ubuntu 9.10 Karmic AMI.


    • umount even the bind mount points, thanks to Ben Standefer


    • Updated script pointer to ec2-consistent-snapshot
    • Converted to Jaunty


    • Create mount point with mode "000" to help protect against accidentally using it when the EBS volume file system is not mounted.
    • Mention the AWS console
    • Update Ubuntu AMI id


    • Switch to using mount bind so that these instructions will work with the default Apparmor configuration.
    • Add "sudo" so that these instructions will work with the Ubuntu images for EC2 published by Canonical (which require you to log in as a normal user).


    • Initial document publication.


    thank you
    The setup of the XFS filesystem and moving of MySQL files to the newly mounted /vol worked flawlessly. This guide really makes things simple and fast.
    Brett D. Moser on June 4, 2010 6:01 PM GMT
    Very useful writeup
    Thanks for the great write up. Not only MySQl. I used the instructions given, to install my Apache also similarly (with conf, modules and logs on the EBS)
    shiningleaf on May 14, 2010 1:56 PM GMT
    Can't locate Net/Amazon/
    I've been trying to get the automated snapshots to work with no much luck, every time I run ec2-consistent-snapshot i get following message: Can't locate Net/Amazon/ in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/ec2-consistent-snapshot line 12. BEGIN failed--compilation aborted at /usr/bin/ec2-consistent-snapshot line 12. Googling for the keywords in the message does not yield any results, I think it's a problem with the latest stack of software packages (I've been through this procedure few month ago on another instance, and had no any problems at all). Has anyone tried to configure the automated snapshot recently? Has it been tested to work? Perhaps someone knows what the problem is and can suggest. Thanks
    Dmitry Amelchenko on April 21, 2010 12:30 AM GMT
    Thats great - but it needs a little extra scripting
    I used this article as a starting point, and the ec2-consistent-snapshot program is great, but whats missing is an automated way of removing old snapshots so you don't go over AWS's 500 snapshot limit and end up keeping way more than you need - if you did hourly backups within a few weeks you'd hit 500 snapshots and it becomes unmanagable without automated tools to clean them up. In the interim until AWS or ec2-consistent-snapshot implement this much needed functionality I've written some easy to use scripts that use this program and a PHP script to automate the entire process: I hope someone finds this useful!
    sambastream on March 12, 2010 5:49 PM GMT
    very concise yet thorough
    Thank you Eric for everything you do for the ec2 community. Just an FYI for others using this now: You may not have to run this command: sudo modprobe xfs I'm using Ubuntu 9.10, so not sure if there was a change from the time this was written to now. Thanks
    siiva on November 17, 2009 5:05 PM GMT
    Thanks for the simple and straight forward instructions.
    Nancy W. Abramson on October 22, 2009 4:48 PM GMT
    Very helpful
    Great stuff. Thanks much for your work.
    jpmalek on August 15, 2009 8:41 PM GMT
    good tutorial
    Hello, Thank you for this tutorial. It's been great help. I am however having a small problem. when i run the following: SYSTEM xfs_freeze -f /vol i get >> xfs_freeze: cannot freeze filesystem at /vol: Operation not permitted any ideas on what could be causing this ? ANy suggestions are most certainly welcome. Thank you Nabil
    nlazouzi on July 22, 2009 12:36 AM GMT
    Very nice solution
    I second all those of us who were benefit by your exceptional tutorial. I wanted to add it is full of beauty. Whis is not so easy to find on technical writings. Thanks Eric.
    jorgegrippo on June 22, 2009 10:29 PM GMT
    Fantastic Tutorial
    AWS and the Ubuntu LAMP community owes Eric Hammond a debt of gratitude. He is one of the most effective, generous, and clear-minded technologists out there. This tutorial works perfectly and I refer to it often.
    Gandalf on May 25, 2009 6:50 PM GMT
    Great tutorial
    Thanks for posting great tutorial. It guides me properly while start setting-up my test environment from scratch. Anyway I tried using symbol link instead of modifying mysql configuration, but I failed to run mysql successfully. Is there anyone who succeeds in using symbolic link. I tried to make a symbol link ln -s /vol/lib/mysql /var/lib/mysql.
    zoodak on May 7, 2009 10:03 PM GMT
    Great methodology
    Hi Eric - this is a great tutorial, I've now set up two servers one 64 bit the other 32 and it's working very well for me. I've also built my apache files onto the EBS volume so I can switch between a small, large xl server depending on the traffic on my site. next step is to build load balancer, with multiple apache/mysql servers - still need to the traffic to grow though :) Graham
    thegreyham on April 13, 2009 9:33 AM GMT
    Worked for me
    I'm new to EC2 and Ubuntu, just migrating my web app from Solaris on another cloud computing platform. If everyone wrote tutorials with this clarity the world would be a better place. Thanks!
    Robert Krikorian on February 27, 2009 5:37 PM GMT
    Great article. After following this tutorial on a Fedora instance I had a small problem with my PHP config and MySQL client config, but these problems were easily remedied by a couple changes outlined here:
    Richard Rauser on February 25, 2009 12:33 PM GMT
    Looks great..but I am getting errors
    Hi, We use Intrepid 8.10. After mount /vol, my systems hangs up. I cannot login or access my application. If I reboot the instance (from ec2 web console), that doesnt help. When I do mkfs.xfs /dev/sdh, it tells me that there is an existing file system at /dev/sdh, use -f option to force it. I tried it with -f and I also tried by skipping the mkfs.sxfs step. apt-get upgrade is updating many files, so I also tried to skip it, but no use. Please help. Thank you
    vpolineni on February 19, 2009 8:55 PM GMT
    Watch out for AppArmor
    Hello, Fantastic article. the only issue I had was that AppArmor needed to be updated with the new data locations. Details: Step 1 Edit: /etc/apparmor.d/usr.sbin.mysqld Step 2 : sudo invoke-rc.d apparmor restart -A
    alanol on February 1, 2009 11:09 PM GMT
    Great tutorial
    Great tutorial on how setting up MySQL on an AMI with EBS on EC2. Almost exact same steps can be applied for Fedora. Since this tutorial was written pre-AWS Management Console (, I've written a tutorial for doing the above steps using AMC (, heavily based upon this tutorial. Hope you find that useful too.
    awsmrami on January 18, 2009 1:44 PM GMT
    Terminating scenario
    Great article. Thanks. I have one question though - When terminating the instance, are there any preparations needed to be made? (unmounted the device? detaching?) Can I simply terminate the instance and they, say the next day, restart and instance and have everything working properly? (Assuming, of course, I bundled an AMI after following these instructions and the volume is untouched) Thanks again...
    contextin on November 12, 2008 10:03 AM GMT
    Perl DBI Dependency
    N.B. I needed to apt-get install libdbi-perl to run this script Alex
    Alex Farrill on October 23, 2008 2:25 AM GMT
    anything for dumb people as me?
    Your article seems nice, but actually for not so skilled men I am afraid it is too unueasy. I have just been on Simones presentation of AWS, and i like it, and i want to start using AWS for some (all?) of our projects, but I'm not sure if we will be able to do what is all necessary. Today, we are using simple managed serverhosting, so when i want to install some PHP+mysql website, i just click in our management to create (sub)domain and database, define name and password for ftp and database and that's it (30 seconds totaly with one simple browser window with few fields). Then i put there our PHP scripts using FTP, they automaticaly generate the database tables (or I do it using our common PHPmyAdmin) and voila - it works. I'm now trying to find such simple way of using AWS and replace our managed serverhosting, but all seems so difficult. But anyway thank you for this article, i will post it to my programmers with some linux experience, thay may understand it better then me. Or if someone will find some easy article like "how to install wordpress CMS on AWS for novices", i would love a link on, thank you ;)
    tomaskapler on October 20, 2008 8:12 PM GMT
    Minor changes to get it working on Fedora-based instances
    This is a very concise tutorial and worked for me on a Fedora instance, except for some changes needed to the /etc/init.d/mysqld startup script. The change needed was to update the references in /etc/init.d/mysqld to point to /vol (/var is hard-coded in the file) and to add -S$socketfile to the line that calls /usr/bin/mysqladmin to point to our non-standard socket file location. Other than that, great job!
    B. True on September 4, 2008 10:49 PM GMT
    Dude, this is awesome. I tried all over the web to get the backup setup for my EC2 mysql instance and couldn't find anything until I stumbled upon this. I tried the steps you mentioned and it worked like a gem. Thanks a lot for all your hard work for writing such a detailed steps and also, making it work. I owe a bunch of thanks to you for it.
    srigotti on September 4, 2008 2:46 AM GMT
    Great article.
    Thanks for posting this. Is there any reason one shouldn't use /var/lib/mysql symlinked to /vol/lib/mysql ? Then the reconfiguring mysql part can be skipped.
    smarttux on August 27, 2008 9:23 PM GMT
    This is great
    Both the feature and your notes are great. You always want to use FLUSH TABLES WITH READ LOCK whether or not InnoDB is in use. Otherwise you risk getting the snapshot with DDL in mid-flight (frm file exists and storage engine does not know about it, frm file does not exist and storage engine thinks it does).
    Mark Callaghan on August 24, 2008 3:42 PM GMT
    great tutorial
    Thank you very much. However I had to change one thing: perl -pi -e 's%/var/log/%/vol/log/%' /vol/log/mysql-bin.index to: perl -pi -e 's%/var/log/%/vol/log/%' /vol/log/mysql/mysql-bin.index and it worked.
    petterim on August 21, 2008 8:52 PM GMT
    Great tutorial
    Congratulations, Eric, this tutorial is very well written, concise, and clear. I am sure it will be useful for many developers. Keep the good job :-)
    simonebrunozzi on August 21, 2008 1:48 PM GMT
    Thanks for cutting to the chase
    Thanks for a concise and helpful rundown of the basic issues involved here. Sometime I would love to see other people's thoughts on how to tune mysql's internal cache and other variables for speed and reliability on EBS, but this article was exactly what i needed to get started quickly.
    Caleb Maclennan on August 21, 2008 11:53 AM GMT
    We are temporarily not accepting new comments.
    ©2014, Amazon Web Services, Inc. or its affiliates. All rights reserved.