Skip to main content
emnode / learn
Compliance Medium severity

AWS Security Hub · RDS

RDS.14: Aurora has no backtracking safety net

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub RDS.14 check?

RDS.14 checks whether an Aurora MySQL cluster has backtracking enabled. It reports FAILED for any Aurora MySQL cluster with BacktrackWindow set to 0.

Why does RDS.14 matter?

Backtracking lets you rewind an entire Aurora MySQL cluster to a point in the last 72 hours in seconds, against the same endpoint, with no new cluster and no application reconfiguration. Without it, recovering from a bad migration, an accidental DROP TABLE, or a runaway script means a snapshot restore: 30-60 minutes of downtime for a sizeable cluster, a new endpoint, and data loss since the last backup. The control only applies to Aurora MySQL — Aurora PostgreSQL has no equivalent.

How do I fix RDS.14?

  1. Inventory Aurora MySQL clusters where BacktrackWindow is 0, prioritising production.
  2. Because backtracking cannot be enabled on a running cluster, clone with restore-db-cluster-to-point-in-time using --restore-type copy-on-write and --backtrack-window 86400 (24h) or 259200 (72h), then cut over.
  3. Run a tabletop rewind in staging so the recovery path is proven before you need it.
  4. Prevent recurrence with an SCP denying CreateDBCluster on aurora-mysql when BacktrackWindow is absent or zero, plus the Config rule rds-cluster-backtracking-enabled.

Remediation script · bash

# Clone the cluster with a 24-hour backtrack window, then promote.
aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier prod-orders-cluster \
  --db-cluster-identifier prod-orders-cluster-bt \
  --restore-type copy-on-write \
  --use-latest-restorable-time \
  --backtrack-window 86400

# Wait for the clone to be available, then add an instance.
aws rds create-db-instance \
  --db-instance-identifier prod-orders-cluster-bt-1 \
  --db-cluster-identifier prod-orders-cluster-bt \
  --db-instance-class db.r6g.xlarge \
  --engine aurora-mysql

# Trigger an actual backtrack (DESTRUCTIVE — loses all writes since target time).
aws rds backtrack-db-cluster \
  --db-cluster-identifier prod-orders-cluster-bt \
  --backtrack-to 2026-05-15T14:32:00Z

Full walkthrough (console steps, edge cases and verification) in the lesson Enable Aurora MySQL backtracking.

Is RDS.14 a false positive?

Running modify-db-cluster --backtrack-window on an existing cluster does not work — the window can only be set at creation, so a live cluster failing RDS.14 always requires a clone-and-cutover rather than an in-place toggle.

Full lesson Enable Aurora MySQL backtracking Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for RDS controls ↗ Check your own account for RDS.14 →

More RDS controls

  • RDS.1 An RDS snapshot is shared publicly
  • RDS.2 An RDS instance is publicly accessible from the internet
  • RDS.3 RDS DB instances should be encrypted at rest
  • RDS.4 RDS snapshots should be encrypted at rest
  • RDS.5 RDS DB instances should use multiple AZs
  • RDS.6 RDS lacks enhanced monitoring
  • RDS.7 RDS clusters should have deletion protection
  • RDS.8 RDS DB instances should have deletion protection
  • RDS.9 RDS engine logs are not shipped to CloudWatch
  • RDS.10 RDS relies on long-lived database passwords
  • RDS.11 RDS instances should have automatic backups
  • RDS.12 IAM auth should be configured for RDS clusters