Provisioned throughput decreases are limited within a given day

TL;DR — DynamoDB limite la fréquence à laquelle tu peux baisser la capacité de lecture/écriture provisionnée d'une table (ou d'un GSI) en un seul jour UTC. Tu as épuisé le quota, donc UpdateTable est rejeté. Attends le rechargement horaire, regroupe ta baisse en moins d'étapes plus grandes, ou bascule la table en on-demand et arrête complètement de gérer les baisses.

Ce que ça signifie

LimitExceededException: Subscriber limit exceeded: Provisioned throughput
decreases are limited within a given UTC day

Chaque table commence un jour UTC avec un petit budget de baisses de capacité (les hausses peuvent être faites aussi souvent que nécessaire, sous réserve des quotas du compte et du fait que DynamoDB ne te laisse pas monter en charge trop vite). Tu commences la journée avec 4 baisses disponibles, et tu en gagnes 1 de plus chaque heure jusqu'à un maximum de 4 disponibles à tout moment — de quoi faire jusqu'à 27 baisses sur une journée de 24 heures complète. Une fois épuisé, les appels UpdateTable de baisse supplémentaires échouent avec une LimitExceededException (HTTP 400 ; le message générique du guide développeur pour cette exception est « Too many operations for a given subscriber. ») jusqu'à ce que le budget se recharge. C'est un quota, donc réessayer aveuglément n'aidera pas dans la même fenêtre.

Pourquoi ça arrive

Oscillation de l'auto-scaling — une charge de travail en pics amène DynamoDB auto-scaling à baisser la capacité de façon répétée, épuisant le budget de baisses.
Un script qui baisse la capacité trop souvent — beaucoup de petites baisses au lieu d'une plus grande.
Réglage manuel pendant des tests de charge — baisser la capacité de façon répétée à mesure que le trafic reflue.
Budgets par index — les limites de baisse de la table et du GSI sont découplées, donc chaque GSI a son propre quota ; une table avec plusieurs index peut l'atteindre sur l'un d'eux. Une seule requête UpdateTable qui baisse à la fois la table et un GSI est rejetée en entier si l'un des deux dépasse sa limite actuelle.

Comment le corriger

Attends le rechargement. Une baisse redevient disponible chaque heure (jusqu'à 4 disponibles à tout moment) ; un budget frais de 4 baisses démarre chaque jour UTC.
Fais moins de baisses, plus grandes. Passe de 1000 → 200 en une seule étape au lieu de cinq étapes de 160 unités.
Règle l'auto-scaling — augmente le taux d'utilisation cible et ajoute un temps de refroidissement pour le scale-in afin qu'il arrête de baisser aussi agressivement.
Bascule en on-demand si la charge de travail est irrégulière ou imprévisible :
```
aws dynamodb update-table --table-name <Table> \
  --billing-mode PAY_PER_REQUEST
```
L'on-demand supprime totalement la gestion manuelle de capacité (et son quota de baisses).

Erreurs liées

ProvisionedThroughputExceededException — le throttle à l'exécution quand les lectures/écritures dépassent la capacité provisionnée.
LimitExceededException — la famille de quotas de plan de contrôle compte/table plus large.
En savoir plus : On-demand vs provisioned

Références

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