DynoTable

DynamoDB LimitExceededException

TL;DR — Du hast zu viele Control-Plane-Operationen auf einmal ausgelöst (oder ein Tabellen-/Kontolimit erreicht). Über dein ganzes Konto hinweg dürfen höchstens 500 Tabellen und Indizes gleichzeitig im Status CREATING/UPDATING/DELETING sein. Serialisiere deine Tabellenoperationen, warte auf ACTIVE und wiederhole mit Backoff.

Was es bedeutet

LimitExceededException: Too many operations for a given subscriber.

Das ist ein Control-Plane-Fehler — er kommt von CreateTable, UpdateTable, DeleteTable, Index-Erstellung, Restores und ähnlichen Aufrufen, nicht von GetItem/PutItem/Query. DynamoDB sagt dir, dass du ein Nebenläufigkeits- oder Kontolimit überschritten hast. Es ist ein HTTP 400, und AWS listet es als wiederholbar — die Bedingung klärt sich, sobald in Bearbeitung befindliche Operationen abgeschlossen sind.

Warum es passiert

  • Zu viele gleichzeitige Tabellen-/Index-Operationen — die kumulierte Anzahl an Tabellen und Indizes im Status CREATING, DELETING oder UPDATING darf 500 pro Konto/Region nicht überschreiten. (Bis zu 500 gleichzeitige Tabellenoperationen sind pro Konto erlaubt — CreateTable, UpdateTable, DeleteTable, UpdateTimeToLive, RestoreTableFromBackup, RestoreTableToPointInTime — und nur bis zu 250 gleichzeitige Anfragen beim Erstellen von Tabellen mit Sekundärindizes.)
  • Bulk-Stack-Deploys — CloudFormation/CDK/Terraform, die viele Tabellen (oder viele GSIs) gleichzeitig erstellen oder abbauen, überziehen das Nebenläufigkeitsbudget.
  • Konto-Ressourcenkontingente — das Erreichen des Soft-Kontingents von 2.500 Tabellen pro Konto/Region oder das Limit von 50 gleichzeitigen Import-Jobs.
  • DynamoDB-Streams-Fehlnutzung — GetRecords mit einem Limit größer als 1000 aufrufen oder mehr als 2 Prozesse, die gleichzeitig aus demselben Streams-Shard lesen.
  • Hinweis: ein zweites UpdateTable, das ausgelöst wird, während dieselbe Tabelle noch UPDATING ist, erscheint als ResourceInUseException, nicht als dieser Fehler — aber beide bedeuten „warte zuerst auf ACTIVE".

So behebst du es

  1. Serialisiere Control-Plane-Operationen — warte, bis eine Tabelle (und jeder GSI) ACTIVE ist, bevor du die nächste Änderung daran auslöst. Poll DescribeTable und prüfe auf TableStatus === 'ACTIVE'.
  2. Wiederhole mit exponentiellem Backoff — das Limit ist vorübergehend; ein Retry mit Backoff geht meist durch, sobald die laufenden Operationen abgearbeitet sind.
  3. Drossle Bulk-Deploys — teile einen großen Stack auf, damit nicht Hunderte Tabellen/GSIs auf einmal entstehen, oder ergänze eine explizite DependsOn-Reihenfolge, damit sie nicht alle gleichzeitig starten.
  4. Prüfe deine Service-Quotas — wenn du nahe am Tabellenlimit pro Konto bist, beantrage eine Kontingenterhöhung in Service Quotas, statt endlos zu wiederholen.
  5. Füge GSIs einzeln hinzu — pro UpdateTable-Operation kannst du nur einen Global Secondary Index anlegen oder löschen; serialisiere Index-Änderungen und warte jeden Backfill ab.

FAQ

Wie behebe ich LimitExceededException in DynamoDB? Höre auf, Control-Plane-Operationen (CreateTable/UpdateTable/DeleteTable/Index-Änderungen) parallel auszulösen. Warte, bis jede Tabelle und jeder Index ACTIVE erreicht, bevor die nächste Änderung kommt, halte die Anzahl der Tabellen in CREATING/UPDATING/DELETING unter der Kontoobergrenze, und wiederhole mit exponentiellem Backoff.

Ist LimitExceededException ein Throttling-Fehler? Es ist ein Control-Plane-Nebenläufigkeits-/Limit-Fehler, kein Data-Plane-Throttling. Data-Plane-Throttling erscheint stattdessen als ProvisionedThroughputExceededException, ThrottlingException oder RequestLimitExceeded.

DynoTable auf Local zeigen lassen

DynoTable ist ein Data-Plane-Client — GetItem, Query und Scan verbrauchen nichts vom Control-Plane-Nebenläufigkeitsbudget, das dieser Fehler schützt. Wenn ein Deploy-Skript beim Anlegen von Tabellen auf LimitExceededException läuft, kannst du mit DynoTable die bereits ACTIVE gewordenen Tabellen durchsehen und das Schema über die Tabelleneinstellungen prüfen, während deine IaC weiter wiederholt. Für lokale Stacks startest du DynamoDB Local mit -sharedDb und verbindest dich über ein Local-Profil (DynamoDB Local betreiben), sodass du Teil-Deploys inspizieren kannst, ohne auf jeden GSI in AWS zu warten. Der Single-Table-Design-Planer hilft beim Skizzieren von Tabellenformen, bevor du in einem ausgelasteten Konto das nächste CreateTable abschickst.

Verwandte Fehler

Quellen

Mit DynamoDB ohne die Console arbeiten

Ein schneller DynamoDB-Desktop-Client, der das echte SQL ausführt, das DynamoDB nicht kann — JOINs, GROUP BY, Aggregationen — mit visueller Bearbeitung und einem KI-Agenten auf deinen eigenen Bedrock-Schlüsseln.

DownloadPreise ansehen

30 Tage kostenlos testen, keine Kreditkarte — danach der Kostenlos-Tarif ohne Zeitlimit.