DynamoDB 按需与预置容量
DynamoDB 用两种方式为吞吐量计费。按需模式按请求收费 —— 你用多少付多少，可缩容到零。 预置模式则预留一个固定的读/写速率，无论你用不用都要为之付费，但每单位价格要低得多。 选错那一个，是最容易多花钱的方式之一。
审计日志让这个选择变得具体。审计写入是突发且难以预测的：夜里安静，然后当某个客户运行 一次批量操作或一起事故生成数千个事件时，便涌来一阵洪流。那种流量形态就是这整个决策本身。
我应该使用 DynamoDB 按需容量还是预置容量？
按需模式按请求计费，可缩容到零，是应对突发、新建或流量不可预测场景的安全默认选择。预置模式以低得多的单价预留固定的读/写速率，仅在持续稳定的流量能让预留保持高利用率时才有优势。除非你的流量已经过验证且可预测，否则请选择按需。
- 按需 = 按请求付费，可缩容到零。 无需规划容量；你为每次读/写支付更高的价格，但只在流量 实际发生时才付。
- 预置 = 预留一个稳定的速率，且始终为之付费。 如果该速率利用得当，每单位会便宜得多；空闲 容量的成本由你承担。
- 突发 / 未知流量 → 按需。 稳定、可预测、高吞吐量的流量 → 预置（可选配自动伸缩）。
- 你可以切换模式，但每 24 小时只能切换有限次数 —— 它不是一个逐请求的开关。
问题所在：为你用不到的容量付费
使用预置容量，你要承诺，比如说，每秒 1000 个写入单元。如果审计日志平均每秒 50 次写入，而你 为事故日的峰值做了预置，那么你就在全天候为 1000 付费，却只用到其中的二十分之一。改为按平均 值预置，事故日的洪流就会被限流 —— 写入会被拒绝。
所以固定容量在突发流量上逼你做一个糟糕的取舍：要么持续多付钱，要么预置不足、在最要紧的时候 丢弃写入。按需模式之所以存在，正是为了消除这个取舍。
两种模式如何工作
按需模式为你实际消耗的读取和写入请求单元收费，无需配置任何容量 —— 它能瞬时容纳流量峰值， 并在空闲时缩容到零。你为这份弹性按请求支付一份溢价。
预置模式预留每秒一定数量的读取容量单元（RCU）和写入容量单元（WCU）。每单位价格要低得多， 但无论用不用，你都要持续为这份预留付费。超出它，DynamoDB 就会限流，除非启用了自动伸缩 以在配置的边界内扩容 —— 不过自动伸缩以分钟为级别做出反应，所以一次骤然的峰值在它追上之前 仍可能被限流。
临界点在于利用率。粗略地说：如果你持续、可预测的流量能让预置容量保持高利用率，预置在价格上 胜出；如果流量是突发、爆发或未知的，按需则凭借不为空闲预留收费而胜出。
一个实战示例：审计日志的账单
审计日志平均每秒写入约 50 个事件，但在事故期间会爆发到数千次，读取流量则低得多（合规导出、 偶尔的调查）。每个事件都很小 —— 远低于 1 KB。
在预置模式下，你要么为爆发做预留（全天候为之付费），要么冒着在事故日洪流中被限流的风险 —— 而那正是丢弃审计写入最糟糕的时刻。在按需模式下，安静时段几乎不花钱，爆发则被自动吸收；你 恰好为实际发生的那些写入付费。
对于这种工作负载，按需是正确的默认选择。一般规则是：任何新表或突发的表都从按需开始，只有 当流量被证明足够稳定、能让预留保持利用率时，才迁移到预置。
把你自己的数字填进去 —— 每秒读/写、项大小、存储 —— 即可针对一个区域并排查看两种模式：
要看应用了免费套餐的完整多区域全貌，请使用 DynamoDB 定价计算器。
在 DynoTable 中操作
容量决策从真实的数字出发：项有多大、有多少个、被写入得有多快。靠猜测这些，正是表最终被错误 预置的原因。
要把一个样本事件换算成它实际消耗的 RCU/WCU，就用项大小计算器 跑一遍。然后把决策落地到你的真实表上：DynoTable 会展示表的元数据 —— 项的数量和大小 —— 并让你 检查有代表性的项，从而准确地估量它们。
坑与后续步骤
- 切换模式受速率限制。 你可以在按需和预置之间切换，但每 24 小时只能切换有限次数 —— 把它 当作一个深思熟虑的决定，而不是一个随手乱拨的旋钮。
- 自动伸缩不是瞬时的。 它以分钟为级别做出反应，所以预置模式上一个陡峭的峰值在容量扩容 之前就可能被限流。对于真正突发的流量，按需模式会直接吸收峰值。
- 一个热点分区无论哪种模式都会被限流。 即便是按需也有每分区的上限 —— 不均匀的键可能会 在表看起来容量充裕时被限流。参见热点分区。
- GSI 有自己的容量。 每个索引单独计费，如果预置不足，可能会限流基础表写入 —— 参见 为什么一个 GSI 会限流基础表写入。
容量模式决定了你在一个区域运行这张表要付什么。接下来：用 DynamoDB Global Tables 把它跨区域复制。
下载 DynoTable，在你确定一种容量模式之前读取你表的真实大小和项数量。