DynamoDB 能自动扩缩吗？
能。DynamoDB 自动扩缩使用 Application Auto Scaling，把预置的读写容量朝一个目标利用率（可设 20–90%，常用 70%）调整，并限制在你定义的最小/最大范围内。另一种做法是按需容量模式，它零配置地即时随流量伸缩。两者都能让表跟上变化的负载，而不必手工做容量规划。
预置容量的自动扩缩
你为每张表（以及每个全局二级索引）创建一条扩缩策略，其中设定：
- 一个目标利用率（要瞄准的预置容量百分比）、
- 容量单元的最小值和最大值，以及
- 要扩缩读、写还是两者都要。
当消耗量越过目标时，CloudWatch 告警会触发 Application Auto Scaling 提高或降低容量。
按需模式
按需容量彻底免去了规划：DynamoDB 会自己把吞吐量调整到你的流量上——瞬时可承接至多为你此前流量峰值两倍的量——并按请求计费。当流量突发或难以预测时，它很合适。
该选哪个
流量稳定且你很了解它时，带自动扩缩的预置容量通常更便宜；面对未知或突发的流量，按需更简单也更合适。
目标利用率在哪里就不划算了
目标利用率是一个价格旋钮，而它有一条下限，低于这条线自动扩缩就完全输给按需模式了。
在 us-east-1，一个写容量单元每小时 0.00065 美元，所以预留一个月要 0.4745 美元，能买到 2,628,000 次写入。这相当于每次写入 0.00000018 美元，而按需是每次 0.000000625 美元，也就是说在每一个预留单元都被用满时，预置容量便宜 3.46 倍。反过来算就得到盈亏平衡点：平均利用率低于 28.9% 时，预置容量就不划算了。读取算出来同样是 28.9%，所以这是定价模型的性质，而不是某一个费率造成的巧合。
以持续每秒 1,000 次、每个项目 1 KB 的写入为例，用定价计算器算价：
| 容量设置 | 预置 | 每月 |
|---|---|---|
| 90% 目标 | 1,112 WCU | $527.64 |
| 70% 目标 | 1,429 WCU | $678.06 |
| 50% 目标 | 2,000 WCU | $949.00 |
| 20% 目标 | 5,000 WCU | $2,372.50 |
| 按需 | 无 | $1,642.50 |
教训在最后两行。20% 的目标是 AWS 接受的最低值，它预留了你流量的五倍，而做同样的活儿却比按请求付费贵 44%。上面每一行都假定自动扩缩把容量精确地钉在目标上，所以请把它们当作最好情况：真实流量会四处游走，而算法总是慢一拍地跟着它走，这会把实际达成的利用率拖到你配置的数值以下。
这个旋钮买到了什么
扩容和缩容是刻意不对称的，而这份余量买的正是这种不对称。AWS 文档写明：消耗容量连续两分钟越过目标后触发扩容，连续 15 个数据点低于目标后触发缩容。随后的 UpdateTable 调用还要再花上几分钟，而在这期间超过旧上限的请求都会被限流。
降容也是配额制的。每个 UTC 日开始时你有四次，每小时再赚一次，但手里最多只能攥着四次，因此每张表每天上限是 27 次。全局二级索引另有自己的额度。
所以高目标值能省下真金白银，代价是花掉那份用来覆盖上述几分钟的缓冲。按需模式每次请求更贵，但把这道取舍整个拿掉了。
深入了解
在按需 vs 预置容量里对比两者，并用定价计算器估算成本。下载 DynoTable，在表统计中查看一张表的大小和条目估算值。
参考资料
- Managing throughput capacity automatically with DynamoDB auto scaling — Amazon DynamoDB Developer Guide
- DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide
- DynamoDB provisioned capacity mode — Amazon DynamoDB Developer Guide
- Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide——降容额度，于 2026-07-28 重新核对。
最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。
盈亏平衡点于 2026-07-28 用我们自己的定价计算器计算，费率取自它从 AWS Price List API 同步的 us-east-1 数据。扩缩延迟和降容额度于同日从上方链接的 AWS 文档中重新读取。