From John Sword’s blog.

The following is a hands-on review of my recent experience moving from traditional managed dedicated LAMP hosting to Amazon Web Services (AWS).  If you are a weekend warrior Linux admin like me and have been eyeing up AWS for hosting your projects but are still uninitiated, this is written for you.  If not, you may want to overt your eyes as its about to get a little nerdy in here.

Introduction

I have been administrating LAMP web servers in some form or another for more than a decade either in support of a business or for personal use.  I seem to never have so few projects that shared hosting made sense.  So instead, solutions like virtual private servers, managed dedicated hosting and, in some cases, my own rack of equipment have served up my projects over the years.

Most recently I had been using dedicated managed servers on Rackspace and GoDaddy to host a few dozen sites.  Because I no longer run my own DNS or mail servers, it made my migration focused on making MySQL and Apache work on AWS.   (I no longer host DNS or mail because as I have found services like EveryDNS and Gmail to be far superior.)

Why and What is AWS

There are many advantages to using AWS (or any elastic/cloud computing platform) over a traditional dedicated server solution including cost, speed and flexibility.  For example, a basic AWS configuration including metered usage charges will cost most people in a similar situation to mine less than $100 per month.  The same solution on a dedicated server would be two to five times the cost, significantly slower in performance, and be at risk of bottlenecking under heavy traffic.

AWS consists of a group of services that represent what is essentially a deconstructed web server.  If you are new to virtualization, this is a very different way to think about running a server.  (I’m sure you’ll figure out somewhere else to put your Tux sticker now that your server is in the cloud.)

Here is a summary of the core AWS services:

Elastic Compute Cloud (EC2) - EC2 is Amazon’s version of a virtual server but with one major caveat — it has a forgetful hard drive.   EC2 instances have ephemeral memory which means that any changes made to its file system are lost on cold restart or because of AWS system failure.  If you want permanent storage, you must use EBS or S3 (both defined below) to store files that must change over time.

Simple Storage Service (S3) - S3 is Amazon’s file serving solution which is managed much like an old school FTP server.   You setup a bucket, toss files into it and then reference them with a URL.  You can also use S3 to store private data such as backups.

CloudFront - (What? No cool alpha-numeric acronym?  Come on guys!) When linked to an S3 bucket, CloudFront acts as an affordable and fast  content delivery network (CDN).  Pricing starts at  17 cents per GB without a contract which is roughly half of what most well established CDNs charge new customers under contract.

Elastic Block Storage (EBS) - Remember how EC2 storage is temporary?  EBS is Amazon’s attached storage solution for EC2 instances.   You can format an EBS volume with any file system you want and mount it just like a hard drive.

Getting Started

The first step in migrating to AWS is getting a virtual server running and configured.  But first, if you have not already, sign up for an AWS account here.  Once that is taken care of you will want to head over to the Management Console where you will want to launch an EC2 instance.

Before you can start up an instance, you’ll need to click on the Key Pairs menu option and generate a private key file (.pem extension). Keep this file secure (and chmod 400 its permissions). You will reference this key pair when starting your instance and the private key fie will be needed to log into the instance.

You will need to choose which stock, off-the-shelf Amazon Machine Image (AMI) to use. Once you have done this once and have an image you like, you can bundle and back it up to one of your S3 buckets for future provisioning.  For purposes of this review, I’m assuming you chose a base Fedora Linux server on a standard size instance.

Once the instance is online, which can take up to a few minutes, go to the EBS tab of the Management Console and create an volume and attach it to your EC2 instance.  I chose 20 GB and chose to reference it as /dev/sdh.

EC2 instances have dynamic IP addresses so you will want to configure an elastic IP address in the Management Console to point to your EC2 instance so your DNS is guaranteed to always resolve.

SSH into the Instance

You will need to download a .pem file which you’ll use to authenticate with SSH into the server.

>ssh -i filename.pem root@address-of-your-server.amazonaws.com

Preparing the EBS Volume

The next step is to prepare the EBS volume so that you have a permanent storage location for MySQL and Apache.

I read quite a few conflicting blog posts about what file system to use on the EBS on a general purpose web server.  I found some consensus that XFS is a good choice because it more cleanly handles backup snapshots of the MySQL data,  so I went with that.

Fedora does not by default have XFS support, so you’ll need to add it:

>yum install xfsprogs

Now you are ready to format the EBS, create a mount point for it, mount it, and make sure it mounts on restart:

>mkfs.xfs /dev/sdh
>mkdir /mnt/ebs1
>mount -t xfs /dev/sdh /mnt/ebs1
>echo “/dev/sdh /mnt/ebs1 xfs noatime 0 0″ >> /etc/fstab

Install Apache, PHP and MySQL

Let’s start out by grabbing the packages and installing them to their default locations:

>yum -y install httpd php mysql mysql-server php-mysql

Confirm both services will start:

>/etc/init.d/httpd start
>/etc/init.d/mysqld start

Move MySQL to the EBS

Before we move it, let’s do some basic MySQL house cleaning:

>mysqladmin -u root password ‘newpassword’
>mysql -u root -p  password
>DELETE FROM mysql.user WHERE user = ‘’;
>FLUSH PRIVILEGES;
>quit

Now let’s stop the service, move the MySQL directory to the EBS volume and setup a symbolic link to the new location:

>/etc/init.d/mysqld stop
>mv /var/lib/mysql /mnt/ebs1/mysql
>ln -s /mnt/ebs1/mysql /var/lib
>/etc/init.d/mysqld start

Move Apache to the EBS

It’s a similar process for Apache.  We stop the service, move the configuration and web directories to the EBS, setup symbolic links to the new location and bring the service back up:

>/etc/init.d/httpd stop
>mv /etc/httpd /mnt/ebs1/httpd
>ln -s /mnt/ebs1/httpd /etc/
>mv /var/www /mnt/ebs1/www
>ln -s /mnt/ebs1/www /var/
>/etc/init.d/httpd start

Depending on your configuration, you may need to set these symbolic links:

>ln -s /var/run /mnt/ebs1/httpd
>ln -s /usr/lib/httpd/modules /mnt/ebs1/httpd

Next Steps
You are ready to rock and roll at this point.  Before you begin migrating your live projects over to the EC2 instance, I recommend doing the following:

• Setup and test an automated snapshot backup strategy for the EBS that stores the snapshots on S3.
• Test your ability to relaunch an EC2 instance and connect it to the existing formatted EBS.
• Bundle and backup a custom AMI based on the configured system so it only takes minutes to get back up and running after an instance failure.  Then test a restore.