使用Elastic Load Balancer进行水平缩放的小型和中型EC2实例

我正在围绕扩展Amazon EC2实例进行一些辩论。 我使用ASP.NET开发了我的应用程序，所以我必须select使用Windows EC2实例。 MySQL和图像由其他实例提供，所以缩放（现在）仅适用于Web应用程序实例。

我的select（现在）：

1. 小型64位实例 – 从小实例32位开始，创buildElastic Load Balancer，在stream量上升时根据需要添加更多的小实例（取决于我设置的CloudWatch规范）。
2. 中等高CPU实例 – 从中等高CPU实例开始（成本更高，但function更强大），创buildElastic Load Balancer，并在需要时添加更多中等高CPI实例。

与Medium实例相比，第一个选项更便宜，并且允许应用程序逐渐扩展，Medium实例只能使用32位，所以我被locking到了32位。 我不想放大，因为我喜欢水平放大。 这意味着当交通不便的时候，我不会支付中等价位的高价。 因此，第二种方法是select使用64位小型实例，并在Elastic Load Balancer下添加更多服务器进行水平扩展，这取决于从Amazon CloudWatch（即CPU，RAM等）获取的规格。

我的问题是，我有问题来决定哪一个去。 我读过中高CPU实例比小实例强5倍。 但价格是有点侵略性的开始。 一般来说，我更愿意在需要的时候通过添加更多的小实例来支付更less和更多的资源

• PHP的FTP不适用于Amazon Linux EC2实例？
• 我找不到lua-devel在哪里安装
• 我的托pipe公司是否使用Amazon EC2？
• Amazon RDS到EC2复制
• 是否有在运行Windows 2008服务器的Amazon EC2上设置OpenVPN的教程？

我需要你的帮助来决定走哪条路。 每种方法的优点是什么？ 如果有优势的话，为什么在水平缩放方面，获得中高CPU的比较好？ 毕竟，围绕云架构的所有想法是能够节省在给定时间范围内不需要计算能力的服务器的成本。

我尽最大努力通过对MySQL的页面和SQL查询使用caching来优化实例（在Xeround上存在，这解决了涉及到数据库的扩展问题）。 我的数据库相对较小（1000行，数据量不多），所以对于我的caching需求，小型实例上的1.7GB RAM是可以的。 我认为当stream量上升时，主要的问题将是在CPU上。 此外，存储也很小，只是我的网站ASPX页面。

我认为这个应用程序每天可以吸引成千上万的访问者，也许更多。 所以缩放是必须的 – 但是，一个小的实例水平缩放是一个聪明的举动？ – 即使是高stream量的Web应用程序，它会是更明智的select吗？

现在我正在更多地面向小实例+ Elastic Load Balancer解决scheme。 随着应用程序的增长，付出更less，付出更多的钱似乎是合乎逻辑的。

等待你的知识丰富的答案。 谢谢。