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

EBS snapshots are point-in-time copies of your block storage volumes. They power your backups, your AMIs, and your disaster recovery process. The problem is that a snapshot is a full copy of everything on the volume, including credentials, database files, application secrets, and customer data. If that copy sits in your account unencrypted, anyone who can read it can read the data inside it.

The ebs_snapshotunencrypted check looks at every EBS snapshot in your account and flags the ones that are not encrypted at rest. It is a simple signal, but the consequences of ignoring it are not.

---

What this check detects

The check inspects each EBS snapshot and reads its Encrypted attribute. When that attribute is false, the snapshot data is stored in plaintext on AWS-managed disks. The check reports those snapshots as a finding.

You can reproduce the same logic from the CLI:

aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?Encrypted==`false`].[SnapshotId,VolumeId,StartTime,Description]' \
  --output table

Any snapshot returned by that command is what Lensix flags. Encryption status is set at creation time and cannot be toggled on an existing snapshot, which is why remediation always involves creating a new, encrypted copy.

---

Why it matters

Encryption at rest protects data when the storage layer is accessed outside your normal application path. With EBS snapshots, there are a few concrete ways that happens.

Snapshot sharing exposes plaintext data

EBS snapshots can be shared with other AWS accounts or made public. This is a common pattern for distributing AMIs or handing data to a partner. If an unencrypted snapshot is shared, the recipient gets the raw data with no key in the way. A single misconfigured ModifySnapshotAttribute call can turn an internal backup into a publicly readable copy of your production database.

It widens the blast radius of a compromised credential

If an attacker gains a role with ec2:CreateVolume and ec2:DescribeSnapshots, they can mount your snapshot data onto an instance they control and read everything on it. With an encrypted snapshot, they also need access to the KMS key, and KMS key policies give you a second, independent layer to deny that access. Encryption turns one stolen credential into two things the attacker has to defeat.

Compliance and audit requirements

Frameworks like PCI DSS, HIPAA, SOC 2, and FedRAMP expect data at rest to be encrypted. Unencrypted snapshots are a recurring audit finding because they are easy to create and easy to forget. They also tend to outlive the volumes they came from, sitting in your account for years as silent liabilities.

---

How to fix it

You cannot encrypt an existing snapshot in place. The remediation is to copy it into a new encrypted snapshot, then update anything that references the old one and delete the original.

Step 1: Copy the snapshot with encryption enabled

aws ec2 copy-snapshot \
  --source-region us-east-1 \
  --source-snapshot-id snap-0123456789abcdef0 \
  --encrypted \
  --kms-key-id alias/aws/ebs \
  --description "Encrypted copy of snap-0123456789abcdef0"

The command returns a new SnapshotId. Swap alias/aws/ebs for a customer-managed key if you want control over the key policy and rotation, which you usually should for sensitive data.

Step 2: Wait for the copy to complete

aws ec2 wait snapshot-completed \
  --snapshot-ids snap-0newencryptedid00

Step 3: Update references and delete the original

Before deleting anything, find what depends on the old snapshot. AMIs built from it, launch templates, and backup automation may point at the original ID.

# Confirm the encrypted copy exists and is complete first
aws ec2 describe-snapshots --snapshot-ids snap-0newencryptedid00 \
  --query 'Snapshots[0].[State,Encrypted]'

# Then delete the unencrypted original
aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0

Fixing the root cause: encrypt the source volume

If the snapshot came from an unencrypted volume, encrypt that volume too. You create an encrypted snapshot, then create an encrypted volume from it and attach it back to the instance.

# Create an encrypted volume from the encrypted snapshot
aws ec2 create-volume \
  --availability-zone us-east-1a \
  --snapshot-id snap-0newencryptedid00 \
  --volume-type gp3 \
  --encrypted

---

How to prevent it from happening again

The single most effective control is turning on EBS encryption by default. Once enabled, every new volume and every snapshot taken from an encrypted volume is encrypted automatically with no extra steps from the people creating them.

Enable default EBS encryption per region

aws ec2 enable-ebs-encryption-by-default --region us-east-1

# Optionally set a default CMK for the region
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id alias/my-ebs-cmk \
  --region us-east-1

# Verify
aws ec2 get-ebs-encryption-by-default --region us-east-1

Enforce it across the organization with an SCP

A Service Control Policy can deny the creation of unencrypted volumes account-wide so the setting cannot be turned off:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedEBS",
      "Effect": "Deny",
      "Action": "ec2:CreateVolume",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "ec2:Encrypted": "false"
        }
      }
    }
  ]
}

Catch it in IaC before it deploys

Bake encryption into your Terraform and reject pull requests that omit it. Here is the correct resource shape:

resource "aws_ebs_volume" "data" {
  availability_zone = "us-east-1a"
  size              = 100
  type              = "gp3"
  encrypted         = true
  kms_key_id        = aws_kms_key.ebs.arn
}

Add a policy-as-code gate in CI so this is enforced automatically. A Checkov run fails the build on unencrypted EBS resources:

checkov -d . --check CKV_AWS_3   # EBS volume encryption

---

Best practices

• Encrypt by default everywhere. Enable default EBS encryption in every region, in every account. It is free and removes the most common cause of this finding.
• Use customer-managed keys for sensitive workloads. CMKs give you key rotation, granular key policies, and per-decrypt audit logging through CloudTrail.
• Never share unencrypted snapshots. If you need to share data across accounts, copy to an encrypted snapshot first and grant the target account access to the KMS key.
• Set a snapshot lifecycle policy. Use Amazon Data Lifecycle Manager to age out old snapshots automatically. Stale unencrypted snapshots are a common source of forgotten exposure.
• Audit regularly. Snapshots accumulate quietly. Continuous scanning catches the ones that slip past your controls, especially in regions you rarely look at.

Encryption at rest is not a silver bullet, but for EBS snapshots it is one of the highest-value, lowest-effort controls you can apply. Turn it on by default and the problem mostly stops occurring.

Lensix continuously scans your AWS accounts for unencrypted EBS snapshots and surfaces them alongside the volumes and AMIs that depend on them, so you can remediate the root cause instead of chasing one snapshot at a time.