DynamoDB ProvisionedThroughputExceededException

TL;DR — Du liest/schreibst schneller, als die Tabelle oder der Index bedienen kann. Stelle die Tabelle auf On-Demand-Kapazität um, erhöhe die provisionierten RCU/WCU (oder aktiviere Auto-Scaling), behalte die standardmäßigen exponentiellen Backoff-Retries des SDK und verteile den Traffic, damit nicht ein Partition Key heiß wird.

Was es bedeutet

ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.

Auf einer Tabelle mit provisionierter Kapazität hast du die Read-/Write-Kapazitätseinheiten überschritten — entweder insgesamt oder (häufiger) auf einer einzelnen Partition. Es ist ein HTTP 400, aber anders als eine ValidationException ist er wiederholbar: Die AWS-SDKs wiederholen ihn automatisch mit exponentiellem Backoff, sodass gelegentliche normal sind. Anhaltende bedeuten echte Unterversorgung oder einen heißen Schlüssel. Der Fehler trägt ThrottlingReason-Felder (z. B. TableReadProvisionedThroughputExceeded) plus die ARN der betroffenen Ressource, sodass du erkennst, welche Tabelle oder welcher Index gedrosselt hat und bei welchem Operationstyp.

Warum es passiert

Unterversorgte Kapazität für den tatsächlichen Traffic.
Eine Hot Partition — Traffic konzentriert sich auf einen Partition Key, sodass der Kapazitätsanteil einer einzelnen Partition erschöpft ist, während die Tabelle insgesamt unterausgelastet aussieht.
Sprunghafter Traffic schneller, als Auto-Scaling reagieren kann — es passt die Kapazität als Reaktion auf Metriken zur verbrauchten Kapazität an, sodass eine plötzliche Sprungänderung drosselt, bevor die Hochskalierung greift.
Ein großer Scan oder Bulk-Import, der die gesamte Kapazität auf einmal verbraucht.
Ein GSI, dessen Kapazität niedriger ist als die Schreibrate — ein gedrosselter GSI drosselt die Basistabelle.

So behebst du es

Wechsle zu On-Demand-Kapazität, wenn der Traffic unvorhersehbar ist — sie skaliert automatisch und dieser Fehler verschwindet praktisch (du zahlst stattdessen pro Anfrage).
Erhöhe die provisionierten RCU/WCU oder aktiviere Auto-Scaling mit einer vernünftigen Ziel-Auslastung, wenn du bei provisioniert bleibst.
Behalte exponentielle Backoff-Retries — das SDK macht das standardmäßig; deaktiviere es nicht. Nutze den Adaptive-Retry-Modus für sprunghafte Workloads.
Behebe die Hot Partition — erhöhe die Schlüssel-Kardinalität / verteile den heißen Schlüssel per Write-Sharding, damit sich die Last über Partitionen verteilt.
Drossle Bulk-Jobs und cache heiße Reads (DAX oder ein App-Cache), um Lesedruck abzubauen.

FAQ

Wie behebe ich ProvisionedThroughputExceededException? Du liest oder schreibst schneller, als die Tabelle oder der Index bedienen kann. Stelle die Tabelle auf On-Demand-Kapazität um, erhöhe die provisionierten RCU/WCU (oder aktiviere Auto-Scaling), behalte die standardmäßigen exponentiellen Backoff-Retries des SDK und verteile den Traffic, damit ein einzelner Partition Key nicht heiß wird.

So reproduzierst du es

Stelle eine Tabelle mit 1 RCU bereit, lege ein Item knapp unter 4 KB ab und lies es dann in einer engen Schleife stark konsistent zurück:

import boto3
ddb = boto3.client('dynamodb', region_name='us-east-1')
# table created with ProvisionedThroughput={'ReadCapacityUnits': 1, 'WriteCapacityUnits': 1}
ddb.put_item(TableName='my-table', Item={'pk': {'S': 'A'}, 'blob': {'S': 'x' * 3500}})
while True:
    ddb.get_item(TableName='my-table', Key={'pk': {'S': 'A'}}, ConsistentRead=True)

Echte Ausgabe:

ProvisionedThroughputExceededException: The level of configured provisioned throughput for the table was exceeded. Consider increasing your provisioning level with the UpdateTable API.
HTTP 400

Es brauchte 49 Reads, um ihn auszulösen, auf einer frisch erstellten Tabelle mit deaktivierten SDK-Retries. Diese Zahl ist der interessante Teil: Eine 1-RCU-Tabelle scheitert nicht bei der zweiten Anfrage, denn DynamoDB leiht dir zuerst angesammelte Burst-Kapazität — ein Lasttest, der früh abbricht, meldet also eine Tabelle als gesund, die es nicht ist. Die andere Hälfte der Illusion ist das SDK, das gedrosselte Anfragen standardmäßig für dich wiederholt; deaktiviere Retries wie oben, sonst bleibt dieser Fehler unsichtbar, bis er stattdessen ein Latenzproblem ist.

Referenzen

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

Am 2026-07-26 gegen den Live-DynamoDB-Dienst in us-east-1 via boto3 1.43.56 reproduziert, auf einer mit 1 RCU bereitgestellten Tabelle bei deaktivierten SDK-Retries — die Ausgabe oben ist wortgetreu.