"Local secondary indexes must be specified at table creation": gli indici secondari locali devono essere specificati al momento della creazione della tabella

TL;DR — Un indice secondario locale (LSI) può essere creato solo nel momento in cui viene creata la sua tabella; non può essere aggiunto, modificato o rimosso in seguito. UpdateTable non prevede alcuna operazione per gli LSI, quindi qualsiasi tentativo di aggiungerne uno a una tabella attiva non riesce a convalidare. Per ottenere un nuovo LSI devi creare una nuova tabella (con LSI) e migrare i dati — oppure utilizzare un indice secondario globale (GSI), che può essere aggiunto online.

Cosa significa

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

Un LSI condivide la sua chiave di partizione con la tabella di base e aggiunge una chiave di ordinamento alternativa; DynamoDB lo co-localizza con la partizione dell'elemento al momento della scrittura. A causa di questo accoppiamento fisico, deve esistere un LSI dalla prima scrittura della tabella — UpdateTable supporta l'aggiunta/rimozione di GSI ma nessun parametro LSI, quindi non c'è alcuna richiesta che potresti inviare per aggiornarne uno. Il messaggio esatto varia in base al percorso (una chiamata SDK/CLI potrebbe non riuscire a convalidare i parametri lato client; gli strumenti IaC presentano la propria formulazione), ma il modulo lato servizio è una ValidationException HTTP 400 e non è riprovabile: l'operazione semplicemente non è supportata su una tabella esistente.

Perché succede

Aggiunta di un LSI a una tabella live — chiamando UpdateTable (o modificando un modello CloudFormation/Terraform) per introdurre una nuova voce LocalSecondaryIndexes su una tabella che già esiste.
Modifica di un LSI esistente: il suo schema chiave o proiezione è fissato al momento della creazione; le modifiche vengono rifiutate.
Una differenza IaC che ricrea rispetto agli aggiornamenti: lo strumento tenta di aggiornare sul posto una modifica di LSI che DynamoDB consente solo al momento della creazione.

Come risolverlo

Crea una nuova tabella con i LSI definiti in anticipo, quindi esegui la migrazione dei dati (scansione e scrittura o esportazione/importazione su richiesta).

Utilizzare invece un GSI se il modello di accesso lo consente — I GSI possono essere aggiunti a una tabella esistente online e non richiedono la stessa chiave di partizione:

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

Pianificare gli LSI durante la modellazione: decidere chiavi di ordinamento alternative prima che la tabella esista, poiché non possono essere adattate.
Modellare prima il modello di accesso in un GSI. Se la query funziona su un GSI con una chiave di partizione diversa, si evita completamente la ricostruzione della tabella.

Controlla la dimensione in DynoTable

Prima di ricostruire una tabella per un LSI, convalida il modello di accesso in DynoTable — apri la tabella con ⌘K e verifica se una query GSI copre la stessa esigenza. Il Query Builder genera la "KeyConditionExpression" che il tuo nuovo indice deve servire.

Utilizza il calcolatore dei prezzi per confrontare l'amplificazione di scrittura LSI con un'alternativa GSI. Cambia profilo con ⌘P; vedere Connetti a AWS e Installa.

Fonti

Indici secondari locali (verificato il 13-07-2026)
UpdateTable - Riferimento Amazon DynamoDB API (verificato il 13-07-2026)

Errori correlati

Tentativo di modificare un GSI in fase di creazione — una modifica GSI bloccata durante la creazione dell'indice.
Risorsa richiesta non trovata/indice non trovato - interrogazione su un nome di indice che non esiste.
ValidationException (panoramica)
Impara: GSI vs LSI · Panoramica degli indici

Riferimenti

Ultima verifica il 13-07-2026 rispetto alla documentazione ufficiale del AWS collegata sopra.