views:

51

answers:

3

I'm about ready to launch our company's web site on Amazon's EC2, and have a fairly simple architectural question: Should I use an array of Small instances for the web / application layer, or an array of Large instances?

This is a fairly broad question, I realize. So to add some clarifying details:

  • Our application is a public-facing e-commerce system. Not a tremendous amount of computation happening, beyond what is typical of an dynamic web site
  • Our app is written in ASP.NET MVC
  • The database is on a separate server

I'm hoping to make a decision that factors in both the performance and cost of these very different instance types. Any thoughts?

+1  A: 

This question is difficult to answer because the question shouldn't be "what instance type should I built my site on?" but rather "how should i scale my site?".

The concept behind EC2 is that you can fluidly scale a website without needing to reconfigure your application. Having a large cluster of small instances behind a load balancer would enable you to have a higher reliability and more even load, though you could accomplish the same goal with a smaller number of larger servers (which, though performant, might not give you a lot of benefits due to the size of your project).

Strictly speaking, front-end web servers should not need to be powerhouses. I push five million hits a month through a single $20/mon box at Linode (though I've pushed more than 15 million with no problems at all). Could I be investing more in my architecture? Sure, I could increase redundancy by adding more mirror boxes, I could increase performance by adding boxes in more data centers, and I could bulk up the box(es) that I have by adding more memory and CPU.

My point is that if you have large boxes and you're not using them fully, you're wasting your resources. If you have small boxes and switch them on and off to adjust to your needs, you're making better use of your resources.

As for the architecture that you've specified, it looks like you're going to want to get a few (small) front-facing web servers online behind a load balancer. Start small and boot up more as your site calls for it. As for your database, I'd suggest a larger, mid-range instance. Make sure your data is pushed to EBS and not the instance storage itself. It might also be worthwhile to add a secondary slave DB server that you replicate to (for redundancy).

The key is to monitor your resources very carefully. Spending lots of money on servers may seem well-justified, but paying for EC2 instances that go unused is simply unwise.

Hope this helps!

mattbasta
Thanks -- that is actually quite helpful. I'm confident that I don't need the additional RAM that comes with a Large instance. The real wild card with EC2 instances is that network and disk IO are apparently slower for Small Instances. Amazon doesn't have any metrics on *how much* slower, though.
Chessaurus
I would consider the extra latency to be insignificant. I would imagine that it's because there are more smaller instances per physical server (larger instances have a lower instance density per physical server), thus there is more traffic and routing that must be done.
mattbasta
A: 

The best answer is to do some load testing and see what gives you better performance/$ based on your application.

The great thing about EC2 is that you can quickly setup a test environment for a couple hours and just try it out.

Once your application is in production it shouldn't be a big deal for you to change instance sizes as needed based on monitoring your actual utilization and usage profiles.

Scrappydog
A: 

I think you're calling out one of the great benefits of EC2... Save your money and run the app on a small instance. If you find that there's no enough power than just fail-over to a larger instance.

Simon Ellis