我在 AWS 中犯过的错误

我从 2015 年左右开始“专业地”使用 AWS。在这段时间里，我犯了很多错误。

除了偶尔删除生产数据之外，所有错误都源于无知——AWS 有太多东西要学，很容易错过一些重要的事情。

以下列出了使用 AWS 与 Laravel Forge 时最常被忽略的事情！

对 CPU 信用一无所知

我们许多人遇到的第一个错误是不知道 T2/T3/T4 实例类别上的 CPU 信用系统。

我们大多数人可能都使用过 T2 或 T3 实例类别。它们更便宜！

它们之所以更便宜，是因为它们使用 CPU 信用系统.

了解它的工作原理非常重要，尤其是在您在与应用程序相同的服务器上运行数据库时。

T3 服务器类别比 T2 更新一代。您应该优先选择 T3 类，因为它们性能更高，通常也更便宜。

T2/T3/T4g 类中的每个服务器大小都具有 CPU 阈值。如果您的 CPU 使用率超过该阈值，您就开始使用 CPU 信用。如果信用达到零，服务器将被限制在阈值。如果 CPU 使用率低于阈值，将获得 CPU 信用（最多一定数量）。

例如，t3.small 服务器大小每小时获得 24 个信用，最多 576 个信用。但是，如果您超过 20% 的 CPU 使用率，您就开始使用 CPU 信用。如果您的信用降至零，服务器将被限制在 20% 的 CPU。

T3 和 T4g 实例带有一个名为 “无限制模式” 的功能。默认情况下，此功能是启用的。如果您没有剩余的 CPU 信用，则允许您的 CPU 以额外费用超过阈值。

幸运的是，这笔费用通常很低，因此您甚至可能不会注意到账单的增加。但是，最好不要让您的服务器在 CPU 信用为零的情况下运行。

您可以在 CloudWatch 指标中监控您的 CPU 信用和突发使用情况，也可以在任何给定服务器实例的 EC2 控制面板的“监控”选项卡中监控。

您是否曾经想过 T3a 实例是什么？“a”代表 AMD。虽然 T3 实例使用英特尔 CPU，但 T3a 实例使用 AMD CPU。从技术上讲，它们在某些工作负载方面的速度比英特尔略慢。但是，对于 Web 应用程序（PHP、MySQL 等），这通常不会造成影响。

使用更便宜的实例类型，节省约 10% 的成本！

还有最新的 T4g 实例类型。它们使用 ARM 处理器，是最便宜的。CPU 速度很快，但 ARM CPU 一般来说更便宜——因此 AWS 将这些节省传递给您。这些在 Forge 上运行良好，我强烈推荐它们。

下一个更严重的错误是，没有检查 IOPS 使用情况。当磁盘卷限制发生时，它并不明显，但会导致性能问题。

与 CPU 突发类似，在与应用程序相同的服务器上运行数据库时，很容易遇到磁盘限制。

您的 EC2 服务器有卷附加到它们（至少一个，可能更多）。这些磁盘卷可能是 gp2 或 gp3 类型。

尽管更新的 gp3 卷（一般来说）更好，但它们还不是默认的卷类型。

两种卷类型都有最大 IOPS 和吞吐量数量。

您可以在下面阅读有关它们如何工作的简要概述，但有关 IOPS 如何工作的更多详细信息请访问 CloudCasts.

GP2 卷为您提供每 GB 存储空间 3 个 IOPS。最小值为 100 个 IOPS——在您配置超过 33.333 GB 时，您会获得额外的 IOPS。

GP2 IOPS 使用类似于 T3 实例的突发系统。您可以突发到 3000 个 IOPS，直到您用完信用。用完信用后，您将被限制在由卷大小确定的最大 IOPS。

当您获得 1000 GB 的存储空间时，您将达到 3000 个 IOPS，并且不再有突发可用。您能获得的最大 IOPS 为 16,000，价格昂贵，约为 5334 GB 的存储空间。

您可以查看每个卷的 CloudWatch 指标以查看 IOPS 使用情况和队列深度（较高表示不好，队列深度应该非常低，低于 1 或 2）。

GP3 卷具有固定的 IOPS 和吞吐量数量。它们从 3000 个 IOPS 和 125 MB/s 开始。这通常比 gp2 实例更好，尤其对于较小的磁盘大小（我们大多数人可能使用）。

IOPS 没有信用系统——您可以使用卷配置的任何数量。您可以根据需要分别配置更多 IOPS 和吞吐量！

GP3 卷通常应该是您的默认卷类型。但是，您应该注意，RDS 数据库当前仅支持 gp2 卷。

除了 Aurora 数据库，由于数据库的架构方式，它们基本上拥有无限的 IOPS。

要了解您是否过度使用磁盘，您可以查看任何给定卷上的以下指标。这些指标在 CloudWatch 指标中，或在 EC2 Web 控制台中单击卷时，在“监控”选项卡中找到。