Fix Unencrypted EBS Volumes in AWS | Lensix

TL;DR

This check flags EBS volumes that store data without encryption at rest, leaving snapshots and underlying disks exposed if access controls slip. Fix it by creating an encrypted copy of the volume (or snapshot), then enable EBS encryption by default for the account and region.

An EBS volume backs the disk of nearly every EC2 instance you run. When that volume is unencrypted, the data on it sits in plaintext on AWS-managed storage, and every snapshot you take inherits that same plaintext state. The ebs_unencrypted check looks at each volume in your account and reports any that lack encryption at rest.

This is one of those findings that looks low-priority until you trace where the data actually ends up. A single unencrypted volume can spawn dozens of unencrypted snapshots, which can be copied across regions, shared with other accounts, or restored months later by someone who has no idea the data was never protected.

What this check detects

The check inspects the Encrypted attribute on every EBS volume in the target region. If the attribute is false, the volume is flagged. That is the whole detection logic, but the implications run deeper than the boolean suggests.

EBS encryption uses AWS KMS keys to encrypt:

Data at rest inside the volume
Data moving between the volume and the instance
All snapshots created from the volume
All volumes created from those snapshots

When a volume is unencrypted, none of that protection applies. The encryption state is also immutable for an existing volume, which is why remediation involves creating a new encrypted resource rather than flipping a switch.

Note: EBS encryption is essentially free in terms of performance. AWS reports no meaningful latency or throughput penalty, and the KMS API calls for volume operations do not count against your normal KMS request costs in most cases. There is rarely a technical reason to leave a volume unencrypted.

Why it matters

Encryption at rest is a defense-in-depth control. It does not stop someone who already has valid EC2 access to a running instance, but it protects you in the scenarios where your other controls have failed or were never tight enough.

Snapshot sprawl and accidental sharing

The most common real-world exposure comes from snapshots. Teams take snapshots for backups, then share them across accounts for migrations or testing. An unencrypted snapshot can be marked public, and there have been multiple incidents where companies leaked customer data this way. An encrypted snapshot cannot be made public at all, so encryption removes an entire class of mistake.

Warning: You cannot share an encrypted snapshot publicly, and sharing it with another account requires granting that account access to the KMS key. This is a feature, not a limitation. It forces a deliberate decision every time data leaves your boundary.

Compliance and audit findings

Encryption at rest is an explicit requirement under PCI DSS, HIPAA, SOC 2, FedRAMP, and most internal security baselines. An unencrypted volume holding regulated data is a finding that auditors will write up, and remediating it under audit pressure is far more painful than doing it ahead of time.

Physical and infrastructure-layer risk

AWS does not let customers see the physical disks, but compliance frameworks still treat at-rest encryption as the control that addresses media reuse, hardware decommissioning, and storage-layer access by the provider. Encryption lets you check that box honestly.

How to fix it

You cannot encrypt an existing volume in place. The process is: snapshot the volume, copy the snapshot with encryption enabled, create a new volume from the encrypted snapshot, then swap it onto the instance.

Danger: Detaching a volume and swapping disks involves stopping the instance and modifying its block device mappings. Do this in a maintenance window, and confirm you have a verified snapshot before detaching anything. A mistake in device mapping can leave the instance unbootable.

Step 1: Snapshot the unencrypted volume

aws ec2 create-snapshot \
  --volume-id vol-0abc123456789 \
  --description "pre-encryption snapshot" \
  --query SnapshotId --output text

Wait for the snapshot to reach completed state:

aws ec2 wait snapshot-completed --snapshot-ids snap-0def456789

Step 2: Copy the snapshot with encryption enabled

aws ec2 copy-snapshot \
  --source-region us-east-1 \
  --source-snapshot-id snap-0def456789 \
  --encrypted \
  --kms-key-id alias/ebs-default \
  --description "encrypted copy" \
  --query SnapshotId --output text

If you omit --kms-key-id, AWS uses the default aws/ebs managed key. For most workloads a customer-managed key (CMK) is the better choice because it gives you control over key rotation, access policy, and cross-account grants.

Step 3: Create an encrypted volume from the new snapshot

aws ec2 create-volume \
  --snapshot-id snap-0encrypted123 \
  --availability-zone us-east-1a \
  --volume-type gp3 \
  --query VolumeId --output text

The new volume inherits encryption from the snapshot, so no extra flag is needed here.

Step 4: Swap the volume onto the instance

# Stop the instance
aws ec2 stop-instances --instance-ids i-0instance123

# Detach the old unencrypted volume
aws ec2 detach-volume --volume-id vol-0abc123456789

# Attach the new encrypted volume at the same device name
aws ec2 attach-volume \
  --volume-id vol-0newencrypted \
  --instance-id i-0instance123 \
  --device /dev/xvda

# Start the instance back up
aws ec2 start-instances --instance-ids i-0instance123

Use the exact device name the original volume occupied. For the root volume on most Amazon Linux and Ubuntu AMIs that is /dev/xvda or /dev/sda1. Verify with aws ec2 describe-instances before detaching.

Tip: For fleets, skip the manual dance entirely. Create an encrypted AMI with aws ec2 create-image, then use aws ec2 copy-image --encrypted to produce an encrypted base image. Launch replacement instances from it and let your autoscaling or blue-green deployment handle the cutover. This is far safer than detaching disks on live machines.

How to prevent it from happening again

The single most effective control is turning on EBS encryption by default. Once enabled, every new volume in that region is encrypted automatically, with no developer action required.

Enable encryption by default per region

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

# Set the default KMS key for new volumes
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id alias/ebs-default \
  --region us-east-1

Warning: Encryption by default is a per-region, per-account setting. Enabling it in us-east-1 does nothing for eu-west-1. Roll it out across every region you use, and use an SCP or Config rule to keep it on.

Enforce it across the organization with an SCP

This Service Control Policy denies the creation of any unencrypted volume across every account in the organization:

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

Catch it in IaC before deploy

In Terraform, always set encrypted = true on EBS resources and root block devices:

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

Then enforce it in CI with a policy-as-code tool. A Checkov scan in your pipeline will fail the build on an unencrypted volume:

checkov -d ./terraform --check CKV_AWS_3

Tip: Layer the controls. Encryption by default handles the console and quick CLI work, the SCP blocks anything that slips through, and the CI gate gives developers fast feedback before a plan ever reaches an account. Any one of these alone has gaps. Together they close them.

Best practices

Use customer-managed KMS keys for sensitive data. The default aws/ebs key works, but a CMK gives you key rotation control, auditable key policies, and the ability to revoke access by disabling the key.
Encrypt snapshots and AMIs too. An encrypted volume with an unencrypted backup defeats the purpose. Audit your snapshot inventory, not just live volumes.
Separate keys by environment or data sensitivity. Production and development should not share a single KMS key. Scoped keys limit blast radius if a key policy is misconfigured.
Monitor for drift. Encryption by default does not retroactively encrypt existing volumes, and someone can disable the setting. Run continuous checks so a new unencrypted volume gets caught within minutes, not at the next audit.
Plan key access for cross-account workflows early. If you share encrypted snapshots between accounts, the receiving account needs a KMS grant. Decide on that key strategy before you have a migration deadline forcing the decision.

Encryption at rest for EBS is one of the cheapest, lowest-friction security wins in AWS. The cost is effectively zero, the performance impact is negligible, and the control closes off a recurring source of data leaks. Turn it on by default, enforce it with policy, and clean up the existing unencrypted volumes on a schedule.

Unencrypted EBS Volume: Why It Matters and How to Fix It