How to take Amazon EC2 for a test-drive

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

After you go to the Amazon Web Services site and create an account, you simply sign up for whichever AWS product you need. It’s like any other e-commerce experience, credit card info included, but with one rather significant exception: a so-called Free Tier that gives you enough compute, storage, and Internet throughput resources to run a fairly capable Linux-based Web server for free for a year. After that, the services revert to pay-as-you-go pricing that works out to around $20 per month, depending upon your choices during setup and how much traffic actually arrives. It’s not too shabby for a highly available Linux server with which you can do anything you want.

AWS encompasses a wide range, from compute resources to various storage products to server monitoring, messaging, and application services. In my case, I had my eye on the well-known Elastic Compute Cloud or EC2, which includes the paravirtualized compute instances that actually run your applications, Amazon EBS (Elastic Block Storage) for instance storage, and Internet access.

Choosing resources and paying for them

EC2 compute instances range from Micro, which I ended up using, all the way up to massive GPU-equipped clusters targeted at HPC environments. The Micro instance includes one virtual core with up to two ECUs of burstable CPU bandwidth, 613MB of RAM, no dedicated instance storage, and “low” I/O performance — and costs 2 cents per hour after the first year. The other type I considered was the Small instance, which includes one virtual core with a single ECU, 1.7GB of RAM, 160GB of dedicated instance storage, and “moderate” I/O performance — at a rate of 8.5 cents per hour from the first time you power it up.

At a rate four times more expensive than that of the Micro instance, the Small instance immediately disqualified itself. Another reason to go with a Micro instance was the burstable CPU allocation. On balance, a Micro instance ends up with less CPU bandwidth than a Small instance, but for short periods of time, it’s allowed to use double the maximum the Small instance can offer. Since Web traffic (especially for small sites) is often very bursty, that makes the Micro instance a better choice in many cases.

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.

IP addressing and simple firewalling are both free services included with EC2. Your instance will start up with a private IP address, which is behind a NAT firewall. You can influence the firewall config through the creation of Security Groups, allowing you to provision simple IP service, source, and destination ACLs to protect your instances. Any more complicated application-layer firewalling has to be done on your instances.

Beyond that, you can create an Elastic IP, essentially a static IP allocation you can attach to any instance you want (and later re-attach it to a different instance). Without an Elastic IP, you still get a public IP, but it’s tied to the instance and isn’t portable. Elastic IPs don’t cost anything so long as they are tied to an active instance — if you sit on one without using it, you end up paying 1 cent per hour for the privilege of hanging onto it.

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.

All that remained after creating the instance was to turn it on and start configuring the applications.

Putting it all together

In the end, AWS ended up being an excellent answer to my friend’s needs: very cheap, easy to manage, and capable. If you remove all the time I spent figuring out what kind of instance I wanted and which AMI to use, the end-to-end duration — everything from signing up to the point where I was SSH’d into the server — was about 10 minutes. While the low performance of the Micro instance is noticeable at times (especially when running CPU-intensive processes such as down-sampling uploaded images or video), in general it handles the load of a small site without any complaint.

Notwithstanding recent availability concerns, I highly recommend getting your own free Micro instance to play with. At worst, you can have it for a year, pay nothing for it, and get to say you gave the cloud a spin.

This article, “How to take Amazon EC2 for a test-drive,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.