无需更改架构或工程开支即可优化 亚马逊云科技 成本

在这种经济环境下，每一美元都很重要。这篇文章将重点介绍如何在几乎不进行架构更改的情况下优化当前 亚马逊云科技 占用空间。这些建议的修改侧重于在不增加工程开销、较长的规划周期和大量时间投资的情况下提高性价比。其中许多更改可以在一夜之间为您节省10-20％。主要关注领域是：

1. 对您的 亚马逊弹性区块存储 (亚马逊 EBS ) 卷进行现代化改造
2. 交换支持 亚马逊关系数据库服务 (Amazon RDS) 和 亚马逊 Aurora 等托管服务的 底层计算
3. 探索迁移基于 Linux 的工作负载的好处，以充分利用基于 亚马逊云科技 Graviton 的 亚马逊弹性计算 云 (Amazon EC2) 实例可以提供的巨大性价比

了解您的 亚马逊云科技 环境的基础知识

在深入研究这三个具体领域之前，大致了解您的 亚马逊云科技 环境的效率将非常有帮助。您可以首先了解我们 亚马逊云科技 成本的地方是 亚马逊云科技 Cost Explorer 。Cost Explorer 具有易于使用的界面，可让您可视化、了解和管理您的 亚马逊云科技 成本和一段时间内的使用情况。通过使用 亚马逊云科技 Cost Explorer，您可以创建自定义报告来可视化您在 亚马逊云科技 上的支出，从而帮助确定成本优化的机会领域。

图 1。亚马逊云科技 Cost Explorer 中的示例成本和使用情况图

为了更好地了解您的整体 亚马逊云科技 成本和使用效率，您可以考虑的第二个地方是 Cost Explorer 中的 “调整大小建议” 功能。 调整大小建议 可帮助您通过缩小或终止 Amazon EC2 中的实例来发现节省成本的机会。这些建议会分析您的 Amazon EC2 资源，并在单一视图中显示成员账户中未充分利用的 EC2 实例，因此您可以确定总体 亚马逊云科技 支出可能节省的费用。

图 2。在 亚马逊云科技 Cost Explorer 中查看合理规模建议

最后， 亚马逊云科技 Trusted Advisor 是另一个很棒的工具，你可以用来寻找成本优化机会。例如，突出显示未充分利用的 Amazon EBS 卷和闲置的 Amazon RDS 数据库实例只是 Tru sted Advisor 可以执行的众多 成本优化检查 之一。Cost Explorer、Rightsizing 建议和 Trusted Advisor 是开始任何成本优化活动的好地方，值得至少每季度查看一次，以减少或阻止 亚马逊云科技 足迹内的浪费。

现在，让我们来看一下三项具体的成本优化修改，它们有可能在一夜之间为您节省10-20％。

对您的亚马逊弹性区块存储 (亚马逊 EBS) 卷进行现代化改造

要节省高达 20% 的亚马逊 EBS 支出，最简单的方法是将 GP2 卷升级到 GP3 卷。除了成本优势外，GP3 卷还使您能够独立于卷存储进行配置 IOPS。这为您提供了另一个调整Amazon EBS卷大小的机会，因为一些运行 GP2 卷的工作负载需要较大的卷大小才能满足 IOPS 要求。此次升级不需要停机，因为您可以使用 Amazon EBS Elastic Volumes，这使您能够调整卷大小、性能和卷类型，而无需分离卷或重启实例。所有 当前一代的实例 都 支持 Amazon EBS 弹性卷。使用这些卷还可以保证您的过渡 卷性能 不会低于源卷性能。

一个简短的例子说明储蓄会是什么样子：

图 3。查看每月从 GP2 交易量过渡到 GP3 交易量后每月和每年可能节省的费用

假设： 150 个独立的 1 TB GP2 卷（3,000 个 IOPS）

结果： 显示每月从 GP2 量过渡到 GP3 交易量后每月和每年可能节省的费用。

交换支持托管服务的底层计算

升级亚马逊 EBS 卷后，是时候优化我们的亚马逊 RDS 和亚马逊 Aurora 占用空间了。亚马逊云科技 托管服务的好处是，亚马逊云科技 提供对云资源或基础设施的部分或全部管理。因此，亚马逊云科技 负责处理软件的性能、维护和可操作性。

基于 亚马逊云科技 Graviton2 的数据库实例可用于亚马逊 Aurora PostgreSQL 兼容版和亚马逊 Aurora MySQL 兼容版。Graviton2 实例还可用于适用于 MySQL 的亚马逊 RDS、适用于 PostgreSQL 的亚马逊 RDS 和适用于 MariaDB 的亚马逊 RDS。这一点值得注意，因为 Graviton2 实例可为 Aurora 提供高达 20% 的性能提升和高达 35% 的性价比提升，具体取决于数据库大小。Graviton2 实例可为 RDS 开源数据库提供高达 35% 的性能提升和高达 52% 的性价比提升。

在实施方面，如果您使用的是支持的 数据库版本，则将 Aurora 数据库实例升级到 Graviton2 需要对实例类型进行简单的修改。这使您的应用程序可以正常运行，无需移植应用程序代码。对于 Amazon RDS，您将导航到 Amazon RDS 控制台，选择您的数据库，然后单击 “修改”。然后，您将选择基于 Gravtion2 的实例来满足您的计算要求。在此修改过程中，服务会短暂中断。默认情况下，修改将在您的下一个预定维护时段内生效。

一个简短的例子说明储蓄会是什么样子：

图 4。查看使用基于 Graviton 的计算每月备份您的 Aurora 和 RDS 数据库可能节省的月度和年度成本

假设： 25 个 Amazon Aurora db.r5.2xlarge 实例和 25 个 MySQL 版 Amazon RDS db.r5.2xlarge 实例

结果： 显示每月使用基于 Graviton 的计算支持 Aurora 和 RDS 数据库可能节省的月度和年度成本。

将基于 Linux 的工作负载迁移到基于 Graviton 的亚马逊 EC2

我们可以节省成本的最后一个地方是分析任何基于 Amazon EC2 Linux 的工作负载和正在使用的特定实例类型。通过利用 亚马逊云科技 定价计算器 ，您可以输入当前的计算需求（内存、vCPU、联网等），以确定性价比更高的实例。

图 5。在 亚马逊云科技 定价计算器中配置 Amazon EC2 实例的示例视图

理想情况下，考虑使用基于 Graviton2 的 Amazon EC2 实例来处理基于 Linux 的工作负载，特别是如果您没有需要基于 x86 的芯片架构的技术依赖关系。下图显示了将任何应用程序移植到 64 位 Arm 处理器所需工作的一般分类。

图 6。该图表按工作负载对 亚马逊云科技 Graviton 采用率的工作水平进行了分类

与当前一代 M5、C5 和 R5 实例相比，亚马逊 EC2 M6g、C6g 和 R6g 实例的性价比最高可提高 40%。以下是这些储蓄可能是什么样子的简短示例：

图 7。查看将基于 Linux 的工作负载迁移到基于 Graviton 的 Amazon EC2 后每月和每年可能节省的费用

假设：

25 x t3.large 实例 25 x
c5.xlarge 实例 25 x
r5.xlarge 实例 25 x m5.2xlarge 实例

成果： 显示通过将基于 Linux 的工作负载迁移到基于 Graviton 的 Amazon EC2 可以节省每月和每年的潜在成本

结论

这些修改可以帮助您优化 亚马逊云科技 成本，而无需引入任何应用程序重新架构、系统重新架构或工程开销。

为了确保对成本进行适当的优先排序，以下是按所需工作顺序进行的拟议更改：

• 将亚马逊 EBS 卷从 GP2 升级到 GP3
• 根据您的数据库引擎，将 Amazon RDS/Amazon Aurora 底层计算交换为基于 Graviton 的实例或最新一代实例
• 迁移现有的基于 Linux 的工作负载，使其在基于 Graviton 64 位 ARM 的亚马逊 EC2 实例上运行。

🗺️ 探索并开始使用： 开始优化 亚马逊云科技 云成本的 关键方法