DynamoDB.4: DynamoDB tables should be in a backup plan

What does AWS Security Hub DynamoDB.4 check?

DynamoDB.4 checks that a table is covered by an AWS Backup plan. It reports FAILED when the table belongs to no backup plan, which is distinct from the PITR that satisfies DynamoDB.2.

Why does DynamoDB.4 matter?

A governed AWS Backup plan gives you scheduled backups with a defined retention policy and an optional locked vault — protection that survives well beyond PITR's 35-day in-service window and is independent of the table itself. Relying on PITR alone leaves a gap that a deliberate retention and recovery policy fills.

How do I fix DynamoDB.4?

1. Confirm which tables are not in any backup plan.
2. Assign them to a backup plan using tag-based resource selection so coverage scales automatically as tables are added.
3. Choose retention and consider a locked vault to meet compliance requirements.
4. Verify recovery points land in the vault.

# Set a 7-day backup floor on production databases below it (skip read replicas).
for db in $(aws rds describe-db-instances \
    --query 'DBInstances[?ReadReplicaSourceDBInstanceIdentifier==`null` && BackupRetentionPeriod<`7`].DBInstanceIdentifier' --output text); do
  aws rds modify-db-instance --db-instance-identifier "$db" \
    --backup-retention-period 7 --no-apply-immediately
done

# Turn on DynamoDB point-in-time recovery (instant, no downtime).
aws dynamodb update-continuous-backups --table-name prod-orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

# Stop any snapshot in the account from being shared publicly, ever.
aws ec2 enable-snapshot-block-public-access --state block-all-sharing