Local secondary indexes must be specified at table creation

En bref — Un index secondaire local (LSI) ne peut être créé qu'au moment de la création de sa table ; il ne peut pas être ajouté, modifié ou supprimé ensuite. UpdateTable n'a aucune opération pour les LSI, donc toute tentative d'en ajouter un à une table active échoue à la validation. Pour obtenir un nouveau LSI, tu dois créer une nouvelle table (avec le LSI) et migrer les données — ou utiliser un index secondaire global (GSI), qui peut être ajouté en ligne.

Ce que ça signifie

ValidationException: One or more parameter values were invalid: Local secondary
indexes can only be created when a table is created

Un LSI partage sa clé de partition avec la table de base et ajoute une clé de tri alternative ; DynamoDB le co-localise avec la partition de l'élément au moment de l'écriture. À cause de ce couplage physique, un LSI doit exister dès la première écriture de la table — UpdateTable prend en charge l'ajout/la suppression de GSI mais n'a aucun paramètre LSI, donc il n'existe même aucune requête que tu pourrais envoyer pour en rajouter un après coup. Le message exact varie selon le chemin (un appel SDK/CLI peut échouer à la validation des paramètres côté client ; les outils IaC affichent leur propre formulation), mais la forme côté service est un HTTP 400 ValidationException et elle n'est pas réessayable : l'opération n'est tout simplement pas prise en charge sur une table existante.

Pourquoi ça arrive

Ajouter un LSI à une table active — appeler UpdateTable (ou modifier un modèle CloudFormation/Terraform) pour introduire une nouvelle entrée LocalSecondaryIndexes sur une table qui existe déjà.
Modifier un LSI existant — son schéma de clé ou sa projection est figé à la création ; les modifications sont rejetées.
Un diff IaC qui recrée au lieu de mettre à jour — l'outil tente une mise à jour sur place d'un changement de LSI que DynamoDB n'autorise qu'à la création.

Comment le corriger

Crée une nouvelle table avec le LSI défini d'emblée, puis migre les données (scan-and-write, ou un export/import à la demande).

Utilise plutôt un GSI si le schéma d'accès le permet — les GSI peuvent être ajoutés à une table existante en ligne et n'exigent pas la même clé de partition :

aws dynamodb update-table --table-name <Table> \
  --attribute-definitions AttributeName=gsi_sk,AttributeType=S \
  --global-secondary-index-updates '[{"Create":{"IndexName":"gsi1", ...}}]'

Planifie les LSI pendant la modélisation — décide des clés de tri alternatives avant que la table n'existe, puisqu'elles ne peuvent pas être rajoutées après coup.

Vérifie la taille dans DynoTable

Avant de reconstruire une table pour un LSI, valide le modèle d'accès dans DynoTable — ouvre la table avec ⌘K et teste si une requête sur GSI couvre le même besoin. Le Query Builder génère la KeyConditionExpression que ton nouvel index devra servir.

Sers-toi du calculateur de tarifs pour comparer l'amplification d'écriture d'un LSI à une alternative en GSI. Change de profil avec ⌘P ; vois Se connecter à AWS et Installation.

Sources

Local secondary indexes (vérifié le 2026-07-13)
UpdateTable — Amazon DynamoDB API Reference (vérifié le 2026-07-13)

Erreurs liées

Attempting to modify a GSI that is being created — un changement de GSI bloqué pendant la construction de l'index.
Requested resource not found / index not found — interroger un nom d'index qui n'existe pas.
ValidationException (aperçu)
Apprends : GSI vs LSI · Index

Références

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