Skip to main content
emnode / learn
Compliance Medium severity

AWS Security Hub · RDS

RDS.26: RDS instances should be in a backup plan

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub RDS.26 check?

RDS.26 checks whether each standalone RDS DB instance is assigned to an AWS Backup plan. It runs on a periodic schedule and reports FAILED for any instance that no backup plan protects. It excludes Neptune and DocumentDB instances and RDS instances that are members of a cluster.

Why does RDS.26 matter?

This is not the same as RDS.11. An instance can pass RDS.11 with a healthy seven-day automated-backup window and still fail RDS.26, because RDS's own automated backups are managed per-instance and tied to that instance's lifecycle — delete the instance and, after the final snapshot window, they are gone. AWS Backup is a separate, centralised policy layer that survives the resource and gives one place to define frequency, retention, cross-Region/cross-account copies, and Vault Lock immutability. Resilience you cannot see centrally is resilience you cannot trust.

How do I fix RDS.26?

  1. Create or reuse an AWS Backup plan with a suitable frequency and retention.
  2. Assign the RDS instance to the plan via a resource assignment (by tag or by ARN).
  3. Confirm a backup job runs successfully against the instance.
  4. Use tag-based assignment so new instances are protected automatically.

Remediation script · bash

# Set a 7-day backup floor on production databases below it (skip read replicas).
for db in $(aws rds describe-db-instances \
    --query 'DBInstances[?ReadReplicaSourceDBInstanceIdentifier==`null` && BackupRetentionPeriod<`7`].DBInstanceIdentifier' --output text); do
  aws rds modify-db-instance --db-instance-identifier "$db" \
    --backup-retention-period 7 --no-apply-immediately
done

# Turn on DynamoDB point-in-time recovery (instant, no downtime).
aws dynamodb update-continuous-backups --table-name prod-orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

# Stop any snapshot in the account from being shared publicly, ever.
aws ec2 enable-snapshot-block-public-access --state block-all-sharing

Full walkthrough (console steps, edge cases and verification) in the lesson Configure backups and retention.

Is RDS.26 a false positive?

Built-in automated backups (RDS.11) do not satisfy RDS.26 — the control specifically requires membership in an AWS Backup plan. A database can be fully recoverable per-instance and still fail this centralised-policy check.

Part of the learning path Lock down access
  • 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