RDS.50: RDS clusters should have adequate backup retention

What does AWS Security Hub RDS.50 check?

RDS.50 checks whether an RDS DB cluster's BackupRetentionPeriod meets a minimum threshold. The minimumBackupRetentionPeriod parameter defaults to 7 days and accepts values from 7 to 35; the control reports FAILED for any cluster below it. It applies to AWS::RDS::DBCluster across all cluster engines (Aurora, DocumentDB, Neptune).

Why does RDS.50 matter?

A too-short window quietly defeats the purpose of having backups. Data corruption, a bad schema migration, or an accidental bulk delete is often not noticed for several days — and if the recovery window is one day, the only restore points still available by the time you notice are already corrupted. Seven days is the floor that gives a team a realistic chance to detect a problem and roll back to a clean state. The feature is free up to the size of provisioned storage, so a longer window is almost pure upside.

How do I fix RDS.50?

1. Set an adequate window with modify-db-cluster --backup-retention-period 7 (or higher to match your RPO).
2. Confirm the backup window falls in a low-traffic period.
3. Default the retention into IaC so new clusters inherit it.
4. Use AWS Backup for longer or cross-Region retention where compliance demands it.

# 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