DynamoDB: Table already exists

TL;DR — 該操作想_建立_它的目標表，而在這個帳戶 + 區域中名稱已被佔用。恢復（RestoreTableFromBackup / RestoreTableToPointInTime）丟擲 TableAlreadyExistsException；CreateTable 和 ImportTable 把同樣的情況報告為 ResourceInUseException。選一個新的目標名稱——恢復和匯入永遠無法寫入一張已有的表。

這是什麼意思

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

# what the engine actually returns, reproduced against DynamoDB Local:
ResourceInUseException: Cannot create preexisting table

恢復和匯入操作總是建立一張全新的表——它們無法合併進或覆蓋一張活動的表。如果目標名稱在同一個帳戶和區域中解析到任何已有的表（無論其狀態如何），請求都會一開始就失敗。你看到哪個異常取決於 API：恢復家族有它自己的 TableAlreadyExistsException，而 CreateTable 和 ImportTable 呈現通用的 ResourceInUseException。

為什麼會發生

把一個備份恢復到原來的名稱——自然的本能（"把我的表放回去"）與仍然存在的表衝突。
重新執行一次匯入或 IaC 部署——一個重試的 ImportTable，或一個試圖建立一張已在棧狀態之外存在的表的 CloudFormation/Terraform/CDK 棧。
一次建立後重試的競速——第一個 CreateTable 成功了（或仍處於 CREATING），而重試發現名稱被佔用了。
環境衝突——兩個階段/環境共享一個帳戶，且都想要那個無字首的名稱。

如何修正

恢復到一個新名稱，然後切換——恢復為 my-table-restored，核實資料，把應用重新指向它（或者刪除舊錶並在它消失後以原來的名稱再次恢復）：
```
aws dynamodb restore-table-from-backup \
  --target-table-name my-table-restored \
  --backup-arn arn:aws:dynamodb:...:table/my-table/backup/...
```
如果你打算替換這張表，就先刪除已有的那張並等到刪除完成——當表處於 DELETING 狀態時名稱仍被佔用（此時嘗試的恢復會以 TableInUseException 失敗；CreateTable 側參見 ResourceInUseException）。
對於匯入，選擇一個未使用的目標名稱——ImportTable 只建立新表。要把資料載入進一張已有的表，改用 BatchWriteItem/PutItem 寫入。
對於 IaC 重試，把已有的表匯入棧的狀態（或重新命名），而不是與建立搏鬥。
檢查實際存在什麼——在同一區域/帳戶中 aws dynamodb list-tables 能確定名稱是否真的空閒。

在切換前核實一張恢復出來的表是人們跳過的安全步驟——DynoTable 桌面應用把恢復的和原來的表並排放在一起，讓你先對比模式並抽查項目。而如果你在估算恢復出來的表執行成本，DynamoDB 定價計算器覆蓋兩種容量模式。

在 DynoTable 中測量

在切換之前，開啟 DynoTable 中的原始表和恢復表 — 切換到 ⌘K 並並排抽查項目。暫存 (⌘S) 允許你在不影響生產流量的情況下測試已恢復副本的寫入。使用 pricing calculator 調整恢復表的大小。使用⌘P切換帳戶/地區； 在“設定”→“設定檔案”上測試連線。參見連線 AWS和安裝。

來源

RestoreTableFromBackup — Amazon DynamoDB API Reference（2026-07-13 驗證）
CreateTable — Amazon DynamoDB API Reference（2026-07-13 驗證）

參考資料

最後核實於 2026-07-13，依據上方連結的 AWS 官方文件。