Provisioned throughput decreases are limited within a given day

TL;DR — DynamoDB limits how often you can decrease a table's (or GSI's) provisioned read/write capacity in a single UTC day. You've used the allowance, so UpdateTable is rejected. Wait for the hourly refill, batch your decrease into fewer larger steps, or switch the table to on-demand and stop managing decreases entirely.

What it means

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

Each table starts a UTC day with a small budget of capacity decreases (increases can be made as often as necessary, subject to account quotas and DynamoDB not letting you ramp up too rapidly). You begin the day with 4 decreases available, and earn 1 more each hour up to a maximum of 4 available at any time — enough for up to 27 decreases across a full 24-hour day. Exhaust it and further UpdateTable decrease calls fail with a LimitExceededException (HTTP 400; the developer guide's generic message for this exception is "Too many operations for a given subscriber.") until the budget refills. It's a quota, so blindly retrying won't help within the same window.

Why it happens

Auto-scaling flapping — a spiky workload makes DynamoDB auto-scaling step capacity down repeatedly, burning the decrease budget.
A script that lowers capacity too often — many small decreases instead of one larger one.
Manual tuning during load tests — repeatedly dialing capacity down as traffic ebbs.
Per-index budgets — table and GSI decrease limits are decoupled, so each GSI has its own allowance; a table with several indexes can hit it on one of them. A single UpdateTable request that decreases both the table and a GSI is rejected whole if either exceeds its current limit.

How to fix it

Wait for the refill. One decrease becomes available each hour (up to 4 available at any time); a fresh 4-decrease budget starts each UTC day.
Make fewer, bigger decreases. Drop from 1000 → 200 in one step instead of five 160-unit steps.
Tune auto-scaling — raise the target utilization and add a scale-in cooldown so it stops decreasing so aggressively.
Switch to on-demand if the workload is bursty or unpredictable:
```
aws dynamodb update-table --table-name <Table> \
  --billing-mode PAY_PER_REQUEST
```
On-demand removes manual capacity management (and its decrease quota) altogether.

ProvisionedThroughputExceededException — the runtime throttle when reads/writes exceed provisioned capacity.
LimitExceededException — the broader account/table control-plane quota family.
Learn: On-demand vs provisioned

References

Last verified 2026-07-13 against the official AWS documentation linked above.