DynamoDB LimitExceededException

TL;DR — Tu as émis trop d'opérations de plan de contrôle à la fois (ou atteint une limite de table/compte). Jusqu'à 500 tables et index peuvent être à l'état CREATING/UPDATING/DELETING dans ton compte à un instant donné. Sérialise tes opérations de table, attends l'état ACTIVE, et réessaie avec un backoff.

Ce que ça signifie

LimitExceededException: Too many operations for a given subscriber.

C'est une erreur de plan de contrôle — elle provient de CreateTable, UpdateTable, DeleteTable, de la création d'index, des restaurations et d'appels similaires, pas de GetItem/PutItem/Query. DynamoDB t'indique que tu as dépassé une limite de concurrence ou de compte. C'est une erreur HTTP 400, et AWS l'indique comme réessayable — la condition se dissipe à mesure que les opérations en cours se terminent.

Pourquoi ça arrive

Trop d'opérations de table/index concurrentes — le nombre cumulé de tables et d'index à l'état CREATING, DELETING ou UPDATING ne peut pas dépasser 500 par compte/Région. (Jusqu'à 500 opérations de table simultanées sont autorisées par compte — CreateTable, UpdateTable, DeleteTable, UpdateTimeToLive, RestoreTableFromBackup, RestoreTableToPointInTime — et seulement jusqu'à 250 requêtes concurrentes lors de la création de tables avec index secondaires.)
Déploiements de stack en masse — CloudFormation/CDK/Terraform créant ou démolissant de nombreuses tables (ou de nombreux GSI) simultanément dépasse le budget de concurrence.
Quotas de ressources du compte — atteindre le quota souple de 2 500 tables par compte/Région, ou la limite de 50 jobs d'import simultanés.
Mauvaise utilisation de DynamoDB Streams — appeler GetRecords avec un Limit supérieur à 1000, ou plus de 2 processus lisant depuis le même shard de flux à la fois.
Note : un second UpdateTable émis pendant que la même table est encore UPDATING remonte sous forme de ResourceInUseException, et non de cette erreur — mais les deux signifient « attends d'abord ACTIVE ».

Comment le corriger

Sérialise les opérations de plan de contrôle — attends qu'une table (et chaque GSI) devienne ACTIVE avant d'émettre le changement suivant la concernant. Interroge DescribeTable et bloque sur TableStatus === 'ACTIVE'.
Réessaie avec un backoff exponentiel — la limite est transitoire ; une nouvelle tentative espacée réussit généralement une fois les opérations en cours drainées.
Régule les déploiements en masse — découpe une grosse stack pour ne pas créer des centaines de tables/GSI d'un coup, ou ajoute un ordonnancement DependsOn explicite pour qu'ils ne se déclenchent pas tous ensemble.
Vérifie tes quotas de service — si tu es proche de la limite de tables par compte, demande une augmentation de quota dans Service Quotas plutôt que de réessayer indéfiniment.
Ajoute les GSI un par un — tu ne peux créer ou supprimer qu'un seul index secondaire global par opération UpdateTable, donc sérialise les changements d'index et attends chaque backfill.

FAQ

Comment corriger LimitExceededException dans DynamoDB ? Arrête d'émettre des opérations de plan de contrôle (CreateTable/UpdateTable/DeleteTable/changements d'index) en parallèle. Attends que chaque table et index atteigne ACTIVE avant le changement suivant, garde le nombre de tables en CREATING/UPDATING/DELETING sous le plafond du compte, et réessaie avec un backoff exponentiel.

LimitExceededException est-elle une erreur de throttling ? C'est une erreur de concurrence/limite de plan de contrôle, pas un throttling de plan de données. Le throttling de plan de données remonte plutôt sous forme de ProvisionedThroughputExceededException, ThrottlingException ou RequestLimitExceeded.

Pointe DynoTable vers Local

DynoTable est un client du plan de données — GetItem, Query et Scan ne consomment pas le budget de concurrence du plan de contrôle que cette erreur protège. Si un script de déploiement tombe sur LimitExceededException en créant des tables, sers-toi de DynoTable pour parcourir celles qui ont déjà atteint ACTIVE et valider leur schéma depuis Paramètres de la table pendant que ton IaC réessaie. Pour les stacks locales, lance DynamoDB Local avec -sharedDb et connecte-toi via un profil Local (Running DynamoDB Local) : tu peux ainsi inspecter des déploiements partiels sans attendre que chaque GSI se termine dans AWS. Le planificateur de conception à table unique aide à esquisser des formes de table avant de lancer un nouveau CreateTable dans un compte chargé.

Erreurs liées

ResourceInUseException — une opération sur une table qui est déjà en cours de modification ou existe déjà.
ThrottlingException — limitation de débit du plan de données/contrôle.
RequestLimitExceeded — limite de débit de requêtes du compte.
Apprends : Migrations DynamoDB

Sources

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.