I just spent about a day and half working with various Amazon Cloud Computing products to investigate the possibility of moving Agtek's server offerings out of our facility and into Amazon's Cloud. As it's the day before Thanksgiving I thought I'd document all my findings so that when I come back to work next week there will be a record.

Amazon's cloud computing infrastructure is organized into a range of very specific products. The products are all designed to work together as building blocks for a complete solution. The products I investigated were:

1. Amazon EC2 - Elastic Compute Cloud
2. Amazon RDS - Relational Database Service
3. Amazon EBS - Elastic Block Store
4. Amazon S3 - Simple Storage Service

Amazon's EC2 service allows customers to dynamically create and deploy Linux or Window servers. You pay an hourly rate based on the performance of the server. A basic server with 1.7gb of memory and an approx. 1.5ghz equivalent processor runs $0.085/hour. Prices climb quickly as you require higher performance machines. You can select from a huge variety of server configurations. You can also modify the configuration, create a bootable image from it, store the image in S3 and directly boot from that. For example, I started with the most basic Fedora 8 configuration they had and installed Sun's Java 1.6 distribution (required by the Agtek Access Server). I created an Amazon AMI image directly from the machine and stored it to our S3 account. I can now use that image anytime I want to launch a new server. There is local storage associated with the running server but it is NOT persistent. To store persisted data your application must use either S3 or EBS.

Amazon's RDS service is similar to EC2 except that it is completely focused on providing MySQL 5.1 compliant servers. You pay an hourly rate which is slightly higher but similar to the EC2 rate to run a fully configured and managed MySQL 5.1 server. Additionally you pay a monthly fee for the database storage associated with the server. Included in the cost is a nightly backup with single day retention. Multiple day retention is available but may cost extra (depends on storage requirements). For my tests I used a basic machine with 5gb of persistent storage.

Amazon's EBS service allows customers to buy the equivalent of a raided disk system and attach it to a running EC2 server. Disk sizes range from 5gb to 1tb. They claim that reliability is 10 times that of a standard raid disk system but the details are a bit sketchy. If additional reliability is required the EBS can be backed up to your S3 account. The advantage of EBS over S3 is that EBS can be formatted to act just like a local hard disk. I did not test this product as I didn't need persistent storage for the tests.

Amazon's S3 service is the backbone of the whole system. S3 provides long term, fully reliable data storage. All the other products fall back on S3 for reliable storage. For example, if you create your own AMI image to boot an EC2 server Amazon requires that the image is stored in S3. All the RDS and EBS data backups are done to S3. We are currently using S3 for backing up various Agtek machines (through Jungle Disk).

Our goal is to eventually (hopefully in the next month) move all Agtek server products out of the lab here in Livermore and into some hosting/cloud solution. Keeping that goal in mind I set out to try the following with the Amazon products:

1. Start an Amazon EC2 instance running an acceptable version of Linux
2. Install the Agtek Access Server and database on the instance
3. Run, configure and test the server with our standard 20 GPS load test
4. Start an Amazon RDS instance to host the Access Server database
5. Start an Amazon EC2 instance running just the Access Server, no database
6. Run, configure and test the server with our standard 20 GPS load test
7. Create a custom EC2 image containing everything we need for our server.
8. Start an Amazon EC2 instance running our custom image.
9. Sanity check all the various Amazon charges

The hardest part of running an EC2 instance is finding the configuration you want. There are tons of configurations and they aren't well indexed. I ended up resorting to Google searches and never did find the exact one I wanted. Finally I gave up and just launched a basic Fedora 8 configuration that contained a full LAMP stack. There is a lot of security issues that have to be addressed the first time you launch an EC2 instance, but once those are understood and handled they are taken care for all future instances. Within about 2 hours I was able to figure out the whole thing, launch an instance, install our server and run the basic load test. In this test the Access Server and MySQL database were both on the EC2 instance. With both running on the smallest/cheapest EC2 available CPU utilization did not go over 25% while running the load test and memory usage did not go over 50%.

A better solution for our server would be to offload the database to a dedicated and managed server and just use the EC2 instance to run the Access Server and store the track data. There is a bit of a chicken and egg issue that occurs at this point. In order to minimize network bandwidth charges you need to have both the EC2 and RDS instances running in the same Amazon Availability Zone. This is much easier to do with the RDS than with the EC2. However, you need to know the address of the RDS before you can start the Access Server. I ended up going through the following steps:

1. Launch an EC2 instance
2. Install our server software
3. Launch an RDS instance in the same availability zone as the EC2
4. Get the RDS ip address
5. Configure the Access Server to use the RDS for database storage
6. Start the Access Server

Once I got all this configured and set up I ran the standard 20 GPS load test. Peak CPU usage on the EC2 was 15% and memory usage never exceeded 33%. Peak CPU usage on the RDS was 7%, I could not find the stats for memory usage. In both cases I was using the smallest, cheapest servers available.

Finally, I set out to create a custom server image containing a basic Fedora 8 configuration with the Sun JDK that the Access Server required. This took more time than all the other testing combined! The fault lies in a combination of our of date documentation on the Amazon website and a bug in their web based management console. I did finally get it working and was able to launch a new EC2 instance running the custom server image I built.

It did expose a non-trivial issue. Unless you explicitly pay for Amazon tech support (starts at $100/month) the only support you get is the online documentation and the user forums. There is NO e-mail address you can send a question to. Additionally, many of the features, such as the web based management console, are listed as BETA…..and they should be. In fact, the entire RDS service is listed as BETA as Amazon only began offering it in October of this year (yes, last month).

All my testing over the last two days including starting and stopping EC2 and RDS instances, uploading large amounts of software multiple times (Access Server code and Java distributions) and running the load tests totaled out at less than $2.00. That is the nice thing about this system, if you aren't using resources you aren't getting charged for them. You also have to be careful. When I first ran the EC2/RDS combo the instances were in different “Amazon Availability Zones” and we were getting charged for all transactions between the server and the database. If the two instances are in the same zone there would have been no charge (those charges only totaled $0.02).