What's better for deploying a website + DB on EC2: 2 small VM or a large one?

I'm planning the deployment of a mid-sized website with a SQL Server Standard DB. I've chosen Amazon EC2 to deploy it. I now have to choose between these 2 options:

1) get 2 small instances (1 core each, 1.7 GB of ram each): one for the IIS front-end, one for running the DB. Note: these "small instances" can only run the 32-bit version of Win2008 Server

2) a single large instance (4 cores, 7.5 gb of ram) where I'd install both IIS and the SQL Server. Note: this large instance can only run the 64-bit version of Win2008 Server

What's better in terms on performance, scalability, ease of management (launch up a new instance while I backup the principal instance) etc.

All suggestions and points of view are welcome!

From serverfault devguy

• This seems to be a little bit of a budget decision.

  I would take the large instance because You have more reserve, memory wise as well as cpu wise. Also I have read about the small EC2 instances becoming sluggish. A bit of headroom can't hurt.

  There also are additional cores so the cpu load of running backups might have an even tinier performance impact.

  Additionally You save one instance of Win2008 server 2008 which is cost and the associated cpu and memory overhead for running the OS two times. I have to admit that I don't know the pricing model of Win2008 Server. (Cost per CPU, thread or socket or ...)

  If You ran into saturation of the large VM, this would have occurred far earlier with the little VMs as they aren't even half the specs of the big one.

  Last but not least, if You really have to launch another instance for Backup, You only have to launch one instance.

  So with windows as the os I don't really see a benefit from splitting the workload over two tiny isolated VMs.

  devguy : thanks for the comment. It's not really a budget decision, since we already own the licenses, the the two setups differs for about 80-90€/month...so that doesn't impact a lot. I'm mostly concerned about difficult scalability options...since I'd probably need to switch to a setup like #1 (but with more powerful machines) to be able to add more front-end servers keeping a single/shared powerful DB machine.
  From deploymonkey

• The two images is probably going to be better for scalability, administration, and general management.

  The single image is probably going to be cheaper, especially if you never have to scale this site out much.

  Performance will depend largely on your implementation, but will likely be similar on both setups. The single image has more RAM and processing cores; this may be very important to your implementation (or maybe it will make no difference in the slightest).

  devguy : I'm interested in this part "Performance will depend largely on your implementation, but will likely be similar on both setups". How can they be similar? Setup #2 runs both services, but has 4 times the ram and cpu...and there's no network latency to bring the data from a separate server. My main concerns are mostly about scalability (how do I attach a new IIS machine from the same image, since it also includes the DB??)

  Chris S : The network latency between the two "machines" is likely to pale in comparison to the Internet latency of the client. Unless you're implementation is actively accessing more than ~1.5GB of DB data, the DB server's RAM is less important that the underlying disk storage, which is likely to be the same on both. Multiple machines can not run off the same underlying image; not yet anyway. If you went with setup #2, and added another IIS VM later, it would have to be different. I'm sorry for being vague, but I don't know the details of the application.

  devguy : Thanks Chris for the additional info. That is actually what I'm considering about setup #2. I have always read however that's best to have all the ram possible on the DB server (also on some Stack Overflow posts by Jeff) and that's why I thought it would be better to have a large machine with a lot of ram to run the DB. The IIS would be pretty light anyway. Sure there's the problem of scalability this way...but I hope the large machine would suffice for quite some time...until a decent initial success at least...

  deploymonkey : I looked for disk performance on EC2 and fount 2 interesting tests. There are People that run benchmarks on EC2. Just have a look. http://blog.mudy.info/2009/04/disk-io-ec2-vs-mosso-vs-linode/ http://stu.mp/2009/12/disk-io-and-throughput-benchmarks-on-amazons-ec2.html And considering the decision what to opt for, just run a simulation if You can, and You will notice, if disk io or CPU is what limits user numbers first. You might even be okay with one smaller instance. Depends on Your app.
  From Chris S

• The two previous answers give some good decision points, but one thing not mentioned is your site availability requirements - if you use either of the architectures you suggested, can you tolerate your site being down while you relaunch a crashed EC2 instance ? (startup times are especially long for Windows instances; I've seen it take up to 30 minutes)

  Whichever way you go, I recommend storing your database on a separate Elastic Block Store volume so that you can easily reattach it to a new instance in case of failure. EBS volumes are also easy to back up using the snapshot facility provided by AWS.

  devguy : yes, DB and website file would be on a separate EBS volume...so that I can also startup a new instance, attach it to that EBS volume, and stop the previous instance
  From gareth_bowles

• As You just mentioned that You can throw money at the problem and that You anticipate some scaling, go with 2 instances. That way You can gain experience with separation of services and have a better starting point for profiling and benchmarking Your services.

  You might even want to migrate Your DB to OSS at a later point which is easier that way.

  (informative: cloning and duplicating instances in EC2 is possible. This article is for linux, but maybe it gives You a hint about how to make a running copy of Your installs.)

  From deploymonkey

• I was once told by a very clever network architect which I respect a lot, that keep each machine as simple as possible. Always!

  So, I would go for small instances, seperately - once they become too small, consider upgrading them or spawning extra instances.

  Because you have them splitup from the beginning, its easier to put in extra power where needed instead of paying too much for the wrong setup.

  It becomes a bit harder to maintain and backup more images, but you also gain the benefits of more scaleability I think.

  We have run with similar setup for quite some years now, running on VMware and the SQL-server is seperated from the 2 IIS machines.

  We even have a secondary SQL now, and thats possible because we also could link them for sync purposes.

  devguy : very correct about the scalability. I'm just a bit worried about two things: 1) the setup would be more complex, and there's the possibility that is would be more complex for nothing, if we don't reach a point where the 2 instances are not enough 2) I'm worried that the total performances of the 2 machines would be sensibly less that the performances of a single large machine. I think the single large machine could last quite longer than the 2 small...
  From BerggreenDK