DynamoDB Idle Table Cleanup – CloudFix Support

Opportunity Name:

DynamoDB Idle Table Cleanup

AWS Resource Type:

Amazon DynamoDB

Opportunity Description:

CloudFix identifies idle DynamoDB tables that are incurring costs but have not been used recently, allowing customers to eliminate unnecessary storage and compute expenses.

This Finder analyzes AWS Cost and Usage Report (CUR) data, CloudWatch metrics, and DynamoDB API data to detect tables that haven’t processed read or write operations within a configurable lookback period (default: 30 days).

Key Benefits:

• Reduce DynamoDB costs by deleting unused tables.
• Automated identification of tables with no recent activity.
• Customizable lookback periods (7, 30, or 60 days) for flexible analysis.

Criteria for Identifying the Opportunity:

CloudFix identifies DynamoDB tables that can be safely deleted based on the following criteria:

1. Table Exists: The DynamoDB table is still active (verified via DescribeTable API).
2. Minimum Age Requirement: The table must be at least 30 days old.
3. No Recent Activity:
   • The table has not performed any read or write operations for the entire lookback period (default: 30 days).
   • CloudWatch metrics (ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits) confirm zero activity.
4. Annualized Cost ≥ $100:
   • If the table incurs an annualized cost of $100 or more, it is considered a cost-saving opportunity.
5. Table Is Not Tagged “Do Not Fix”:
   • If the table has the cloudfix:dontFixIt tag, CloudFix will exclude it from deletion.
6. No Active Streams, GSIs, or Triggers:
   • Tables with active DynamoDB Streams, Global Secondary Indexes (GSIs), or event Triggers are excluded, since these usually indicate the table is wired into a live workload even when read/write capacity looks idle.
7. No Active Replication / Global Table Configuration:
   • Tables that are part of an active global table (multi-region replication) configuration are excluded.
8. Protected Prefixes Excluded:
   • Additional naming-based filters keep tables that match protected prefixes (e.g., production naming conventions) out of the candidate list, on top of the tag-based exclusion above.

Potential Savings:

Since deleting an idle table eliminates its cost entirely, the estimated savings are 100% of the table’s annualized cost.

For example, if a DynamoDB table incurs $1,000 per year, deleting it saves the full $1,000.

What Happens When the Fixer Is Executed?

When CloudFix executes the fix, the SSM Automation runbook performs the following steps, in order:

1. Verify Table Status is ACTIVE using the DescribeTable API.
2. Start an AWS Backup job for the table (backup:StartBackupJob), tagging the resulting recovery point with the fixer ID, execution date, and original table name.
3. Wait for the backup job to complete before proceeding.
4. Delete the Table using the AWS DeleteTable API.
5. Verify Deletion by waiting for the table to reach DELETING/DELETED status via DescribeTable.

If the backup step, the deletion step, or the wait for deletion times out or fails, CloudFix automatically deletes the just-created recovery point (so no orphaned backup is left behind) and publishes an SNS failure notification instead of deleting the table.

Is It Possible to Roll Back Once CloudFix Implements the Fixer?

Yes, via the AWS Backup recovery point CloudFix creates automatically before deletion — this is not a one-click restore inside CloudFix, but a manual restore through AWS Backup:

• Before the table is deleted, the fixer takes an AWS Backup snapshot (recovery point) of the table.
• The recovery point is retained in the “Default” backup vault, moving to cold storage after 7 days by default, and being deleted after 97 days by default (both configurable — see Finder Configuration Parameters below).
• To restore, use the AWS Backup restore workflow to recreate the table from the recovery point within the retention window.
• If the fixer itself fails partway through (for example, the delete step times out), CloudFix automatically deletes the recovery point it just created and sends an SNS alert — it does not leave a half-finished state.

If Point-in-Time Recovery (PITR) is separately enabled on the table, that provides additional protection but is not required — the fixer's own AWS Backup snapshot is what makes rollback possible by default. See Troubleshooting: “DynamoDB Delete Idle Tables” Fixer Fails at AWS Backup StartBackupJob if the backup step itself fails with an AccessDeniedException.

Can CloudFix Implement the Fix Automatically Once I Accept the Recommendation?

Yes. CloudFix will automatically delete the table once the user accepts the recommendation.

Does This Fix Require Downtime?

Yes. DeleteTable runs only after the AWS Backup job completes, and once it runs the table is unavailable until it is manually restored from the AWS Backup recovery point — this is not a zero-downtime operation.

Recommendation Report

CloudFix generates a detailed recommendation report containing:

1. Table Information:

   • Table Name
   • Region
   • Account ID
   • Creation Date
   • Current Status

2. Cost & Savings Data:

   • Annualized On-Demand Cost
   • Projected Savings ($ & %)
   • Break-even Analysis (if applicable)

3. Activity Summary:

   • Last Read/Write Operation Timestamp
   • Average Daily Read/Write Capacity Usage

4. Visualizations:

   • Historical activity over 7, 30, and 60 days
   • Projected savings over 1 year

5. Backup Configuration:

   • Move to Cold Storage After (days)
   • Delete After (days) — the effective rollback window for the pre-delete AWS Backup recovery point

Finder Configuration Parameters:

Parameter	Default	Description
Lookback Period	30 days	Defines the number of days to check for table activity. Options: 7, 30, 60 days.
Max Units	0	Maximum daily read/write capacity allowed before the table is considered active.
Annual Cost Threshold	$100	Minimum annual spend required to qualify for deletion.
Move to Cold Storage After	7 days	Days before the pre-delete AWS Backup recovery point transitions to cold storage.
Delete After	97 days	Days before the pre-delete AWS Backup recovery point itself is deleted, ending the rollback window.

Additional Resources:

• AWS DynamoDB Pricing
• AWS DynamoDB DeleteTable API
• AWS Backup: Restoring a Resource
• Troubleshooting: “DynamoDB Delete Idle Tables” Fixer Fails at AWS Backup StartBackupJob (AccessDeniedException)