The table does not have the specified index

TL;DR — Der IndexName in deiner Query/deinem Scan existiert auf dieser Tabelle nicht (aus Sicht von Region + Konto dieses Clients), ist falsch geschrieben, oder der GSI ist noch CREATING und damit nicht abfragbar. Bestätige den exakten Indexnamen und -status mit DescribeTable und korrigier den Aufruf.

Was es bedeutet

ValidationException: The table does not have the specified index: <IndexName>

# what the engine actually returns, reproduced against DynamoDB Local:
ValidationException: The table does not have the specified index: no-such-index

Du hast DynamoDB gebeten, einen bestimmten Sekundärindex nach Namen zu Query oder Scan, und die Tabelle (wie dieser Client sie sieht) hat keinen Index mit diesem Namen in einem nutzbaren Zustand. Es ist ein HTTP 400 ValidationException — clientseitig und nicht wiederholbar, bis Name/Status stimmen.

Warum es passiert

• Tippfehler oder falsche Groß-/Kleinschreibung — Indexnamen sind case-sensitiv; GSI1 ≠ gsi1.
• Index gehört zu einer anderen Tabelle — du hast den IndexName aus dem Schema einer anderen Tabelle kopiert.
• Der GSI ist noch nicht ACTIVE — ein neu erstellter Global Secondary Index kann erst abgefragt werden, wenn sein Status von CREATING → ACTIVE wechselt (er wird zuerst befüllt).
• Falsche Region/falsches Konto — der Client zeigt auf eine Region, in der die Tabelle (oder ihr Index) nicht existiert (dasselbe Problem der Zuordnung wie bei einer fehlenden Tabelle).
• DynamoDB-Local-Drift — eine veraltete lokale shared-local-instance.db, die dem Index vorausgeht; erstelle sie neu.

So behebst du es

1. Liste die echten Indexnamen und -status auf:

   aws dynamodb describe-table --table-name <Table> \
     --query "Table.GlobalSecondaryIndexes[].{Name:IndexName,Status:IndexStatus}"

   KopierenKopiert
2. Kopiere den Namen wortgetreu in IndexName — stimme die Groß-/Kleinschreibung exakt ab.
3. Warte auf ACTIVE. Wenn der GSI CREATING ist, funktioniert die Query erst, sobald das Backfill abgeschlossen ist (DescribeTable zeigt IndexStatus).
4. Bestätige Region + Konto mit aws sts get-caller-identity und pinne die region des Clients.
5. Bei DynamoDB Local lösche die lokale DB-Datei und führe dein Tabellen-/Index-Setup erneut aus, sodass der Index lokal existiert.

Arbeitest du über mehrere Tabellen und Indizes hinweg? DynoTables Tabellen-Dialog listet die GSIs jeder Tabelle und ihren Status auf, sodass du einen Index auswählen kannst, der tatsächlich existiert — und ACTIVE ist — statt den Namen zu erraten. Er erstellt und löscht außerdem einen GSI, wenn der Index, den du brauchst, wirklich fehlt.

In DynoTable abfragen

Öffne die Tabelle in DynoTable mit ⌘K und klapp das Indexes-Panel auf — jeder GSI-Name und IndexStatus steht dort ohne einen einzigen CLI-Aufruf. Wähl den Index aus dem Dropdown im Query-Panel, statt IndexName von Hand zu tippen; DynoTable bietet nur Indizes an, die es auf der verbundenen Tabelle wirklich gibt.

Wenn the GSI is still CREATING, refresh the table metadata from the sidebar until status flips to ACTIVE. Nutze den Query Builder to compose a GSI query and copy the generated IndexName into your SDK code. Wechsle Profile mit ⌘P when the index exists in one Region but not another. Setup: Mit AWS verbinden, Installation.

Quellen

• Managing Global Secondary Indexes in DynamoDB (verifiziert 2026-07-13)
• Query — Amazon DynamoDB API Reference (verifiziert 2026-07-13)

Verwandte Fehler

• ResourceNotFoundException — die ganze Tabelle (nicht nur ein Index) kann nicht gefunden werden.
• Query key condition not supported — der Index existiert, aber deine Key-Condition ist dafür falsch.
• Code-Beispiel: Query a GSI in Node.js — IndexName korrekt verdrahtet.
• Learn: GSI vs LSI · GSIs sind letztendlich konsistent · Indexes

Referenzen

• Managing Global Secondary Indexes in DynamoDB — Amazon DynamoDB Developer Guide
• Query — Amazon DynamoDB API Reference
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide

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