Aurora Serverless v2：当 “I/O Optimized” 实际上让你付出更多成本

Source: Dev.to

请提供您希望翻译的完整文本内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。谢谢！

请求

“我们已经使用 Aurora I/O Optimized 运行了几个月。我们能通过转换回 Standard 来省钱吗？”

我们启用了 I/O Optimized，因为 “Free IOPS” 的承诺对我们高流量工作负载来说听起来非常完美。缺乏最近的验证，我们只能盲目操作。

我的第一步是检查回退是否会影响性能。我查阅了 AWS 文档，确认在 Standard 与 I/O Optimized 之间切换 不会 更改底层硬件——这纯粹是计费配置的区别。

定价比较 (eu‑west‑1)

数学看起来很简单：我们实际上消耗了足够的 IOPS 来证明我们为计算和存储支付的溢价是合理的吗？

CloudWatch 陷阱

我写了一个简短的 Python 脚本（使用 boto3）来从 CloudWatch 拉取指标，并使用 30 天的 “Average” 统计计算 ServerlessDatabaseCapacity (ACUs)。

# Example snippet – not the full script
import boto3

client = boto3.client('cloudwatch')
response = client.get_metric_statistics(
    Namespace='AWS/RDS',
    MetricName='ServerlessDatabaseCapacity',
    Dimensions=[{'Name': 'DBClusterIdentifier', 'Value': 'my-cluster'}],
    StartTime=datetime.utcnow() - timedelta(days=30),
    EndTime=datetime.utcnow(),
    Period=300,
    Statistics=['Average']
)

结果： 计算不准确。Aurora Serverless 按秒级进行扩缩容。如果数据库在 30 秒内突升至 60 ACU 然后下降，AWS 计费引擎会精确捕获这部分费用。而 CloudWatch 会在 1‑5 分钟的窗口内对突升进行平均，平滑数据，使使用量看起来比实际更低（也更便宜）。

经验教训： 切勿使用 CloudWatch 的平均值进行计费核算。CloudWatch 是监控工具，而不是计费工具。

混合方法：10 天快照

由于 CloudWatch 的平均值不可靠且 AWS Cost Explorer 只能提供 14 天的细粒度数据，我设计了一种“10 天快照”方法：

1. 确定一个具有代表性的 10 天窗口（例如 Dec 11 – Dec 20）。
2. 使用 Cost Explorer 获取该窗口内 Compute（ACU）的精确计费金额。
   • 按 Usage Type: EU-Aurora:ServerlessV2IOOptimizedUsage (ACU‑Hr) 进行过滤（因为我们使用的是 Optimized）。
   • 将特定的 DB 集群选为资源。
3. 从 CloudWatch 收集相同窗口的存储和 I/O 数据。

从 CloudWatch 拉取存储 & I/O 的步骤

1. 导航到 Metrics → AWS/RDS → DBClusterIdentifier。
2. 选择集群（例如 client-db-01）。
3. 选择指标：
   • VolumeBytesUsed（存储）
   • VolumeReadIOPS（读取 I/O）
   • VolumeWriteIOPS（写入 I/O）
4. 设置时间范围 为精确的 10 天窗口（Custom → Absolute）。
5. 配置计算方式：
   • 存储： Statistic = Average；使用表达式 m1/1024/1024/1024 将字节转换为 GB。
   • I/O： Statistic = Sum；使用表达式 m2 + m3 将读取和写入 IOPS 合并。
6. 周期： 设置为覆盖整个窗口的单一值（例如 864000 seconds ≈ 10 days），使 CloudWatch 返回一个数字而不是折线图。

现在我们已经获得了 10 天期间总 I/O、存储和消耗的 ACU 的精确数值。

成本情景

所有计算均基于 10 天快照；(10/30) 因子将月度存储费率缩放到 10 天窗口。

判决

结果令人震惊：我们在每一个集群上都支付了过高的费用。我们随即安排了维护窗口，并将所有集群恢复为 Aurora Standard。

验证表明，虽然 “Optimized” 听起来更好，但有时 “Standard” 才是真正为预算保驾护航的英雄。如果你当前正在使用 I/O Optimized，请进行一次 10‑day snapshot 并检查你的存储成本——你可能会对发现感到惊讶。