20

I was wondering which would be better, to host a site on EC2 with many micro instances, or fewer larger instances such as m1.large. All will sit behind one or a few larger instances as load balancers. I will say what my understanding is, and anybody who knows better can add or correct me if I'm wrong

Main reason for choosing micro instances is cost. A single micro instance on average will give around 0.35ECU for $0.02/hour, while one small instance will give 1ECU for $0.085. If you do the math of $/ECU/hour, a micro instance works out to be $0.057/ECU/hour, whereas for a small instance it's $0.085/ECU/hour. So for the same average computing power, choosing 100 micro instances would be cheaper than 35 small instances.

Main problem with micro instances is more fluctuating performance, but I'm not sure if this will be less of a problem when you have many instances.

So does anybody have experience benching such setups and see the benefits and drawbacks? I'm trying to choose which way to go.

PS: an article on the subject, http://huanliu.wordpress.com/2010/09/10/amazon-ec2-micro-instances-deeper-dive/

starball
  • 20,030
  • 7
  • 43
  • 238
Jd007
  • 201
  • 2
  • 6

2 Answers2

12

Beware of micro-instances, they may bite you. We have out test environment all on micro-instances. Since they are just functional test environment, it works smoothly. However, we happened to have update some application (well, Jetty 7.5.3) that has known bug of spinning higher CPU usage. This rendered those instances useless as Amazon throttles the available CPU to 2%.

Also, micro instances are EBS backed. EBS is not advisable (over instance-store) for high IO operations like the ones require for Cassandra or the likes.

If you want to save money and your software is architected to handle interruptions, you may opt for spot instances. They usually cost less than on-demand ones.

If all these are not a issue to you, I would say, micro-instances is the way to go! :)

Community
  • 1
  • 1
Nishant
  • 54,584
  • 13
  • 112
  • 127
0

I would say: depends on what kind of architecture your app will have and how reliable it will need to be:

  • AWS Load Balancers does not provide instant (maybe real-time is a better word?) auto-scale which is different of fail-over concept. It works with health checks from time to time and have its small delay because it is done via http requests (more overhead if you choose https).
  • You will have more points of failure if you choose more instances depending on architecture. To avoid it, your app will need to be async between instances.
  • You must benchmark and test more your application if you choose more instances, to guarantee those bursts won't affect your app too much.

That's my point of view and it would be a very pleasant discussion between experienced people.

gabrielhpugliese
  • 2,588
  • 19
  • 19
  • Thanks for your reply. I don't know how ELB works (and I've heard some not-so-great experiences with it from other people), but I use HAProxy, and the fail over is generally real-time (with 500 or 1000 ms checks). The check is also done with a HEAD or OPTION request, so the overhead should not be that great, but definitely there. Also I'm mostly talking about app servers, with database elsewhere, so the app servers themselves are independent, and a few of them failing should not be a problem I think, but spinning up replacement instances do take time which will affect performance for sure. – Jd007 Feb 03 '12 at 02:55