Attempting to modify a GSI that is being created

TL;DR — Solange ein Global Secondary Index aufgebaut wird (IndexStatus = CREATING), lehnt DynamoDB kollidierende Strukturänderungen ab. In der ersten Phase der Ressourcenzuteilung kannst du den neuen Index nicht ändern, den provisionierten Durchsatz von Index oder Tabelle nicht anpassen, keine weiteren Indizes anlegen oder löschen und die Tabelle nicht löschen. Sobald der Backfill beginnt, kannst du den laufenden Index löschen oder Tabellen-/GSI-Durchsatz wieder ändern, aber das Anlegen und Löschen weiterer Indizes sowie das Löschen der Tabelle bleiben gesperrt, bis er ACTIVE ist. Nimm GSI-Änderungen einzeln vor — ein Create oder Delete pro UpdateTable.

Was es bedeutet

ValidationException: Attempting to modify a GSI that is being created

Das Erstellen eines GSI auf einer befüllten Tabelle löst einen Backfill aus — DynamoDB spielt bestehende Items im Hintergrund in den neuen Index ein. Während dieser Phase ist der IndexStatus des Index CREATING. Während des Backfills weist DynamoDB weitere strukturelle Änderungen am Index oder an der Tabelle ab, damit der Aufbau konsistent bleibt. Es ist ein HTTP 400 ValidationException; sofortiges Wiederholen schlägt fehl, bis der Index fertig ist.

Warum es passiert

Überlappende Index-Operationen — ein UpdateTable (oder ein IaC-Apply) versucht, einen GSI zu ändern/löschen oder einen zweiten hinzuzufügen, während der erste noch aufbaut.
CloudFormation-/Terraform-Batching — das Tool versucht mehrere GSI-Änderungen in einem einzigen Update; DynamoDB erlaubt nur ein GSI-Create oder -Delete pro UpdateTable.
Durchsatzänderung während der Ressourcen-Allokation — während der neue Index noch Ressourcen allokiert (Backfilling: false), kannst du den bereitgestellten Durchsatz dieses Index oder der Tabelle nicht ändern; diese Änderungen sind wieder erlaubt, sobald das Backfilling beginnt.
Die Tabelle zu früh löschen — ein Teardown, der mit dem Backfill um die Wette läuft.

So behebst du es

Warte auf ACTIVE. Poll DescribeTable und prüfe jeden GlobalSecondaryIndexes[].IndexStatus; fahre erst fort, wenn er ACTIVE ist.
```
aws dynamodb describe-table --table-name <Table> \
  --query "Table.GlobalSecondaryIndexes[].{Name:IndexName,Status:IndexStatus}"
```
Die Indexbeschreibung trägt außerdem einen Backfilling-Boolean (false = Ressourcen-Allokation, true = Backfilling), und die CloudWatch-Metrik OnlineIndexPercentageProgress verfolgt den Aufbau.
Staffele Index-Änderungen — ein Create/Delete pro UpdateTable; füge keinen neuen GSI hinzu, während ein anderer aufbaut.
In CloudFormation/Terraform teile GSI-Ergänzungen auf separate Deploys auf, sodass jeder Backfill abgeschlossen ist, bevor die nächste Änderung kommt.
Verschiebe andere Index-Änderungen und das Löschen der Tabelle, bis der Index ACTIVE ist. Musst du aussteigen? Sobald das Backfilling begonnen hat, kannst du den Aufbau abbrechen, indem du den in Erstellung befindlichen Index löschst.

Vor dem Retry in DynoTable

Während a GSI is CREATING, open the table in DynoTable and watch index status under table details bevor du queue another UpdateTable. Die App aktualisiert DescribeTable, während du browsed — wenn IndexStatus auf ACTIVE wechselt, erscheint der Index im Query-Pattern-Picker und du kannst ihn aus dem Visual-Modus queryen or the Query Builder.

Nicht stack CloudFormation/Terraform GSI changes in one apply während DynoTable still shows CREATING. Sequenziere Deploys; nutze DynoTable als Ground-Truth-Status-Panel zwischen Applies. Wenn you need to cancel a build nachdem backfilling starts, delete that index from your IaC/CLI, then confirm it disappears from the DynoTable index list.

Quellen

Managing Global 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.