我阅读了EC2的文档：instance types，pricing，FAQ，burstable performance以及this有关CPU积分的信息。 我甚至询问了以下AWS支持，答案也不清楚。
根据文档（虽然不太清楚）和AWS支持，所有3种实例类型在突发时具有相同的性能，它是100％使用某种类型的CPU核心。
所以这是我的思考过程。假设t2.micro的RAM足够，软件可以水平扩展。有2个t2.micro与1 t2.small具有相同的成本，假设负载在它们之间平均分配（可能通过AWS LB），它们将使用相同数量的总CPU并消耗相同数量的CPU信用。如果他们回到基线表现，那就是一样的。
但是，当它们爆裂时，2 t2.micro可以达到x2 t2.small的性能（同样的成本）。同样的概念适用于t2.medium。此外，使用较小的实例可以进行自动（或手动）缩放，从而节省资金。
所以我的问题是，鉴于RAM和水平刻度不是问题，为什么要使用除t2.micro之外的其他内容。
编辑：在回复之后，这里有一些关于它们的注释：
答案 0 :(得分：13)
您的分析似乎是正确的。
虽然处理器类型没有明确记录，但我通常会看到我的t2.micro实例配备一个Intel Xeon E5-2670 v2（Ivy Bridge）核心，而我的t2.medium实例有两个。
只要具有合理数量的CPU信用剩余，微和小应该具有相同的突发性能。我说“一个合理的数字”，因为记录的性能会在15分钟的窗口内优雅地降级，而不是像t1.micro那样急剧下降。
三个类别（核心除外，微小对小）的所有内容在你升级时乘以2：基线，每小时赚取的信用额度和信用上限。可以说，当涉及到短期突发性能（具有两个内核）时，介质非常接近于两个小，但是再次说明，正如你所指出的那样，这也恰好具有两个微处理器的能力。如果记忆不是问题，流量是适当的突发，你的分析是明智的。
虽然t1类几乎完全不适合生产环境，但t2类也是如此。他们是世界分开的。
如果您的代码内存紧凑且高效，并且您的工作负载适用于基于cpu信用的模型，那么我同意您对t2.micro所代表的优秀价值的分析。
当然，这是一个巨大的“如果”。但是，我的网络中的系统完全适合这个模型 - 它们的内存几乎完全在启动时分配，它们的负载相对较轻但在一天中变化很大。只要你没有用尽你的信用余额，我就没有看到这种方法的错误。
答案 1 :(得分：1)
这里有许多移动目标。你的实例在做什么？ 你说流量一天变化但不尖锐。因此，如果您希望使用少量t2.micro实例“密切关注”负载，您将无法使用太多的爆发，因为在每次升级时，您将获得较低的CPU积分。因此，如果大多数实例仅在负载下运行时，它们将永远不会收集CPU信用。 此外，您还会在每次启动时间和未使用但已启动的使用时间内浪费时间和金钱，因此进行过于频繁的向上/向下扩展并不是最具成本效益的。 最后但并非最不重要的是，操作系统，其他软件或多或少都有一个修复开销，运行它2次而不是一次，可能会占用系统中的应用程序更多的资源，在这种情况下，只有20％的负载可以获得CPU信用额度
如果您想要极高的成本效率，请使用现场实例。
答案 2 :(得分：0)
分配给每个实例的贷方余额各不相同。因此，虽然两个微型计算机在爆发期间可以提供两倍的性能，但它只能在一半的时间内完成。
出于可用性目的，我通常更喜欢至少两个实例。但是使用突发模型，工作量也会受到考虑。你在看持续负荷吗？或者您是否预计全天会出现随机峰值？