RDS Snapshot Not Encrypted: Why It Matters and How to Fix It

Your production database might be encrypted, but that protection does not automatically extend to every copy of it. RDS snapshots are full point-in-time backups, and a manual snapshot created from an unencrypted instance, or copied without specifying a key, sits on disk in plaintext. That snapshot contains the same customer records, credentials, and PII as the live database, just without the access controls and monitoring you put around the running instance.

The rds_snapshotunencrypted check looks at your manual RDS snapshots and reports any that do not have encryption at rest enabled.

---

What this check detects

Lensix queries the snapshots in your account and inspects the Encrypted attribute on each manual snapshot. When that value is false, the snapshot data is stored unencrypted on the underlying EBS volumes that back RDS. The check fires for manual snapshots specifically, since those are the ones you create and retain deliberately, often for long periods and often shared across accounts or regions.

This applies to both Amazon RDS and Amazon Aurora cluster snapshots. The mechanics differ slightly between the two, which we cover in the remediation section.

---

Why it matters

Encryption at rest protects data on the physical media. Without it, the snapshot is one access-control mistake away from disclosure. A few realistic scenarios:

• Snapshot sharing gone wrong. RDS lets you share manual snapshots with other AWS accounts. Unencrypted snapshots can even be shared publicly. A single misconfigured ModifyDBSnapshotAttribute call can expose a full database backup to every account on AWS. This has happened to real companies, and it is one of the more common ways database contents leak.
• Overly broad IAM. An engineer or compromised role with rds:RestoreDBInstanceFromDBSnapshot can spin up a new instance from your snapshot and read everything in it. With encryption, they also need kms:Decrypt on the key, which gives you a second control point and an audit trail in CloudTrail.
• Compliance gaps. PCI DSS, HIPAA, SOC 2, and GDPR all expect encryption of data at rest, and they do not carve out backups. An unencrypted snapshot of a PCI-scoped database is a finding, even if the live instance is encrypted.
• Cross-region copies. Teams copy snapshots to other regions for disaster recovery. An unencrypted snapshot replicated to a second region doubles the exposure surface for the same data.

---

How to fix it

You cannot encrypt a snapshot in place. The remediation is to copy the unencrypted snapshot into a new encrypted one using a KMS key, validate it, then remove the original.

Step 1: Identify the unencrypted snapshots

aws rds describe-db-snapshots \
  --snapshot-type manual \
  --query "DBSnapshots[?Encrypted==\`false\`].[DBSnapshotIdentifier,DBInstanceIdentifier,SnapshotCreateTime]" \
  --output table

For Aurora, use cluster snapshots instead:

aws rds describe-db-cluster-snapshots \
  --snapshot-type manual \
  --query "DBClusterSnapshots[?StorageEncrypted==\`false\`].[DBClusterSnapshotIdentifier,DBClusterIdentifier]" \
  --output table

Step 2: Copy to an encrypted snapshot

Pick a customer managed KMS key (recommended over the AWS managed aws/rds key, since a CMK gives you control over key policy, rotation, and grants). Then copy:

aws rds copy-db-snapshot \
  --source-db-snapshot-identifier mydb-manual-2024-06 \
  --target-db-snapshot-identifier mydb-manual-2024-06-encrypted \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd1234-...  \
  --copy-tags

For an Aurora cluster snapshot:

aws rds copy-db-cluster-snapshot \
  --source-db-cluster-snapshot-identifier mycluster-manual-2024-06 \
  --target-db-cluster-snapshot-identifier mycluster-manual-2024-06-encrypted \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd1234-... \
  --copy-tags

Step 3: Confirm the copy is encrypted and complete

aws rds describe-db-snapshots \
  --db-snapshot-identifier mydb-manual-2024-06-encrypted \
  --query "DBSnapshots[0].[Status,Encrypted,KmsKeyId]" \
  --output table

Wait for Status to read available and confirm Encrypted is true before touching the original.

Step 4: Delete the unencrypted original

aws rds delete-db-snapshot \
  --db-snapshot-identifier mydb-manual-2024-06

Fixing the root cause: the instance

If the snapshot was unencrypted because the source instance is unencrypted, fixing snapshots one at a time is treating a symptom. You cannot enable encryption on an existing RDS instance either, so the path is to restore the encrypted snapshot into a new encrypted instance and cut over:

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier mydb-encrypted \
  --db-snapshot-identifier mydb-manual-2024-06-encrypted

---

How to prevent it from happening again

The durable fix is to make encrypted-by-default the only option, both at the source and in your tooling.

Encrypt instances by default with Terraform

If the instance is encrypted, its snapshots will be too. Set this in your module so it is never left to chance:

resource "aws_db_instance" "main" {
  identifier        = "mydb"
  engine            = "postgres"
  instance_class    = "db.t3.medium"
  allocated_storage = 50

  storage_encrypted = true
  kms_key_id        = aws_kms_key.rds.arn

  # ... other settings
}

Block unencrypted instances with an SCP or policy-as-code

A Service Control Policy can deny the creation of unencrypted RDS instances across an entire AWS Organization:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedRDS",
      "Effect": "Deny",
      "Action": [
        "rds:CreateDBInstance",
        "rds:CreateDBCluster"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "rds:StorageEncrypted": "false"
        }
      }
    }
  ]
}

Gate it in CI/CD

Catch the problem before it ever reaches AWS by scanning Terraform plans in your pipeline. With Checkov, the relevant check is CKV_AWS_16 (RDS encryption):

checkov -d . --check CKV_AWS_16

---

Best practices

• Encrypt at the source. Encrypted instances produce encrypted snapshots automatically. This removes the per-snapshot remediation toil entirely.
• Prefer customer managed KMS keys. A CMK lets you control the key policy, enable automatic rotation, and audit every decrypt call. It also makes cross-account snapshot sharing possible in a controlled way, since you can grant key access deliberately.
• Audit snapshot sharing attributes. Regularly check describe-db-snapshot-attributes for snapshots shared with other accounts or marked public, and confirm each share is intentional.
• Apply lifecycle policies. Use AWS Backup with a backup plan rather than ad hoc manual snapshots. Backup-managed copies enforce encryption settings consistently and expire on schedule, so stale unencrypted backups do not pile up.
• Tag and track. Use --copy-tags when copying so ownership and data-classification tags follow the snapshot. That makes it far easier to prioritize which findings actually contain sensitive data.
• Plan key access for disaster recovery. If you copy encrypted snapshots cross-region, the destination region needs a usable KMS key. Set up the DR-region key and grants before an incident, not during one.

Encrypting an RDS snapshot is cheap and has no performance impact on the live database. The cost of skipping it shows up only when something goes wrong, and by then the data has already moved.