DynamoDB: Table already exists

TL;DR — Die Operation will ihre Zieltabelle erstellen, und der Name ist in diesem Konto + dieser Region bereits vergeben. Restores (RestoreTableFromBackup / RestoreTableToPointInTime) werfen TableAlreadyExistsException; CreateTable und ImportTable melden dieselbe Situation als ResourceInUseException. Wähle einen neuen Zielnamen — Restores und Imports können nie in eine existierende Tabelle schreiben.

Was es bedeutet

TableAlreadyExistsException: A target table with the specified name already exists
ResourceInUseException: Table already exists: my-table

Restore- und Import-Operationen erstellen immer eine brandneue Tabelle — sie können nicht in eine aktive Tabelle mergen oder sie überschreiben. Wenn sich der Zielname auf irgendeine existierende Tabelle (in welchem Zustand auch immer) im selben Konto und derselben Region auflöst, scheitert der Request von vornherein. Welche Exception du siehst, hängt von der API ab: Die Restore-Familie hat ihre eigene TableAlreadyExistsException, während CreateTable und ImportTable die generische ResourceInUseException zutage fördern.

Warum es passiert

• Ein Backup über den Originalnamen wiederherstellen — der natürliche Instinkt ("meine Tabelle zurücklegen") kollidiert mit der noch existierenden Tabelle.
• Einen Import oder ein IaC-Deployment erneut ausführen — ein wiederholtes ImportTable oder ein CloudFormation-/Terraform-/CDK-Stack, der versucht, eine Tabelle zu erstellen, die außerhalb des Stack-States bereits existiert.
• Ein Create-dann-Retry-Wettlauf — das erste CreateTable war erfolgreich (oder ist noch CREATING), und der Retry findet den Namen vergeben.
• Umgebungskollision — zwei Stages/Umgebungen teilen sich ein Konto und beide wollen den nicht präfixierten Namen.

So behebst du es

1. Stelle unter einem neuen Namen wieder her, dann schalte um — stelle als my-table-restored wieder her, verifiziere die Daten, richte die Anwendung neu aus (oder lösche die alte Tabelle und stelle erneut unter dem Originalnamen wieder her, sobald sie weg ist):

   aws dynamodb restore-table-from-backup \
     --target-table-name my-table-restored \
     --backup-arn arn:aws:dynamodb:...:table/my-table/backup/...

2. Wenn du die Tabelle ersetzen willst, lösche zuerst die existierende und warte, bis die Löschung abgeschlossen ist — der Name bleibt vergeben, solange die Tabelle im Zustand DELETING ist (ein dann versuchter Restore scheitert mit TableInUseException; siehe ResourceInUseException für die CreateTable-Seite).

3. Für Imports wähle einen unbenutzten Zielnamen — ImportTable erstellt nur neue Tabellen. Um Daten in eine existierende Tabelle zu laden, schreibe sie stattdessen mit BatchWriteItem/PutItem.

4. Für IaC-Retries importiere die existierende Tabelle in den State des Stacks (oder benenne um), statt gegen das Erstellen zu kämpfen.

5. Prüfe, was tatsächlich existiert — aws dynamodb list-tables in derselben Region/im selben Konto klärt, ob der Name wirklich frei ist.

Eine wiederhergestellte Tabelle vor dem Umschalten zu verifizieren, ist der sichere Schritt, den Leute überspringen — die DynoTable-Desktop-App stellt die wiederhergestellte und die Original-Tabelle nebeneinander, sodass du das Schema diffen und Items stichprobenartig prüfen kannst. Und wenn du schätzt, was die wiederhergestellte Tabelle im Betrieb kosten wird, deckt der DynamoDB-Preisrechner beide Kapazitätsmodi ab.

Verwandte Fehler

• ResourceInUseException — die CreateTable-Variante derselben Kollision.
• Backup not found
• Export requires PITR
• Learn: Backups & Point-in-Time Recovery

Referenzen

• RestoreTableFromBackup — Amazon DynamoDB API Reference
• RestoreTableToPointInTime — Amazon DynamoDB API Reference
• CreateTable — Amazon DynamoDB API Reference
• Amazon S3 import validation errors — Amazon DynamoDB Developer Guide

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