DynamoDB throttled on a hot partition despite capacity

TL;DR — Your table has plenty of unused RCU/WCU overall, but you're still throttled because a single partition key is hot. Every physical partition has a hard ceiling of ~3,000 RCU** and ~1,000 WCU, regardless of how much capacity the table has. Traffic piled onto one key exhausts that one partition. Spread requests across more distinct partition keys (write-sharding) to fix it.**

What it means

ProvisionedThroughputExceededException: The level of configured provisioned
throughput for the table was exceeded.
# ...yet CloudWatch shows consumed capacity well below provisioned.

DynamoDB spreads a table across many physical partitions, and a table's capacity is divided among them. An individual partition can serve at most ~3,000 read units and ~1,000 write units per second. If your access pattern focuses traffic on one partition key, that key's partition hits its own ceiling and throttles — even though the table-wide metrics look under-utilized. Adaptive capacity helps, but it can't rescue a genuinely unbalanced key.

Why it happens

• Low-cardinality partition key — a status flag, a boolean, a "current date", or a single tenant that receives most traffic.
• A viral / celebrity item — one popular partition key (a trending product, a hot user) draws disproportionate load.
• Time-series with a "today" key — every write lands on the same date-based partition key.
• A sequential or monotonic key so writes cluster on the newest partition.
• A GSI with a low-cardinality partition key, which throttles the base table's writes.

How to fix it

1. Increase key cardinality. Design the partition key so requests spread across many values — this is the single most effective fix.
2. Write-shard the hot key. Append a suffix (USER#42#1…USER#42#N) so one logical entity spans multiple partitions; fan out reads across the shards.
3. Add randomness or a calculated suffix to time-series keys so "today's" writes don't all collide.
4. Cache hot reads (DAX or an application cache) to shed read pressure off the hot partition.
5. Keep exponential-backoff retries — this error is retryable and the SDK backs off by default.
6. Fix low-cardinality GSI keys — a throttled GSI throttles the base table.

Want to inspect key distribution while you redesign? The DynoTable desktop app lets you filter and sort by partition key so an over-loaded key is obvious before you re-shard.

Related errors

• ProvisionedThroughputExceededException — the general throttling error and capacity fixes.
• ThrottlingException — account/control-plane rate limits.
• Learn: Hot partitions · How partition keys work