Provisioned throughput decreases are limited within a given day

TL;DR — DynamoDB 限制你在单个 UTC 天内能多频繁地降低一张表（或 GSI）的预置读/写容量。你已用完额度，因此 UpdateTable 被拒绝。等待每小时的补充、把你的降低合并为更少的更大步骤，或者把表切换到按需模式，从此不再管理降低。

含义

LimitExceededException: Subscriber limit exceeded: Provisioned throughput
decreases are limited within a given UTC day

每张表在一个 UTC 天开始时有一小份容量降低的预算（增加可以按需进行，受账户配额以及 DynamoDB 不允许你过快爬升的约束）。你在一天开始时有 4 次可用的降低，之后每小时再赚 1 次，任意时刻最多 4 次可用——足以在完整的 24 小时天内进行最多 27 次降低。用完它，进一步的 UpdateTable 降低调用会以一个 LimitExceededException（HTTP 400；开发者指南对这个异常的通用消息是 "Too many operations for a given subscriber."）失败，直到预算补充。它是一个配额，因此在同一时间窗口内盲目重试不会有帮助。

为什么会发生

• 自动扩缩抖动——一个尖峰式工作负载让 DynamoDB 自动扩缩反复地把容量往下调，烧掉降低预算。
• 一个过于频繁降低容量的脚本——许多小的降低而不是一个更大的。
• 负载测试期间的手动调优——随着流量退去反复把容量往下调。
• 逐索引预算——表和 GSI 的降低限制是解耦的，因此每个 GSI 有自己的额度；一张带多个索引的表可能在其中一个上触及它。一个同时降低表和 GSI 的单个 UpdateTable 请求，如果任一超过其当前限制，就会被整体拒绝。

如何修复

1. 等待补充。 每小时会有一次降低变为可用（任意时刻最多 4 次可用）；每个 UTC 天开始一份新的 4 次降低预算。
2. 做更少、更大的降低。 一步从 1000 → 200，而不是五个 160 单元的步骤。
3. 调优自动扩缩——提高目标利用率并添加一个缩容冷却，让它停止如此激进地降低。
4. 切换到按需，如果工作负载是突发的或不可预测的：

   aws dynamodb update-table --table-name <Table> \
     --billing-mode PAY_PER_REQUEST

   复制已复制
   按需完全移除了手动容量管理（及其降低配额）。

相关错误

• ProvisionedThroughputExceededException——读/写超过预置容量时的运行时限流。
• LimitExceededException——更宽泛的账户/表控制平面配额族。
• 学习：On-demand vs provisioned

参考资料

• Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide
• UpdateTable — Amazon DynamoDB API Reference
• DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。