Amazon Aurora 定价：运行 Aurora 数据库的意外成本

Amazon 将 Aurora 描述为一个可扩展且易于管理的数据库，但如果你从未使用过“创建数据库”向导，那么这一说法可能不太准确。从实例类型到存储配置，再到监控数据库，有很多需要考虑的因素，这使得 Amazon Aurora 集群的定价并不简单。
本文将详细介绍 Amazon Aurora 的定价模型背后需要考虑的所有细节，帮助你更准确地估算 Aurora 数据库的费用。

注意

本文内容仅适用于 Aurora，而不是 Aurora Serverless。Aurora Serverless 是一种不同的配置，其定价模式与传统 Aurora 有所不同。

什么是 Amazon Aurora

Amazon Aurora 是 AWS 上兼容 MySQL 和 PostgreSQL 的数据库平台，可简化创建和管理 MySQL 数据库的过程。它简化了运行生产环境中 MySQL 数据库所需基础设施的配置，同时提供了许多标准 RDS 配置中没有的功能，例如自动故障转移、只读副本，以及在几乎没有停机的情况下扩展计算和存储资源的能力。
尽管如此，其定价结构并不像看上去那样简单清晰。考虑 Aurora 集群的定价时需要评估许多因素，尤其是在运行 MySQL 工作负载时。下面我们具体分析这些因素。

实例类型

实例类型用于指定分配给底层 MySQL 计算节点的 CPU 和内存资源。
创建 Aurora 集群时，你最先需要选择的就是实例类型。对于没有背景知识的人来说，查看实例类型列表可能会感到困惑。不过，Amazon 采用了一种命名约定，可以用来解读名称的每个部分含义：
Aurora 定价示意图
实例类型的类别和尺寸将对最终费用产生显著影响。例如，下表比较了三个具有相同类别但尺寸不同的实例类型的费用：

实例类型	vCPUs	内存 (GiB)	每小时费用
db.x2g.large	2	32	$0.377
db.x2g.4xlarge	16	256	$3.016
db.x2g.16xlarge	64	1024	$12.064

可突发与内存优化实例

Aurora 的实例类型分为两类：可突发和内存优化。可突发实例因日常负载下使用较少资源而有一定的成本优势，但在较高需求出现时可短时间“突发”以提升性能。这与内存优化实例形成了对比，后者性能稳定并一直满足其所宣传的配置。由于可突发实例的性能相较于内存优化实例不够稳定，Amazon 不推荐将其用于生产环境。

预留实例与按需定价

另一个需要考虑的因素是预付款购买计算节点的使用时段，称为“预留实例”。如果选择预付款购买 1 年或 3 年的预留实例时段，Amazon 会给予按需定价的折扣。折扣金额取决于合同期限和所选实例类型。若你能预估出需要多少实例以及使用时长，预留实例是一种降低 AWS 账单成本的好方法。

副本

为生产环境数据库至少创建一个副本并将该副本与 Aurora 集群连接（放置在不同的可用区 AZ）是最佳实践。副本能够保证主写节点离线时更快速的故障转移，同时在执行需要重启的更新（如调整实例大小或配置参数）时减少停机时间。
因此，对于关键业务场景（任何停机可能导致显著财务损失或声誉风险），你需要考虑将一个主节点与两个副本放置于不同 AZ 中。然而，这种方案将有效地按副本数量增加你选定实例类型的成本，同时也提高了正确地管理副本位置和故障切换编排的运维工作量。

存储配置

在 Amazon Aurora 中，存储的工作方式与 RDS 或基于 EC2 配置自己的数据库集群有所不同。后者依赖于底层的 EBS 卷，提供了多种选择。而 Aurora 使用专有存储设备，自动预划分“块”来存储数据，这种方式允许 Amazon 自动调整存储容量，而无需担心空间不足问题。
因此，存储配置选项仅限于标准存储和 I/O 优化存储两种。
选择标准存储时，你将根据使用的存储量和 IOPS 消耗来收费。而选择 I/O 优化存储则会提高实例类型的费用，但不收取 IOPS 费用。如果你的应用程序 I/O 密集型，则选择 I/O 优化存储可能反而降低总体费用。当 I/O 费用超过 Aurora 账单总成本的 25% 时，通常会出现显著节省。要做出最优选择，你需要充分了解应用的 I/O 需求，因为 Amazon 对两种存储配置均未明确推荐。

数据传输费用

另一个需要考虑的指标是与你的 Aurora 集群之间传输的数据量。Amazon 会为多种场景中的数据传输收费，包括可用区之间的传输、跨区域的传输甚至向公有互联网进行的数据传输。具体收费金额依赖于使用的服务。
有些场景中 Amazon 不收取数据传输费用，例如在同一区域内进行数据复制或在同一可用区内 Aurora 节点与 EC2 实例之间的数据传输。而大多数其它场景都会产生额外的数据传输费用。确保你的应用程序托管区域与它所使用的副本在同一区域内可以帮助降低数据传输费用。

跨区域复制

如果需要跨区域复制数据以接近用户，Global database 是 Aurora 集群的服务名称，它允许在另一个区域创建一个独立的只读 Aurora 集群，进行数据复制。每个区域可以独立扩展，因此根据该区域的计算要求选择合适的实例类型可优化成本。
使用 Global database 还需承担额外费用，首先，你需支付与主区域计算实例和存储相同的费用。此外，Amazon 还会对每 100 万次写操作以及跨区域复制的数据传输收取额外费用。

连接池

每个与 MySQL 数据库的连接都将消耗 CPU 和内存资源。
AWS 提供 RDS Proxy 作为数据库客户端与写节点/读节点计算资源之间的轻量代理层。RDS Proxy 不仅能够实现连接池，还可以帮助更高效地管理计算节点所消耗的资源。在节点故障发生时，RDS Proxy 可更快速地检测故障并将流量重定向到另一个节点，而不会断开客户端连接。
RDS Proxy 是 Aurora 的附加服务，因此会在 AWS 账单上出现额外的费用。

变更管理

对数据库进行的许多更改需要实例重启，此时操作期间将会产生一些停机时间。有些操作，例如调整实例类型，可通过只读副本实现最小的停机时间。
另一个减少停机时间的选项是蓝绿部署（blue/green deployment），即创建一个新的完全相同的环境，在应用变更后将流量重新定向至新环境。Amazon 推荐使用蓝绿部署进行各种数据库配置变更，例如版本更新或架构修改。重新定向流量的过程称为切换（switchover），尽管所有连接仍会在切换期间中断，但与直接操作集群相比停机时间更短。

注意

要了解更多关于蓝绿部署的信息，请查看我们关于 Aurora 和 PlanetScale 分支比较的文章。
创建蓝绿部署时，你将设置一个完全相同的在线环境。这意味着在两个环境在线期间，你的计算成本（选定的实例类型和副本数量）会翻倍。此外，切换完成后 Amazon 不会自动删除旧环境，你必须手动移除它以避免费用异常增加。

备份

备份是灾难恢复计划的重要组成部分，应在数据库定价时优先考虑。通过自动备份功能，你将根据使用的存储量（以 GB 计）收费，并减去数据库最新的大小。因此，你可以免费获得一个完整备份，但对于任何后续增量备份，将会收取费用。你还可以配置备份的保留时长，超出时将被自动删除。
此外，你还可以选择手动创建数据库的快照。这些快照不属于自动化系统，即使数据库被删除，它们仍会保留。手动快照的收费基于快照大小，不包含在免费的自动备份中。

监控

监控 Aurora 数据库可以采用许多不同的解决方案。
默认情况下，Amazon Aurora 每分钟会向 CloudWatch 发送一系列广泛的指标，包括集群和每个单独实例的指标，且不额外收费。指标内容涵盖活动事务数量到副本之间复制时间等信息。所有默认指标过于繁多，详细列表可查看 Amazon 的文档。
如果需要实时信息，可以使用 Enhanced Monitoring 服务作为附加功能。Enhanced Monitoring 使用 CloudWatch Logs，这些日志会根据每月发送到 CloudWatch 的数据量收费。费用可能因集群不同差异显著，但可以提供更为详细的数据分析所需的信息。
此外，Performance Insights 允许从实际的数据库引擎中收集数据，例如数据库负载和查询性能。这项服务的收费基于数据保留时间，最长可保留两年。前七天不额外收费，但针对超过七天的数据保留则会产生费用。

与 PlanetScale 的对比

在详细分析创建 Aurora 集群时需考虑的各种成本后，让我们看一下 PlanetScale 如何应对相同领域需求以及其定价方式。

实例类型

在创建 PlanetScale 数据库时，我们也会要求你选择实例类型。然而，与 Aurora 的复杂选择不同，我们将实例类型的选择显著简化。我们没有可突发与内存优化的概念，同时在选择实例类型时会直接显示 CPU、内存分配和价格。以下是 AWS us-east-1 区域创建 PlanetScale Scaler Pro 数据库的定价表：
PlanetScale 创建数据库的价格表
此外，显示的每种类型实际上都是一个 MySQL 集群的配置。我们遵循所有数据库的最佳实践，包括将你的数据跨三个可用区复制。

存储配置

PlanetScale 的存储配置也简化了，所有网络连接的实例类型均采用统一存储配置。而在 PlanetScale Metal 配置中，你可以根据具体工作负载选择合适的存储大小。
Metal 的一个最大优势是性能改进。你不需要在 PlanetScale 中购买 Aurora 专属的 I/O 优化计划。Metal 实例默认提供了无限制的 IOPS。此外，与等效的 Aurora I/O 优化工作负载相比，你可能会节约资金。

数据传输

PlanetScale 不会收取任何数据传输费用。唯一的例外是 PlanetScale Managed 配置，在这种情况下，PlanetScale 会部署在你的 AWS 组织中的子账户中。然后，你将按照 Aurora 数据库的标准支付 AWS 的数据传输费用。

跨区域复制

PlanetScale 提供了创建只读区域的功能，可以将数据复制到靠近应用服务器的选定区域。这与 Aurora 的 Global database 非常类似，但无需支付数据传输费用，同时你仍可以获得与所选实例类型完全相同的 MySQL 集群资源。

连接池

PlanetScale 的 PostgreSQL 集群使用 PgBouncer 进行连接池管理和自动故障切换。
同时，PlanetScale 提供了完全托管的 Vitess 集群——一种最初由 YouTube 开发的数据库集群系统，用于解决 2010 年的扩展问题。这使得我们能够利用 Vitess 提供的连接池和负载均衡功能。
Vitess 中管理所有 MySQL 集群连接的核心组件是 vtgate，一种轻量级代理，它负责将流量路由到集群中的正确 MySQL 节点。vtgate 类似于 RDS Proxy，能够通过 MySQL 协议与所有节点管理连接，减少每个节点的资源消耗，同时与我们的拓扑服务沟通以确定流量的路由方式。在分片配置中，当查询的目标数据分布在多个分片节点中时，它还将拆分查询并向正确节点发送。
由于 vtgate 是 Vitess 的核心组件，PlanetScale 支持几乎无限数量的连接，同时运行 PlanetScale 数据库的成本中已包含这项服务。

变更管理

与 Aurora 相比，PlanetScale 的管理显著优化。Aurora 需要你创建蓝绿部署，这增加了复杂度和成本（并且在进行变更时可能导致客户端中断）。PlanetScale 的许多蓝绿部署适用场景均由平台或工程团队自动化处理。
例如，当发布新的 MySQL 版本时，我们的工程师会严格测试版本的稳定性，以确保其能够在 PlanetScale 基础设施上运行。对于实例类型变更，我们利用 Kubernetes 运行的容器化计算节点进行滚动升级，将新的实例类型副本添加至你的集群，完成数据复制并通过 vtgate 重新路由流量。这一流程完全自动化且无需停机。
对于架构更新，PlanetScale 用户可以利用数据库分支（如开发分支）和部署请求机制实现。分支是一个完全隔离的 MySQL 集群，包含上游分支的架构副本。你可以在这个分支上应用并测试架构变更，随后通过合并请求将变更应用到上游分支，而无需离线来完成操作。分支运行时资源消耗非常少，因此不会显著增加运营成本。

通过这种方式，PlanetScale 显著简化了变更和管理流程，同时避免了生产停机。由此造成的成本增加远低于 Aurora 的方案。