On the other hand if you just need memory (without necessarily having the clock cycles to quickly access it), or just something that will eventually handle occasional requests, a micro instance should be just fine.
I started the ./configure, and it blasted through 40 or 50 checks almost instantly, then stopped. Suddenly, it started taking about 3-5 seconds for each check (i.e. 'check for blarg in -lfoo'). For the rest of the compile, it was like I'd gone back in time ten years; incredibly slow. Checking top, it showed the %steal at 99.5-100% - the host system was scheduling almost no CPU at all to my machine.
Playing around, I found that you basically get a specific allotment of CPU cycles per a certain amount of time, and once you run out you don't get any more for a while (other than the bare minimum to keep the server working). This makes it great for 'bursty' load cases, but after you burst burst, they cut you off, so it's terrible if you suddenly get a sustained burst of traffic.
It's so bad that I spun up a clone of the machine, compiled SSH there, and then spun it down afterwards, which turned out to take easily half the time as compiling it on the micro instance itself.
So: great for personal blogs; terrible for suddenly getting traffic to your personal blogs.
http://blog.documentcloud.org/blog/2010/09/evaluating-amazon...
1GB Rackspace vs EC2 Micro - CPU Performance: http://cloudharmony.com/ws/getServerBenchmarkResults?serverI...
1GB Rackspace vs EC2 Micro - IO Performance (using EC2 EBS): http://cloudharmony.com/ws/getServerBenchmarkResults?serverI...
16GB Rackspace vs EC2 cc.4xlarge - CPU Performance: http://cloudharmony.com/ws/getServerBenchmarkResults?serverI...
16GB Rackspace vs EC2 cc.4xlarge - IO Performance: http://cloudharmony.com/ws/getServerBenchmarkResults?serverI...
http://cloudharmony.com/benchmarks (click on the 'View benchmark results' link on the bottom left)
My post was mostly meant to illustrate that Amazon puts hard limits on how your VM operates (which makes it inconsistent over time under load), vs. Rackspace, which gives you a constant amount of CPU capacity all the time.
I can say that when executing kcbench (set to do 4 kernel compiles, same configuration on all machines, using a '-j' equal to the number of CPUs in /proc/cpuinfo) I got the following times:
EC2 Small Node: ~849 seconds
Rackspace 1GB Node: ~81 seconds
Based on that, for CPU heavy jobs I would put a 1GB Rackspace node at something like 25x faster than the EC2 micro node.
I found that for the most part, in order to compete with Rackspace on CPU you needed to go with at least an Extra Large (which was about on par with Rackspace) or a High-CPU Extra Large (which managed kcbench in ~44 seconds).