RDS Automated Backups Disabled: Why It Matters and How to Fix It

An RDS instance with automated backups disabled is a database operating without a safety net. AWS gives you a built-in mechanism to recover from accidental deletes, bad migrations, and ransomware, and turning it off removes that mechanism entirely. This check catches the configuration before it becomes the reason an incident turns into a disaster.

---

What this check detects

The rds_noautomatedbackups check looks at every RDS DB instance in your account and inspects the backup retention period. When this value is set to 0, automated backups are disabled. Lensix flags those instances as a finding.

Automated backups in RDS do two things:

• They take a daily snapshot of your instance during the backup window you define.
• They continuously capture transaction logs, which is what enables point-in-time recovery (PITR) down to roughly a 5-minute granularity.

Set the retention to 0 and both features stop. You lose the daily snapshots and the ability to roll back to a specific moment before something went wrong.

---

Why it matters

Backups are boring right up until the moment you need one. Here are the scenarios where a disabled backup turns a recoverable problem into permanent data loss.

Accidental deletes and bad migrations

A developer runs a DELETE without a WHERE clause. A migration script drops the wrong column. An application bug truncates a table. With PITR you restore to a new instance at the timestamp just before the mistake and recover the data. Without it, the data is gone unless you happened to take a manual snapshot recently.

Ransomware and malicious deletion

If an attacker gains access to your database, encrypting or wiping the data is a common play. Automated backups stored by AWS are not directly writable from your application credentials, so they give you a recovery path that does not depend on the compromised instance. No backups means you are negotiating or rebuilding from scratch.

Compliance and audit failures

Frameworks like SOC 2, PCI DSS, and HIPAA expect documented backup and recovery controls. An instance with backups disabled is a direct finding in most audits, and it undermines any recovery point objective (RPO) you have committed to customers.

---

How to fix it

Enabling automated backups is a single configuration change: set the backup retention period to a value greater than zero. AWS supports 1 to 35 days.

Using the AWS CLI

Set a 7-day retention period on a single instance:

aws rds modify-db-instance \
  --db-instance-identifier my-production-db \
  --backup-retention-period 7 \
  --apply-immediately

To set a specific backup window so the daily snapshot runs during low-traffic hours (times are UTC):

aws rds modify-db-instance \
  --db-instance-identifier my-production-db \
  --backup-retention-period 7 \
  --preferred-backup-window "03:00-04:00" \
  --apply-immediately

Using the AWS Console

1. Open the RDS console and select Databases.
2. Choose the instance, then click Modify.
3. Scroll to Backup and set Backup retention period to 7 days or more.
4. Optionally set a backup window during off-peak hours.
5. Click Continue, choose when to apply, and confirm.

Using Terraform

In Terraform, the retention period is controlled by backup_retention_period. The default for aws_db_instance is 0 for some configurations, so set it explicitly:

resource "aws_db_instance" "production" {
  identifier              = "my-production-db"
  engine                  = "postgres"
  instance_class          = "db.t3.medium"
  allocated_storage       = 100

  backup_retention_period = 7
  backup_window           = "03:00-04:00"
  deletion_protection     = true
  skip_final_snapshot     = false
  final_snapshot_identifier = "my-production-db-final"
}

Verify the change

aws rds describe-db-instances \
  --db-instance-identifier my-production-db \
  --query 'DBInstances[0].BackupRetentionPeriod'

A return value of 7 confirms automated backups are active.

---

How to prevent it from happening again

Fixing one instance is easy. Making sure no one ever ships a database with backups off takes guardrails.

Block it in your IaC pipeline

Add a policy-as-code rule that fails the build when backup_retention_period is zero. Here is a Checkov-style custom check using OPA/Rego for Terraform plans:

package rds.backups

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_db_instance"
  retention := resource.change.after.backup_retention_period
  retention < 1
  msg := sprintf("RDS instance '%s' has automated backups disabled", [resource.address])
}

Checkov also ships a built-in check, CKV_AWS_133, that ensures the retention period is set. Enable it in your CI run:

checkov -d . --check CKV_AWS_133

Enforce with an AWS Config rule

The managed rule db-instance-backup-enabled evaluates every RDS instance and reports non-compliant ones. Combine it with an SSM remediation action to auto-enable backups, or route the finding to your alerting channel.

aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "rds-backup-enabled",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "DB_INSTANCE_BACKUP_ENABLED"
    },
    "Scope": {
      "ComplianceResourceTypes": ["AWS::RDS::DBInstance"]
    }
  }'

Set an organization-wide default

If you provision databases through a module or a Service Catalog product, bake a non-zero retention period into the template and do not expose 0 as a valid input. Teams should have to make a deliberate effort to disable backups, not accidentally inherit a zero default.

---

Best practices

• Retain for at least 7 days. One day of retention technically passes the check, but it gives you almost no recovery window. Seven days handles a weekend plus the time it takes to notice a problem. Sensitive workloads often warrant the full 35.
• Schedule backups during low-traffic windows. The daily snapshot adds I/O. Run it when your application is quiet.
• Use Multi-AZ for production. Backups protect data; Multi-AZ protects availability. They solve different problems, and serious workloads need both.
• Test your restores. A backup you have never restored is a hope, not a recovery plan. Periodically restore a snapshot to a throwaway instance and confirm the data is intact.
• Copy critical snapshots across regions or accounts. For your most important databases, automated backups in a single region are not enough. Cross-region or cross-account snapshot copies protect against region-wide events and account compromise.
• Keep deletion protection on. Backups stop you losing data inside a live instance. Deletion protection stops you losing the instance itself.

Enabling automated backups costs you a few minutes and a small amount of storage. The alternative cost, an unrecoverable production database, is the kind of incident that ends up in a postmortem read by the whole company. Turn them on, set a sensible retention, and put a gate in front of every new instance so the question never comes up again.