Skip to content
Ask AI about this
Help improve this page

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.

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.

module "rds" {
  source  = "terraform-aws-modules/rds/aws"
  version = ">=7.0.0"

  allocated_storage      = 20
  db_name                = "myapp"
  db_subnet_group_name   = "example-db-subnet-group"
  engine                 = "mysql"
  engine_version         = "8.0.41"
  family                 = "mysql8.0"
  identifier             = "abc123"
  instance_class         = "db.t3.micro"
  major_engine_version   = "8.0"
  password_wo            = "change-me-in-production"
  skip_final_snapshot    = true
  username               = "dbadmin"
  vpc_security_group_ids = ["sg-12345678"]
}

Use AWS provider resources directly. See docs for the resources involved: aws_db_instance.

resource "aws_db_instance" "this" {
  allocated_storage               = 20
  enabled_cloudwatch_logs_exports = ["general", "slowquery"]
  engine                          = "mysql"
  identifier                      = "pofix-abc123"
  instance_class                  = "db.t3.micro"
  monitoring_interval             = 60
  monitoring_role_arn             = "arn:aws:iam::123456789012:role/example-role"
  password                        = "ChangeMe123!"
  skip_final_snapshot             = true
  username                        = "dbadmin"
}

What this control checks

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

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: rds_db_instance_backup_retention_period_less_than_7

  • Checkov Check: CKV_AWS_133

  • Powerpipe Control: aws_compliance.control.rds_db_instance_backup_retention_period_less_than_7

  • Prowler Check: rds_instance_backup_enabled

  • AWS Security Hub Controls: RDS.11, RDS.50

  • KICS Query: 1dc73fb4-5b51-430c-8c5f-25dcf9090b02

  • Trivy Check: AWS-0077

Last reviewed: 2026-03-09