AWS EC2：有什么理由不总是使用最便宜的实例？答案

【问题标题】：AWS EC2: Any reason not to always use the cheapest instance?AWS EC2：有什么理由不总是使用最便宜的实例？
【发布时间】：2023-03-26 17:00:01
【问题描述】：

在使用 Amazon Web Services 设置 EC2 时，是否有任何理由不总是使用最便宜的实例（即 t2.nano - 如果您要使用基于 tx.x 的实例）并让它自动放大（注意：UP，而不是 OUT）以使用它需要的东西？

如果您不一定需要它，为什么要从更高的实例（例如 t2.micro、t2.small、t2.medium）开始？

唯一的理由是不这样做，以确保在缩放自动调整时没有性能问题？

【问题讨论】：

投反对票？有什么特别的原因吗？
AWS 不支持自动扩展，只支持自动扩展。 Scaling UP 需要关闭实例，更改实例类型，然后重新启动实例。此外，如果您的服务器应用程序有任何内存使用设置，您可能必须在每次扩展服务器时更新这些设置。此外，在将 CPU 积分用于任何生产工作负载之前，您需要非常了解 CPU 积分在 T2 实例上的工作方式。
虽然您说的是真的，但如果您在 Auto Scaling 组中配置了某些内容，那么您无需人工干预就可以做到这一点。尽管您的应用需要支持将新节点加入组并逐步淘汰旧节点的过渡。
@MarkB 这解释了很多，谢谢。

【解决方案1】：

似乎自动向上扩展是not available in AWS，实际上你必须向外扩展。考虑到这一点，总是从您的应用可以运行良好的最小实例开始是有意义的，这可能不是最便宜的。

【讨论】：

【解决方案2】：

这一切都取决于您的应用程序使用情况。如果您在 AWS 中使用 EC2 实例测试某些东西，那么 T2 系列实例非常好，您可以继续使用它。对于生产，您可以根据您的应用程序使用以下实例。

应用使用情况：

CPU bouns 使用 C4 系列

Memory bouns 使用 R4 或 m3 系列

Storage bouns 使用 d2、i2 和 i3 系列

请找到以下链接供您参考。

【讨论】：

【解决方案3】：

在我看来这是一个相当广泛的问题，因为我们对底层应用程序一无所知，所以我将根据一些假设给出一个示例，说明它何时显然不起作用。

我还假设您在这里使用自动缩放并根据警报和指标添加另一种实例类型？

例如，如果您在自动扩缩组中有一个实例用于一个重要的以客户为中心的解决方案，那么在您的系统由于资源限制而可能无法足够快地处理请求的持续时间内，并且在进行扩缩过程时，您'可能会失去风俗和/或金钱。特别是如果您必须扩展大约 5 倍才能找到正确的实例类型。

另外，瓶颈是什么？如果它的网络 io 则通过 T2 系列进行扩展将完全没有帮助，因为您将受益于仅在某些实例类型上支持的增强网络。出于一般目的，您需要 m4 类型。

【讨论】：