Question

I’m a web developer just now getting interested in sysadmin stuff. I’ve set up a server before on Linode.com (Ubuntu 10.04 LTS, nginx, Ruby on Rails, PostgreSQL), but there were some issues. Everything was on one machine, so whenever something went wrong with Linode or I got a lot of traffic, my site would go down.

Now I’m interested in setting up a personal blog, and deploying it across Amazon AWS. This is a good opportunity for me to learn to how to use multiple servers with load balancing, auto-scaling, failover, etc. The only problem is I’m not quite sure where to start.

I’ve read a litany of documentation from Amazon and blog posts elsewhere, but as a sysadmin newbie I have a few questions:

• I get that EC2 instances are too volatile to store data on. So where should I store it? Amazon Elastic Block Store? Will the entire filesystem go there, as well as the database?
• Do I need serious knowledge of load balancing and scaling? Or will the Amazon Elastic Load Balancer handle make things simple for me? How does their load balancer interact with nginx?
• How much of this do you recommend doing through the AWS interface as opposed to through the command line?
• Any non-obvious snags that might catch me?
• Are there any tutorials for deploying a blog or simple Rails app on EC2? I don’t need a production-quality setup here; my main goal is to learn.

Thanks for any answers you can provide!

Answer 1

I’ve set up my fair share of AWS deployments; here’s basics:

Data store

If you have frequently accessed data, as you likely know, it is best to use a database. This is one of the hairier parts of AWS hosting. Your options are, roughly in increasing order of complexity/cost:

1. SimpleDB – Amazon’s own database offering. They give you an HTTP api, which you use to read and write your data. There are some rails libraries for it, but on the whole, it isn’t a graceful drop-in for rails.
2. Amazon RDS – Amazon will preconfigure a mysql-like database server for you. This requires you to boot up an DB server instance, so the pricing server isn’t favorable for tiny sites. On the plus side, it allows you to scale your DB server more easily.
3. Roll your own – Plan around Amazon EC2 instances vanishing at any point; therefore, the local storage you get with EC2 instances can best be considered a big temp directory. Elastic Block Store is Amazon’s solution to this; it effectively is a disk image your instances mount. EBS images live independently of EC2 instances, so if your server goes down, you can mount the EBS image on a new EC2 instance. You can essentially roll your own database cluster by booting a bunch of instances and configuring them to replicate off eachother. This works, but is not graceful, and should really only be attempted if you cannot solve your problem with less exotic methods.

Amazon pretty much enumerates these options, plus a few more which are not applicable to you at http://aws.amazon.com/running_databases/

Infrequently changed data should be stored in S3; there’s plenty of ruby gems for accessing this easily. If your website is entirely static on the server side, you can even run your entire site off S3

Load Balancing

Amazon “Elastic Load Balancing” is quite effective at the typical web load balancing requirements. It is usually a no-brainer choice, unless you have exotic requirements. It will not scale your cluster for you, however. For auto-booting and shutting down of instances, you should look to Amazon’s own auto-scaling solution

Caveats

Be sure to note which “Availability Zone” (aka datacenter) you’re in. In some cases, you cannot share AWS resources across availability zones.

Tutorials

There are plenty of tutorials, but in my brief search, none that I found to be really great or up to date. However, check out https://github.com/wr0ngway/rubber , which is a ruby tool for deploying apps to EC2. It will get you most of the way there.