I moved one of my blogs there, from a vmware instance that I was running in a physical server of my own, hosted at Colt Telecom, and my deception was huge.
That instance frozen often! According to Amazon EC2 web it was Ok, but it was totally KO. No ping, unable to log by ssh.
The only solution then was to shutdown the instance from the EC2 console, what it takes some time, because in fact, machine was down but the console didn’t know.
Once down, then start again. Reassign the static Ip address (Amazon calls it Elastic Ip).
And once or twice per week I had one of those frozen.
I tried to found a pattern of why instance freezes, but no luck. It simply happen.
I was about to leave Amazon forever when I decided to try the next instance size, just in case, the Small, and problems disappeared forever.
Now, that I have started my project CMIPS to measure and compare the Cloud performance (different providers and instance types), I see how bad it was t1.micro.
Even without the freezes, my not-so-modern ultra-portable laptop performs several times faster (x9.39 times faster), so any project hosted in a t1.micro will suffer a pathetic performance.
Later I discovered that sometimes the Amazon servers where your instances are running have a hardware problem or die. A reboot doesn’t help, since when you reboot, you don’t change the server that hosts your instance (guest).
Only poweroff makes Amazon to assign you another physical server.
And as later I learned, from time to time, no matter how good your instances are -but with expensive instances it happens much less-, without a reason one of your instances can freeze. So if your Startup has 30 instances, monitor them, because one can freeze some day. It just happens. I guess hardware crashes. And it could be one of the databases that gets knock down.
If you’re lucky you’ll have no corruption in the network storage, if not you will loss data. So backup.
It has occurred to me twice with my private instances in Amazon (not counting the nightmare t1.micro), but we suffered it from time to time when I worked for a videogames company where we had many always-on servers and where we were creating on the fly, scaling the number of instances, according to the increasingly or decreasingly number of users.