Skip to main content
emnode
Compliance Medium severity

AWS Security Hub · RDS

RDS.3: RDS DB instances should be encrypted at rest

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub RDS.3 check?

RDS.3 flags any RDS DB instance where storage encryption at rest is not enabled. It is scoped to AWS::RDS::DBInstance but can also raise findings for Aurora, Neptune, and DocumentDB instances. It maps to CIS AWS Foundations 2.3.1 and a wide set of NIST 800-53 data-protection controls.

Why does RDS.3 matter?

Encryption at rest scrambles the data on the disks underneath the database (AES-256) so a stolen snapshot, mis-shared backup, or compromised volume yields ciphertext rather than customer records. It protects the instance, its automated backups, read replicas, and every snapshot. The setting is permanent at creation (there is no modify-db-instance flag to turn it on later), so unencrypted databases accumulate quietly (a POC that became production, a restore from an old unencrypted snapshot) and each is a standing audit finding under SOC 2, ISO 27001, PCI, and HIPAA.

How do I fix RDS.3?

  1. Take a snapshot of the unencrypted instance.
  2. Copy the snapshot with copy-db-snapshot --kms-key-id, which produces an encrypted copy.
  3. Restore a new instance from the encrypted snapshot, then cut clients over to the new endpoint and retire the old instance.
  4. Enable a default KMS key in IaC templates so new databases are encrypted from creation.

Remediation script · bash

# 1. Find unencrypted databases across engines (sample: RDS, Redshift, OpenSearch).
aws rds describe-db-instances \
  --query 'DBInstances[?StorageEncrypted==`false`].DBInstanceIdentifier' --output text
aws redshift describe-clusters \
  --query 'Clusters[?Encrypted==`false`].ClusterIdentifier' --output text

# 2. Immutable engine (RDS): snapshot, copy WITH a KMS key, restore the new instance.
SRC=prod-orders-db; KEY=alias/db-encryption
aws rds create-db-snapshot --db-instance-identifier $SRC --db-snapshot-identifier ${SRC}-snap
aws rds wait db-snapshot-completed --db-snapshot-identifier ${SRC}-snap
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier ${SRC}-snap \
  --target-db-snapshot-identifier ${SRC}-snap-enc \
  --kms-key-id $KEY
aws rds wait db-snapshot-completed --db-snapshot-identifier ${SRC}-snap-enc
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier ${SRC}-enc --db-snapshot-identifier ${SRC}-snap-enc

# 3. In-place engine (Redshift): background migration (cluster is read-only during it).
aws redshift modify-cluster --cluster-identifier analytics-prod \
  --encrypted --kms-key-id $KEY

# 4. Prevent recurrence: deploy the rds-storage-encrypted Config rule to flag any
#    new unencrypted RDS instance (back it with an SCP to deny creation outright).
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "rds-storage-encrypted",
  "Source": {"Owner": "AWS", "SourceIdentifier": "RDS_STORAGE_ENCRYPTED"}
}'

Full walkthrough (console steps, edge cases and verification) in the lesson Encrypt AWS databases at rest.

Is RDS.3 a false positive?

Encryption cannot be toggled on an existing instance; there is no in-place flag. A database failing RDS.3 always requires the snapshot-copy-with-KMS-and-restore migration, not a quick modify call.

Part of the learning path Encrypt everything
  • RDS.1 An RDS snapshot is shared publicly
  • RDS.2 An RDS instance is publicly accessible from the internet
  • 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
  • RDS.13 RDS is not receiving automatic minor security patches