RDS DB instances backup retention period should be greater than or equal to 7
A 7-day minimum retention window gives your team enough time to detect data corruption, accidental deletion, or malicious changes before the oldest usable snapshot expires. With shorter retention, a problem discovered on Monday that started the previous Wednesday may already be unrecoverable.
Point-in-time recovery depends on automated backups. Setting backup_retention_period to 0 disables them entirely, removing your ability to restore to any arbitrary second within the retention window. Even a value of 1 leaves almost no margin for weekend incidents or delayed incident detection.
Retrofit consideration
Increasing backup_retention_period on an existing instance does not cause downtime, but may temporarily increase storage costs and trigger a brief I/O suspension during the initial backup window if automated backups were previously disabled.
Implementation
Choose the approach that matches how you manage Terraform.
This control is enforced automatically with Compliance.tf modules. Start free trial
If you use terraform-aws-modules/rds/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.
In the aws_db_instance resource, backup_retention_period must be set to 7 or higher. A value of 0 disables automated backups entirely and fails. Any value from 1 through 6 also fails. Valid passing values range from 7 to 35 (the AWS maximum). If backup_retention_period is omitted, Terraform defaults it to 0 for new instances, which fails this control. Also confirm that backup_window is set to a preferred maintenance window so backups occur during low-traffic periods. For read replicas, backup_retention_period can only be set on the source instance, not the replica itself.
Common pitfalls
Terraform default is 0, not 7
Omit backup_retention_period from aws_db_instance and Terraform sets it to 0, disabling automated backups entirely. Always declare it explicitly; relying on the default is the most common way this control fails in practice.
Read replicas ignore backup_retention_period
On a read replica (replicate_source_db set), backup_retention_period has no effect. Backup retention is controlled entirely by the source instance. Depending on how the policy evaluates effective configuration, the replica may still be flagged, so verify that the source instance is compliant rather than trying to fix the replica directly.
Aurora clusters use a different resource
Aurora DB instances are managed through aws_rds_cluster, not aws_db_instance, and backup_retention_period lives on the cluster resource. This control targets aws_db_instance only. If you have Aurora clusters, they need a separate check against aws_rds_cluster.
Storage cost increase with longer retention
RDS charges for backup storage that exceeds provisioned database size. Going from 1 to 7 days can noticeably increase backup storage costs on write-heavy databases with frequent transaction log generation. Factor this into cost estimates before rolling out the change fleet-wide.
Audit evidence
AWS Config rule evaluation results for db-instance-backup-enabled with backupRetentionPeriod set to a minimum of 7 are the primary evidence artifact. Console screenshots of the RDS instance configuration page showing the "Backup retention period" field at 7 days or more work as direct supporting evidence. A compliance dashboard or report from Security Hub or a CSPM tool showing historical pass/fail status across all RDS instances in all regions rounds out a continuous-compliance evidence package.
CloudTrail logs for ModifyDBInstance and CreateDBInstance confirm no instance was created or modified with a retention period below 7. Auditors may also request a full inventory of RDS instances cross-referenced against compliance scan results to confirm no exceptions exist.
Framework-specific interpretation
SOC 2: A1.3 and A1.4 cover backup, recovery, and restoration capability. A 7-day retention window helps demonstrate that recovery time and recovery point objectives are achievable, which is what Availability criteria examiners ask to see.
PCI DSS v4.0: For systems supporting a cardholder data environment, Requirement 12.10 covers incident response and recovery readiness. Maintaining RDS backups with a 7-day minimum gives you a recovery path for database-tier incidents and is the kind of evidence examiners look for when assessing CDE restoration capability.
HIPAA Omnibus Rule 2013: 45 CFR 164.308(a)(7)(ii)(A) requires covered entities to establish a data backup plan for ePHI. A 7-day retention period gives a recoverable copy sufficient to restore data following an incident, satisfying the backup plan requirement for RDS databases holding protected health information.
GDPR: Article 32(1)(c) requires the ability to restore availability and access to personal data in a timely manner following a physical or technical incident. For RDS databases holding personal data, a 7-day retention period directly supports that obligation.
NIS2 Directive (EU 2022/2555): Article 21 calls for backup management as part of broader business continuity and disaster recovery measures. For essential and important entities, automated database backups with a defined minimum retention period satisfy that component of the requirement.
NIST SP 800-53 Rev 5: CP-9 calls for backups of system-level and user-level information at a defined frequency and requires protecting backup confidentiality, integrity, and availability. The 7-day minimum provides a practical recovery window and directly addresses the backup frequency and retention requirements at Moderate impact.
NIST Cybersecurity Framework v2.0: RC.RP (Recovery Planning) expects organizations to restore systems to a known good state after an incident. Automated backups with adequate retention are how you get that capability for RDS databases.
FedRAMP Moderate Baseline Rev 4: CP-9 and CP-10 require regular backups of system-level and user-level information at defined frequencies, with retention periods tied to recovery objectives. Both controls are required at the Moderate baseline, and a 7-day window is the floor for meeting CP-9's recovery support requirement.