DynamoDB throttled on a hot partition despite capacity

TL;DR — Deine Tabelle hat insgesamt reichlich ungenutzte RCU/WCU, wird aber trotzdem gedrosselt, weil ein einzelner Partition Key heiß ist. Jede physische Partition ist auf höchstens 3.000 Read Units und 1.000 Write Units pro Sekunde ausgelegt, egal wie viel Kapazität die Tabelle hat. Traffic, der sich auf einen Schlüssel türmt, erschöpft genau diese eine Partition. Verteile Requests auf mehr unterschiedliche Partition Keys (Write-Sharding), um das zu beheben.

Was es bedeutet

ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.
# ...yet CloudWatch shows consumed capacity well below provisioned.

DynamoDB verteilt eine Tabelle über viele physische Partitionen, und die Kapazität einer Tabelle wird unter ihnen aufgeteilt. Eine einzelne Partition ist darauf ausgelegt, höchstens 3.000 Read Units und 1.000 Write Units pro Sekunde zu liefern — in beiden Kapazitätsmodi. Wenn dein Zugriffsmuster den Traffic auf einen Partition Key fokussiert, erreicht die Partition dieses Schlüssels ihre eigene Obergrenze und drosselt — obwohl die tabellenweiten Metriken unterausgelastet aussehen (die ThrottlingReason-Felder des Fehlers, z. B. TableReadKeyRangeThroughputExceeded, benennen das genau erreichte Limit). Adaptive Kapazität hilft, kann aber einen wirklich unausgeglichenen Schlüssel nicht retten.

Warum es passiert

Partition Key mit geringer Kardinalität — ein Status-Flag, ein Boolean, ein „aktuelles Datum" oder ein einzelner Mandant, der den meisten Traffic erhält.
Ein virales / Promi-Item — ein beliebter Partition Key (ein Trendprodukt, ein heißer Nutzer) zieht überproportionale Last.
Zeitreihe mit einem „heute"-Schlüssel — jeder Schreibvorgang landet auf demselben datumsbasierten Partition Key.
Ein sequentieller oder monotoner Schlüssel, sodass sich Schreibvorgänge auf der neuesten Partition häufen.
Ein GSI mit einem Partition Key geringer Kardinalität, der die Schreibvorgänge der Basistabelle drosselt.

So behebst du es

Erhöhe die Schlüsselkardinalität. Gestalte den Partition Key so, dass sich Anfragen über viele Werte verteilen — das ist die mit Abstand wirksamste Lösung.
Write-Sharde den heißen Schlüssel. Hänge ein Suffix an (USER#42#1…USER#42#N), sodass eine logische Entität mehrere Partitionen umspannt; fächere Lesevorgänge über die Shards auf.
Füge Zufälligkeit oder ein berechnetes Suffix zu Zeitreihen-Schlüsseln hinzu, damit die Schreibvorgänge von „heute" nicht alle kollidieren.
Cache heiße Lesevorgänge (DAX oder ein Anwendungscache), um Lesedruck von der heißen Partition zu nehmen.
Behalte Retries mit exponentiellem Backoff bei — dieser Fehler ist wiederholbar und das SDK wartet standardmäßig ab.
Behebe GSI-Schlüssel mit geringer Kardinalität — ein gedrosselter GSI drosselt die Basistabelle.
Prüfe ThrottlingReason im Fehler. Es nennt, ob das Limit tabellenweit oder auf einen Schlüsselbereich bezogen war.

Größe in DynoTable prüfen

Find the hot partition key — öffne die Tabelle mit ⌘K, sort by partition key, and look for one key carrying far more items than neighbors. Filter to that key and inspect write patterns bevor du re-shard.

Model write-shard suffixes in the Query Builder and estimate retry traffic with the Pricing-Rechner. Wechsle Profile mit ⌘P; see Mit AWS verbinden and Installation.

Quellen

Best practices for designing partition keys (verifiziert 2026-07-13)
Troubleshooting throttling in Amazon DynamoDB (verifiziert 2026-07-13)

FAQ

Warum drosselt DynamoDB mich, wenn die Tabelle freie Kapazität hat? Weil ein einzelner Partition Key heiß ist. Jede physische Partition hat eine Obergrenze von etwa 3.000 Read Units und 1.000 Write Units pro Sekunde, unabhängig von der Kapazität auf Tabellenebene, sodass Traffic, der auf einen Schlüssel aufgetürmt wird, diese eine Partition erschöpft, während die tabellenweiten Metriken unterausgelastet aussehen.

Wie behebe ich eine heiße Partition in DynamoDB? Erhöhe die Partition-Key-Kardinalität, sodass sich Anfragen über viele Werte verteilen, write-sharde den heißen Schlüssel mit einem Suffix, füge Zeitreihen-Schlüsseln ein berechnetes Suffix hinzu und cache heiße Lesevorgänge. Retries mit exponentiellem Backoff helfen, kurze Spitzen zu überstehen, beheben aber keinen unausgeglichenen Schlüssel.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.