我想知道哪个会更好，在EC2上托管一个具有许多微实例的站点，或者更少的大型实例，例如m1.large . 所有这些都将作为负载 balancer 器位于一个或几个更大的实例后面 . 我会说出我的理解是什么，如果我错了，任何知道更好的人都可以添加或纠正我
选择微实例的主要原因是成本 . 单个微型实例平均每小时0.02美元可以提供0.35ECU，而一个小型实例将以0.085美元提供1ECU . 如果你进行$ / ECU /小时的数学计算，微型实例的成本为0.057美元/ ECU /小时，而小型实例则为0.085美元/ ECU /小时 . 因此，对于相同的平均计算能力，选择100个微实例将比35个小实例便宜 .
微实例的主要问题是性能波动较大，但是当你有很多实例时，我不确定这是不是一个问题 .
那么有没有人有这样的设置和看到好处和缺点的经验？请告诉我，因为我正在尝试选择哪条路，谢谢！
PS：关于这个问题的文章，http://huanliu.wordpress.com/2010/09/10/amazon-ec2-micro-instances-deeper-dive/
2 回答
Beware of micro-instances, 他们可能会咬你 . 我们在微实例上都有测试环境 . 由于它们只是功能测试环境，因此工作顺利 . 但是，我们碰巧更新了一些应用程序（好吧，Jetty 7.5.3），它已经知道了提高CPU使用率的错误 . 这使得这些实例无用，因为亚马逊将可用CPU限制为2％ .
此外，微实例是EBS支持的 . 对于高IO操作（例如Cassandra or the likes所需的操作），不建议使用EBS（通过实例存储） .
如果您想省钱并且您的软件是architected to handle interruptions，您可以选择现场实例 . 他们通常cost less than on-demand ones .
如果所有这些都不是你的问题，我会说，微实例是要走的路！ :)
Basics questions about micro instances performance
CPU pattern for micro
Stolen CPU on micro
我会说：取决于你的应用程序将具有什么样的架构以及它需要多么可靠：
AWS Load Balancers不提供即时（可能是实时更好的词？）自动扩展，这与故障转移概念不同 . 它不时地用于 Health 检查并且具有小的延迟，因为它是通过http请求完成的（如果选择https，则会产生更多的开销） .
如果根据体系结构选择更多实例，则会有更多失败点 . 为避免这种情况，您的应用需要在实例之间保持异步 .
如果您选择更多实例，则必须对您的应用程序进行基准测试和测试，以确保这些突发不会对您的应用程序造成太大影响 .
这是我的观点，这将是有经验的人之间非常愉快的讨论 .