我正在考虑扩展 Amazon EC2 实例。我使用 ASP.NET 开发了我的应用程序，因此我必须选择使用 Windows EC2 实例。MySQL 和图像由其他实例提供，因此扩展（目前）仅适用于 Web 应用程序实例。
我的选择（目前）：
- 小型 64 位实例- 从 32 位小型实例开始，创建一个弹性负载均衡器，在流量增加时根据需要添加更多小型实例（取决于我设置的 CloudWatch 规格）。
- 中高 CPU 实例- 从中高 CPU 实例开始（成本更高，但功能更强大），创建弹性负载均衡器，并在需要时添加更多中高 CPI 实例。
与中型实例相比，第一种选择更便宜，并且允许应用程序逐渐扩展，中型实例仅适用于 32 位，因此我有点被锁定在 32 位。我不想扩大规模，因为我更喜欢水平扩展。这意味着当流量较低时，我不会支付中型实例的高价。因此，对于第二种选择，我可以选择使用 64 位小型实例，并通过在 Elastic Load Balancer 下添加更多服务器来水平扩展，这自动取决于从 Amazon CloudWatch 获得的规格（即 CPU、RAM 等）。
我的问题是我不知道该选哪一个。我读到中高 CPU 实例比小实例强大 5 倍。但一开始价格有点太高了。一般来说，我更喜欢少付钱，在需要时通过添加更多小实例来扩展。
我需要你的帮助来选择要走哪条路。每种方法有什么优势？如果有优势，为什么在水平扩展方面，中高 CPU 比小 CPU 更好。毕竟，围绕云架构的所有想法都是能够节省在给定时间范围内不需要其计算能力的服务器上的成本。
我尽了最大努力优化实例，对页面和 MySQL 的 SQL 查询都使用了缓存（Xeround 上有缓存，解决了数据库扩展的问题）。我的数据库相对较小（1000 行，数据量不大），因此小型实例上的 1.7GB RAM 足以满足我的缓存需求。我认为流量增加时主要问题将出现在 CPU 上。此外，存储空间也非常小，仅托管我的网站 ASPX 页面。
我假设该应用程序每天可以吸引数万名访问者，甚至更多。因此，扩展是必须的 - 但是小规模实例的水平扩展是否明智之举？ - 对于高流量的 Web 应用程序来说，这是否是更明智的选择？
目前我更倾向于小型实例 + Elastic Load Balancer 解决方案。费用少一点，随着应用程序的增长而增加费用似乎合乎逻辑。
等待您的专业解答。谢谢。
答案1
一定要从小处着手。您可以随时迁移到更大的实例大小。如果您在设计时考虑了水平扩展，那么后端可以是任意系统的混合体。
答案2
如果 CPU 确实是瓶颈，那么中等配置更划算，因为它的 CPU 是 5 倍，成本是 2 倍。不过我怀疑你的瓶颈可能在文件 io 上，在这种情况下，中等配置可能仅比小配置略胜一筹。