DynamoDB RequestLimitExceeded

TL;DR — Du hast ein Request-Rate-Kontingent auf Konto-/Tabellenebene überschritten, nicht die eigene provisionierte Kapazität einer Tabelle. On-Demand-Tabellen haben standardmäßig 40.000 Read Request Units und 40.000 Write Request Units pro Sekunde. Behalte die Backoff-Retries des SDK, erhöhe das Kontingent in Service Quotas, wenn der Traffic echt ist, und verteile die Last, damit nicht eine einzelne Tabelle/Partition der Engpass ist.

Was es bedeutet

RequestLimitExceeded: Throughput exceeds the current throughput limit for your
account. To request a limit increase, contact AWS Support.

RequestLimitExceeded ist eine der drei Throttling-Exceptions, die DynamoDB auf der Data Plane zurückgibt (neben ProvisionedThroughputExceededException und ThrottlingException). Sie signalisiert, dass du ein Service-Kontingent auf Kontoebene erreicht hast — etwa das Durchsatzkontingent pro Tabelle für On-Demand-Tabellen — statt einer provisionierten RCU/WCU-Obergrenze pro Tabelle. Sie gibt HTTP 400 zurück und ist wiederholbar — die SDKs warten automatisch und wiederholen. Der Fehler trägt ThrottlingReason-Felder (z. B. TableWriteAccountLimitExceeded oder IndexReadAccountLimitExceeded) plus die ARN der betroffenen Ressource.

Warum es passiert

Standard-Obergrenze von On-Demand-Tabellen — jede On-Demand-Tabelle (und jeder ihrer GSIs) hat ein anpassbares Standardkontingent von 40.000 Read Request Units und 40.000 Write Request Units pro Sekunde. Anhaltender Verbrauch darüber hinaus drosselt mit ThrottlingReasons auf Kontoebene, bis das Kontingent erhöht wird.
Die Tabelle kann unter dem Kontokontingent nicht weiter skalieren — laut AWS-Dokumentation überschreitet die Rate der On-Demand-Requests den erlaubten Kontodurchsatz "and the table cannot be scaled further". Diese Kontingente sind Sicherheitsvorkehrungen und können erhöht werden.
Eine neu auf On-Demand umgestellte Tabelle beim Aufwärmen — eine frische On-Demand-Tabelle (oder eine gerade auf On-Demand umgestellte) bedient sofort bis zum Doppelten ihres vorherigen Spitzenwerts; ein deutlich größerer Ausschlag darüber hinaus kann drosseln, bevor sie skaliert.
Eine einzelne heiße Tabelle, die einen Traffic-Ausschlag weit über ihren jüngsten Spitzenwert absorbiert.

So behebst du es

Lass exponentielle Backoff-Retries an — der SDK-Standard bewältigt vorübergehende Ausschläge. Nutze den Adaptive-Retry-Modus für sprunghafte Workloads. Deaktiviere Retries nicht.
Erhöhe das Kontingent — beantrage in Service Quotas eine Erhöhung des On-Demand-Durchsatzes pro Tabelle (oder des Konto-Tabellenanzahl-/Durchsatzkontingents), wenn der Traffic legitim und anhaltend ist.
Wärme vor einem bekannten Ausschlag vor — fahre den Traffic hoch, statt direkt zum Spitzenwert zu springen, damit die On-Demand-Skalierung der Nachfrage vorausbleibt.
Verteile die Last — sharde heiße Schlüssel und verteile Writes, damit nicht eine Tabelle/Partition den ganzen Ausschlag trägt (Hot-Partition-Muster).
Cache heiße Reads (DAX oder ein App-Cache), um Lesedruck unter die Obergrenze zu bringen.

FAQ

Wie unterscheidet sich RequestLimitExceeded von ProvisionedThroughputExceededException? ProvisionedThroughputExceededException bedeutet, dass eine Tabelle mit provisionierter Kapazität ihre eigenen konfigurierten RCU/WCU überschritten hat. RequestLimitExceeded bedeutet, dass du ein Request-Rate-Kontingent auf Konto- oder Tabellenebene erreicht hast — meist das On-Demand-Standardlimit von 40.000 Read und 40.000 Write Request Units pro Sekunde — unabhängig von der Einstellung einer einzelnen Tabelle.

Ist RequestLimitExceeded wiederholbar? Ja. Es ist ein Throttling-Fehler und die AWS-SDKs wiederholen ihn automatisch mit exponentiellem Backoff. Anhaltende Vorkommnisse bedeuten, dass du eine Kontingenterhöhung brauchst oder die Last verteilen musst, nicht mehr Retries.

Referenzen

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