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