Skip to content
Ask AI about this
Help improve this page

RDS Aurora clusters should have backtracking enabled

Aurora backtracking is a fast undo button. When a bad migration runs, an application writes corrupt data, or an attacker modifies records, you can rewind the cluster in seconds rather than spending minutes or hours restoring from a snapshot. The recovery is in-place, so connection endpoints stay the same and application reconnection is immediate.

Cost scales with the volume of change records retained. A longer backtrack window on a high-write cluster adds up, but faster recovery can more than offset the cost during a serious incident.

Retrofit consideration

Enabling backtracking on an existing Aurora cluster requires a cluster modification that may cause brief downtime. Backtracking is only supported on Aurora MySQL-compatible clusters, not Aurora PostgreSQL, so check your engine type before applying this control broadly.

Implementation

Choose the approach that matches how you manage Terraform.

Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.

module "rds_aurora" {
  source  = "acscessentialeight.compliance.tf/terraform-aws-modules/rds-aurora/aws"
  version = ">=10.0.0,<11.0.0"

  create_db_subnet_group = true
  create_security_group  = true
  engine                 = "aurora-mysql"
  engine_version         = "8.0.mysql_aurora.3.08.0"
  instances = {
    one = {
      instance_class = "db.t4g.medium"
    }
  }
  manage_master_user_password = true
  master_username             = "root"
  name                        = "abc123"
  skip_final_snapshot         = true
  subnets                     = ["subnet-12345678", "subnet-12345678"]
  vpc_id                      = "vpc-12345678"
}


module "rds_aurora" {
  source  = "nistcsfv11.compliance.tf/terraform-aws-modules/rds-aurora/aws"
  version = ">=10.0.0,<11.0.0"

  create_db_subnet_group = true
  create_security_group  = true
  engine                 = "aurora-mysql"
  engine_version         = "8.0.mysql_aurora.3.08.0"
  instances = {
    one = {
      instance_class = "db.t4g.medium"
    }
  }
  manage_master_user_password = true
  master_username             = "root"
  name                        = "abc123"
  skip_final_snapshot         = true
  subnets                     = ["subnet-12345678", "subnet-12345678"]
  vpc_id                      = "vpc-12345678"
}

If you use terraform-aws-modules/rds-aurora/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_aurora" {
  source  = "terraform-aws-modules/rds-aurora/aws"
  version = ">=10.0.0,<11.0.0"

  create_db_subnet_group = true
  create_security_group  = true
  engine                 = "aurora-mysql"
  engine_version         = "8.0.mysql_aurora.3.08.0"
  instances = {
    one = {
      instance_class = "db.t4g.medium"
    }
  }
  manage_master_user_password = true
  master_username             = "root"
  name                        = "abc123"
  skip_final_snapshot         = true
  subnets                     = ["subnet-12345678", "subnet-12345678"]
  vpc_id                      = "vpc-12345678"
}

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

resource "aws_rds_cluster" "this" {
  backtrack_window                = 72
  cluster_identifier              = "pofix-abc123"
  db_subnet_group_name            = "example-db-subnet-group"
  enabled_cloudwatch_logs_exports = ["audit"]
  engine                          = "aurora-mysql"
  engine_version                  = "8.0.mysql_aurora.3.08.0"
  manage_master_user_password     = true
  master_username                 = "dbadmin"
  skip_final_snapshot             = true
  vpc_security_group_ids          = ["sg-12345678"]
}

What this control checks

This control validates that the aws_rds_cluster resource has backtrack_window set to a value greater than 0. The value is an integer in seconds, capped at 259200 (72 hours). A missing argument or a value of 0 fails. To pass, set backtrack_window to your desired recovery window, for example 86400 for 24 hours.

This argument only applies to Aurora MySQL-compatible clusters (engine = "aurora-mysql" or engine = "aurora"). Aurora PostgreSQL doesn't support backtracking, so scope this control to MySQL-compatible clusters accordingly.

Common pitfalls

  • Aurora PostgreSQL does not support backtracking

    Backtracking is only available for Aurora MySQL-compatible engines (aurora and aurora-mysql). Setting backtrack_window on an aws_rds_cluster with engine = "aurora-postgresql" causes the provider or API to return an error. Scope this control to MySQL-compatible clusters only.

  • Backtrack window cannot be added to cloned clusters

    Backtracking must be enabled at cluster creation time. If you create a cluster using restore_to_point_in_time or by cloning and omit backtrack_window, you can't add it later without recreating the cluster. Make sure it's in the initial resource block, not added as a follow-up change.

  • Maximum window is 72 hours

    The backtrack_window argument caps at 259200 seconds (72 hours). Setting a higher value causes an API error. If your recovery requirements extend beyond 72 hours, automated snapshots or AWS Backup plans are required in addition, backtracking alone won't cover that range.

  • Cost scales with change volume

    AWS charges per change record stored, and high-write workloads with a large backtrack_window can add up fast. Check the BacktrackChangeRecordsStored CloudWatch metric and set a billing alarm before rolling out large windows across many clusters.

Audit evidence

Auditors expect API-level evidence: DescribeDBClusters output showing a non-zero BacktrackWindow on each Aurora MySQL-compatible cluster. In the RDS console, select each Aurora cluster and confirm the Backtrack details section shows a non-zero window.

For continuous assurance, provide periodic compliance reports from your CSPM or policy-as-code pipeline. CloudTrail events for ModifyDBCluster with the BacktrackWindow parameter show when backtracking was enabled or changed, which is useful for demonstrating configuration history.

Framework-specific interpretation

Tool mappings

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

  • Compliance.tf Control: rds_db_cluster_aurora_backtracking_enabled

  • AWS Config Managed Rule: AURORA_MYSQL_BACKTRACKING_ENABLED

  • Checkov Check: CKV_AWS_326

  • Powerpipe Control: aws_compliance.control.rds_db_cluster_aurora_backtracking_enabled

  • Prowler Check: rds_cluster_backtrack_enabled

  • AWS Security Hub Control: RDS.14

Last reviewed: 2026-03-09