Just about everyone I know in IT has gotten the dreaded phone call from a friend or acquaintance that begins: "Can you help me fix my computer?" If the person on the the line is persistent enough, the result always seems to be a late night drinking beer and cleaning spyware off a PC that was manufactured during the Clinton era.
Earlier this week, however, I got a more interesting query -- one that may be a sign of the times. A friend wanted to set up a customized forum and image-sharing website for a group he's associated with and wasn't sure where to host it. I could have pointed him to any number of Web hosting companies, but he had a few requirements that indicated he might need a server he could fully control. The kicker: It had to be cheap -- really, really cheap.
That last requirement ruled out just about every option except a cloud-based solution. I had used Amazon.com's EC2 before, but mostly to poke around and see what it looked like, never to actually work on a project. I figured we'd give it a try.
Getting started with Amazon EC2
The storage allocation was another reason to go with the Micro instance. In this case, I needed only about 5GB of aggregate storage beyond the OS -- which, being Linux, wouldn't add up to a whole lot -- so I wouldn't have needed to add a secondary data-only volume to my instance. Using the Small instance, that means that I would have wanted to put both the OS and user data on the local instance storage rather than on an EBS volume, which is what using a Micro instance requires.
The important point is that dedicated instance storage is ephemeral; if you delete the instance or terminate it, you lose access to that storage and anything on it. Unlike instance storage, which lives on the local disk of the virtualization host that's running the instance, EBS storage is located on a shared device. That allows you to separate it from the instance, tie it to a different instance, take snapshots, or scale its size. I could also have tied an EBS volume to the Small instance, but that 160GB of ephemeral instance storage wouldn't have had much value to me, so it wasn't a decision maker.
You pay for EBS-based storage on a per-capacity and per-I/O basis. Capacity costs 10 cents per gigabyte per month (with snapshot storage costing 15 cents per gigabyte per month) and transactional I/O costs 10 cents per 1 million I/Os. For a low-traffic website with an 8GB EBS volume, this ends up being a few bucks a month on top of the cost of the instance. The priority of your I/O requests is determined by the size of the instance you're paying for. Thus, a Micro instance is on the bottom of the pile, where a large cluster instance gets a much higher EBS storage service level.
Internet access is also a pay-as-you-go cost. The Free Tier includes up to 15GB of bidirectional Internet transfer, which is more than enough for this application. Outside of the first year, transfer charges are based on a sliding scale with the first gigabyte of outbound transfer being free and subsequent outbound transfer costing 15 cents per gigabyte (transfer becomes progressively less expensive as the number goes up -- bottoming out at 8 cents per gigabyte over 150TB of transfer). Inbound transfer is always 10 cents per gigabyte.
So that initial 15GB allocation of inbound and outbound transfer ends up costing $3.60 per month after the trial period is up. It's worth noting you only pay for transfer that goes outside the EC2 availability zone where your instance is located -- so transfer to another running instance in the same zone doesn't cost anything. Similarly, traffic in between different EC2 availability zones (East to West, for example) is much cheaper at 1 cent per gigabyte.
Firing up your first instance
After signing up and mulling over what kind of instance I wanted, it was time to fire one up. Your instance is initially based on an AMI or Amazon Image. Amazon provides a number of different public AMIs for you to choose from -- including many different flavors of Linux and Windows -- along with a much wider community-provided selection. You can also upload your own image to Amazon's S3 cloud storage and then make it available as an AMI for you to base your own custom instance on.
Again, the limitations on the Free Tier played a role in my choice. I ended up going with a simple 64-bit Amazon Linux image. Amazon Linux is essentially a stripped-down version of CentOS (which is itself a stripped version of Red Hat Enterprise Linux) with some EC2-specific tools injected to make them easier to manage. The image starts with very little already installed, but using Yum to install new packages is very quick and easy. Amazon hosts its own basic Yum repository within each availability zone, so adding new packages doesn't hit your transfer totals.
Since CentOS is what I wanted from the start, this ended up working out well. My only issue ended up being that Amazon's Yum repos don't include some of the mainline CentOS packages (specifically some that have some encumbered licensing such as ffmpeg though I'm not sure if that's the reason they aren't included). However, simply reconfiguring the machine to use those external Yum repositories was all it took to easily get the packages I needed.
When you create your instance, you'll also create an SSH key pair. That key pair is what you'll need to connect to your instance for the first time (password encryption is not enabled in the image by default). Make sure you download it and store it somewhere safe -- after you've created it, you can't download it again.