Local secondary indexes must be specified at table creation

TL;DR — Ein Local Secondary Index (LSI) lässt sich nur im Moment der Tabellenerstellung anlegen; danach kann er weder hinzugefügt noch geändert oder entfernt werden. UpdateTable hat keine Operation für LSIs, jeder Versuch an einer laufenden Tabelle scheitert also an der Validierung. Für einen neuen LSI musst du eine neue Tabelle (mit dem LSI) anlegen und die Daten migrieren — oder du nimmst einen Global Secondary Index (GSI), der sich im Betrieb hinzufügen lässt.

Was es bedeutet

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

Ein LSI teilt seinen Partitionsschlüssel mit der Basistabelle und fügt einen alternativen Sortierschlüssel hinzu; DynamoDB legt ihn beim Schreiben mit der Partition des Items zusammen. Wegen dieser physischen Kopplung muss ein LSI ab dem ersten Schreibvorgang der Tabelle existieren — UpdateTable unterstützt das Hinzufügen/Entfernen von GSIs, hat aber gar keinen LSI-Parameter, also gibt es keine Anfrage, die du überhaupt senden könntest, um einen nachzurüsten. Die exakte Meldung variiert je nach Pfad (ein SDK-/CLI-Aufruf kann clientseitig an der Parametervalidierung scheitern; IaC-Tools bringen ihren eigenen Wortlaut hervor), aber die serviceseitige Form ist ein HTTP 400 ValidationException und sie ist nicht wiederholbar: Die Operation wird auf einer bestehenden Tabelle schlicht nicht unterstützt.

Warum es passiert

Einen LSI zu einer aktiven Tabelle hinzufügen — UpdateTable aufrufen (oder ein CloudFormation-/Terraform-Template bearbeiten), um einen neuen LocalSecondaryIndexes-Eintrag auf einer bereits existierenden Tabelle einzuführen.
Einen bestehenden LSI ändern — sein Key-Schema oder seine Projection ist bei der Erstellung fixiert; Änderungen werden abgewiesen.
Ein IaC-Diff, der neu erstellt statt aktualisiert — das Tool versucht, eine LSI-Änderung in-place zu aktualisieren, die DynamoDB nur zur Erstellungszeit erlaubt.

So behebst du es

Erstelle eine neue Tabelle mit dem LSI von vornherein definiert und migriere dann die Daten (Scan-and-Write oder ein On-Demand-Export/-Import).
Nutze stattdessen einen GSI, wenn das Zugriffsmuster es zulässt — GSIs können einer bestehenden Tabelle online hinzugefügt werden und benötigen nicht denselben Partitionsschlüssel:
```
aws dynamodb update-table --table-name <Table> \
  --attribute-definitions AttributeName=gsi_sk,AttributeType=S \
  --global-secondary-index-updates '[{"Create":{"IndexName":"gsi1", ...}}]'
```
Plane LSIs während der Modellierung — entscheide alternative Sortierschlüssel, bevor die Tabelle existiert, da sie nicht nachgerüstet werden können.

Größe in DynoTable prüfen

Bevor du rebuild a table for an LSI, validate the access pattern in DynoTable — öffne die Tabelle mit ⌘K and test whether a GSI query covers the same need. The Query Builder generiert die KeyConditionExpression, die dein neuer Index bedienen muss.

Use the Pricing-Rechner um LSI-Write-Amplification gegen eine GSI-Alternative zu vergleichen. Wechsle Profile mit ⌘P; see Mit AWS verbinden and Installation.

Quellen

Local secondary indexes (verifiziert 2026-07-13)
UpdateTable — Amazon DynamoDB API Reference (verifiziert 2026-07-13)

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.