EBS Default Encryption Disabled: Why It Matters and How to Fix It

EBS default encryption is one of those settings that feels like it should be on out of the box, but it isn't. It's a per-region, per-account toggle, and until you flip it, nothing stops an engineer (or a Terraform module, or an Auto Scaling group) from launching a volume with no encryption at all. This check looks for exactly that gap.

What this check detects

The ebs_defaultencryptiondisabled check inspects the EBS encryption setting for a given AWS region and account. It calls the EC2 API to read the EBS encryption by default flag. If that flag is false, the check fails.

When default encryption is off, the encryption state of a new volume depends entirely on whoever creates it. If they forget to set --encrypted, or the snapshot they restore from was never encrypted, the volume lands on disk in plaintext. There's no warning and no block. The check exists because that default behavior quietly produces unencrypted data stores across an account.

Why it matters

EBS volumes hold the actual bytes behind your EC2 instances: databases, application data, logs, cached credentials, whatever your workloads write to disk. An unencrypted volume means that data sits on AWS-managed storage hardware with no encryption-at-rest protection that you control.

Here's where it bites in practice:

• Snapshots inherit the volume's state. An unencrypted volume produces unencrypted snapshots. Snapshots are easy to share across accounts and even make public by mistake. A public, unencrypted snapshot is a direct data leak.
• Compliance failures. PCI DSS, HIPAA, SOC 2, and FedRAMP all expect encryption at rest. An auditor finding plaintext EBS volumes is a finding you have to remediate and document, often under a deadline.
• Blast radius on key compromise. With encryption on and a customer-managed KMS key, you can revoke or disable the key to cut off access to the data. With no encryption, you have no such lever.
• Silent drift. One engineer launches an instance from an old AMI, the volume is unencrypted, and three months later it's a production database. Nobody noticed because nothing failed.

How to fix it

Option 1: AWS CLI (fastest)

Enable default encryption for the current region:

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

Verify it took effect:

aws ec2 get-ebs-encryption-by-default --region us-east-1
# Expected:
# {
#     "EbsEncryptionByDefault": true
# }

By default, AWS uses the AWS-managed key (aws/ebs). For better control, set a customer-managed KMS key as the default:

aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/your-key-id \
  --region us-east-1

# Confirm
aws ec2 get-ebs-default-kms-key-id --region us-east-1

for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  aws ec2 enable-ebs-encryption-by-default --region "$region"
  echo "Enabled default encryption in $region"
done

Option 2: AWS Console

1. Open the EC2 console and confirm the region selector (top right) is set to the region you want.
2. In the left navigation, scroll to the bottom and click EC2 Dashboard.
3. On the right side, find Account attributes and click Data protection and security (or Settings in older layouts).
4. Under EBS encryption, click Manage.
5. Check Enable, optionally select a customer-managed KMS key, and click Update EBS encryption.
6. Repeat for every region you use.

Option 3: Terraform

resource "aws_ebs_encryption_by_default" "this" {
  enabled = true
}

resource "aws_ebs_default_kms_key" "this" {
  key_arn = aws_kms_key.ebs.arn
}

resource "aws_kms_key" "ebs" {
  description             = "Default EBS encryption key"
  deletion_window_in_days = 30
  enable_key_rotation     = true
}

Migrating existing unencrypted volumes

For volumes that already exist unencrypted, the path is: snapshot, copy the snapshot with encryption, create a new volume, swap it in.

# 1. Snapshot the existing (unencrypted) volume
SNAP=$(aws ec2 create-snapshot --volume-id vol-0abc123 \
  --description "pre-encryption snapshot" \
  --query SnapshotId --output text)

# 2. Copy the snapshot with encryption enabled
ENC_SNAP=$(aws ec2 copy-snapshot \
  --source-region us-east-1 \
  --source-snapshot-id "$SNAP" \
  --encrypted \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/your-key-id \
  --query SnapshotId --output text)

# 3. Create a new encrypted volume from the encrypted snapshot
aws ec2 create-volume \
  --snapshot-id "$ENC_SNAP" \
  --availability-zone us-east-1a

Then stop the instance, detach the old volume, attach the new one at the same device name, and start the instance.

How to prevent it from happening again

Flipping the flag fixes today. Keeping it on across new accounts and new regions takes a bit of automation.

Enforce with an SCP

A Service Control Provider policy in AWS Organizations can deny the creation of unencrypted volumes outright, regardless of the default setting:

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

This belongs at the org or OU level so it covers every member account, including ones created later.

Set the default on every new account

If you use AWS Control Tower or an account factory, add a lifecycle hook or a CloudFormation StackSet that runs enable-ebs-encryption-by-default across all regions as part of account baselining. New accounts start compliant instead of starting with the gap.

Catch it in CI/CD with policy-as-code

Scan IaC before it ships. With Checkov:

checkov -d . --check CKV_AWS_3,CKV_AWS_189

Or write an OPA/Conftest rule that fails any plan creating an EBS volume without encrypted = true:

# Example: fail the pipeline if any aws_ebs_volume lacks encryption
conftest test plan.json --policy policy/ebs.rego

Continuous monitoring

Lensix re-runs this check on a schedule so that if someone disables the setting in a new region, or a region you just started using never had it enabled, you find out without waiting for an audit. That closes the drift loop that manual fixes leave open.

Best practices

• Use a customer-managed KMS key, not the default AWS-managed key. A CMK lets you control rotation, set key policies, audit usage in CloudTrail, and revoke access during an incident.
• Enable key rotation. Turn on automatic annual rotation for your EBS KMS keys so you aren't relying on a single static key indefinitely.
• Apply the setting in every region, including ones you don't think you use. Default encryption costs nothing when set in an idle region, and it protects you the day someone launches something there.
• Encrypt snapshots and AMIs too. An encrypted volume can still spawn copies. Make sure your AMI bakery and backup tooling carry encryption forward.
• Treat the SCP and the default flag as separate layers. The flag changes the default; the SCP enforces the rule. Both together give you defense in depth.
• Audit existing volumes after enabling. Remember the setting is forward-looking only. Run an inventory of unencrypted volumes and snapshots and schedule their migration.

EBS default encryption is cheap insurance. It takes a single API call per region, has no performance penalty worth measuring, and removes a whole category of accidental data exposure. There's no good reason to leave it off.