September 18, 2010

Amazon EC2 Micro Instances (t1.micro)

Amazon recently announced a new instance type – “micro instances.”  They are wicked cheap ($54 + $0.007/hr for a 1-year reserved instance + $.10/GB per month storage) and finally make Amazon accessible to the non-business user with a few low-traffic websites.  For a typical Ubuntu 10.04 LTS (Lucid) installation with a 15GB root partition, that is only $133.32 a year for your very own server in the cloud!  I’ve been with Dreamhost for a couple years because they are inexpensive and allow shell access and “unlimited” storage*.   However, as a professional Systems Engineer, I’ve been wanting to move to something that allowed me to “own” my server.  There are many VPS (Virtual Private Server) providers out there, including Dreamhost and Linode (arguably the king of Linux VPS), but they never excited me very much. I’ll be honest and admit that I didn’t spend any time performing a detailed cost and feature analysis between the leading VPS providers, though. My day job is working with a couple hundred EC2 instances complete with dynamic spinup and spindown for capacity, so EC2 is a comfortable environment for me.  I’ve been wanting to move into EC2 for a while, but could never justify the cost of a m1.small, though.  Last week, I dived in and have moved all of my hosting over to a t1.micro (t for tiny?) instance.

Here is what Amazon has to say about the new Micro Instances (t1.micro):

“Instances of this family provide a small amount of consistent CPU resources and allow you to burst CPU capacity when additional cycles are available. They are well suited for lower throughput applications and web sites that consume significant compute cycles periodically.

  • Micro Instance 613 MB of memory, up to 2 ECUs (for short periodic bursts), EBS storage only, 32-bit or 64-bit platform”

Amazon has a good deal of information in their FAQ and a very detailed view of usage models in their User Guide.

After a few days with this new instance type, I’ve noticed CPU time is very limited. CPU bursts can only be very brief and it appears that you are penalized when you exceed your quota.  I run a zenphoto gallery that brought my instance to a crawl when trying to batch resize a bunch of images with ImageMagick. It was so bad that php was unable to return simple pages before the 60 second fast cgi timeout on the nginx process.  However, with appropriate caching strategies, these machines are more than capable of running a low traffic website. Using Apache Bench, I was able to get 1000 rpm out of the front page of this blog. That’s with the entire application stack residing on a single machine! I will elaborate more on my configuration in a future blog post.

There are a couple catches with this instance type. Storage is only EBS, which means you have to pay $0.10/GB per month above the cost of the instance time.  Also, like all hosting within Amazon, the individual instances are completely unreliable. You need to make sure that you can recreate your nodes from scratch at any point. For me this means documentation, automation, monitoring, backups, and most of all keeping everything important on a separate EBS volume so it can be moved around easily in the event of an instance failure. Even though the root partition of t1.micro instances is EBS, it is a lot easier to move data around if you don’t have to terminate the old instance before bringing up a new one.


** That’s unlimited for web use – not for backups.  They noticed my 300GB of photo backups and very politely asked me to move them to a backup account and even allowed me to keep the data there for a week while I migrated it.*</p> <div class="addtoany_share_save_container addtoany_content_bottom">

</div>