Introduction

Deleting all DynamoDB tables is technically easy and operationally risky. There is no single “delete everything” API, so the real task is to list the tables in the correct account and region, delete them one by one, and wait for the deletions to finish. The dangerous part is usually not the code itself, but accidentally running it in the wrong environment.

Confirm Account and Region First

DynamoDB tables are regional resources, so the first safety check is always identity plus region.

aws sts get-caller-identity
aws configure get region
aws dynamodb list-tables --region us-east-1

If a cleanup script uses the wrong AWS profile or a stale default region, it can destroy tables you never intended to touch. That is why mass deletion scripts should never rely on vague local defaults.

The Basic AWS CLI Pattern

For a disposable development account, the CLI approach is often enough.

1REGION="us-east-1"
2
3for table in $(aws dynamodb list-tables --region "$REGION" --query 'TableNames[]' --output text); do
4  echo "Deleting: $table"
5  aws dynamodb delete-table --table-name "$table" --region "$REGION"
6  aws dynamodb wait table-not-exists --table-name "$table" --region "$REGION"
7done

The waiter is important because delete-table is asynchronous. Without waiting, later steps may assume the table is already gone while DynamoDB is still processing the deletion.

Use boto3 for Better Control

If you need logging, pagination, or skip rules, a Python script is usually easier to maintain than a shell loop.

1import boto3
2from botocore.exceptions import ClientError
3
4client = boto3.client("dynamodb", region_name="us-east-1")
5
6
7def list_all_tables():
8    paginator = client.get_paginator("list_tables")
9    for page in paginator.paginate():
10        for name in page.get("TableNames", []):
11            yield name
12
13
14def delete_all_tables():
15    waiter = client.get_waiter("table_not_exists")
16    for name in list_all_tables():
17        print(f"Deleting {name}")
18        try:
19            client.delete_table(TableName=name)
20            waiter.wait(TableName=name)
21        except ClientError as exc:
22            print(f"Failed for {name}: {exc}")
23
24
25delete_all_tables()

This structure is easy to extend when you want denylists, confirmations, or audit logging.

Add Safety Rules Before Running It

A mass-deletion command should almost never run without guardrails. Useful protections include:

• requiring an explicit region argument
• requiring an explicit AWS profile
• printing the tables before deletion
• skipping protected prefixes such as prod_
• asking for a manual confirmation string

For example:

1PROTECTED_PREFIXES = ("prod_", "shared_")
2
3for name in list_all_tables():
4    if name.startswith(PROTECTED_PREFIXES):
5        print(f"Skipping protected table: {name}")
6        continue
7    client.delete_table(TableName=name)

That does not make the operation safe by itself, but it prevents a class of obvious mistakes.

Think About Recovery Before Cleanup

Deleting a table means deleting its data, indexes, and configuration. Before doing that in anything beyond a disposable sandbox, decide whether you need:

• backups or exports
• point-in-time recovery checks
• infrastructure-as-code re-creation steps
• proof that the tables are truly disposable

A cleanup script can be syntactically correct and still be a bad operational decision.

Add a Dry-Run Mode First

Before the script deletes anything, it is worth supporting a dry-run path that only prints the tables it would remove. That gives you one last chance to confirm naming patterns, account context, and skip rules before turning a safe listing operation into a destructive one.

Common Pitfalls

• Running the deletion in the wrong AWS account or region.
• Forgetting that table deletion is asynchronous.
• Giving a cleanup script broader IAM permissions than it actually needs.
• Deleting shared tables because no skip rules or confirmation step existed.

Summary

• DynamoDB does not provide a one-shot API to delete every table automatically.
• List the tables, delete them individually, and wait for each deletion to finish.
• Verify account and region before running any cleanup.
• Use boto3 when you need skip logic, pagination, or better auditability.
• Treat mass table deletion as an operationally sensitive action, not a casual maintenance shortcut.