BackupInUseException

TL;DR — A conflicting backup control-plane operation is still in flight on this table: the backup is being created, deleted, or restored right now. These operations serialize — wait for the in-flight one to finish (check BackupStatus via DescribeBackup), then retry yours.

What it means

BackupInUseException: There is another ongoing conflicting backup control
plane operation on the table. The backup is either being created, deleted
or restored to a table.

On-demand backup operations (CreateBackup, DeleteBackup, RestoreTableFromBackup) are control-plane calls, and DynamoDB rejects ones that would conflict with an operation already running against the same backup or table. It's a transient state error, not a permissions or data problem.

Why it happens

Deleting a backup that's still being created — the CreateBackup hasn't reached AVAILABLE yet.
Deleting a backup while a restore from it is running — the restore holds the backup until the new table finishes creating.
Overlapping automation — a cleanup script and a backup scheduler racing each other, or a retry loop double-firing CreateBackup on the same table.
Bursting past the rate limit — DeleteBackup accepts at most 10 calls per second; sweeping many backups in a tight loop trips conflicts and throttling together.

How to fix it

Check what's in flight, then wait:
```
aws dynamodb describe-backup --backup-arn arn:aws:dynamodb:...:table/orders/backup/01234...
# BackupStatus: CREATING | AVAILABLE | DELETED
```
Retry your operation once the status settles (AVAILABLE for a completed create; a restoring table reaches ACTIVE via describe-table).
Retry with backoff instead of failing hard — backup operations take seconds to minutes; a simple wait-and-retry loop around the call absorbs the serialization.
Serialize your automation — one owner per table for backup lifecycle operations; queue deletes behind creates rather than running both on a cron that can overlap.
Pace bulk deletes — stay under 10 DeleteBackup calls/second and handle this exception as the signal to slow down.
Tag backups with the table name and date so automation can skip in-flight ARNs instead of blindly retrying deletes.

Spot this in DynoTable

Before you delete backups, browse the live table they protect — open it with ⌘K and confirm the data still matters. DynoTable makes it practical to spot-check table contents across accounts (⌘P) before a cleanup script runs.

Estimate restore read traffic with the pricing calculator when you plan a RestoreTableFromBackup. Configure profiles under Settings → Profiles with Test Connection for each account that owns backups. See Connect to AWS and Install. While waiting for an in-flight backup to finish, browse protected tables with ⌘K to confirm the data still warrants retention. A DescribeBackup poll every few seconds is enough — backup creates typically finish within minutes, and deletes are similarly bounded.

Sources

DeleteBackup — Amazon DynamoDB API Reference (verified 2026-07-13)
Restoring a DynamoDB table from a backup (verified 2026-07-13)

BackupNotFoundException — the ARN doesn't resolve to a backup at all.
Table already exists — restoring to a name that's taken.
LimitExceededException — too many concurrent control-plane operations.
Learn: Backups & point-in-time recovery

References

Last verified 2026-07-13 against the official AWS documentation linked above.