Skip to content
Ask AI about this
Help improve this page

EBS snapshots should be encrypted

EBS snapshots are frequently shared across accounts, copied between regions, or stored long-term for disaster recovery. An unencrypted snapshot exposes raw block-level data to anyone who gains access to it, whether through a misconfigured IAM policy, a leaked credential, or an overly broad snapshot share. AWS does not let you encrypt an existing snapshot in place; you must copy it with encryption enabled and delete the original.

Enabling EBS encryption by default at the account level via aws_ebs_encryption_by_default prevents new unencrypted volumes and snapshots from being created, but it does nothing about snapshots that already exist. Retroactively remediating a fleet of unencrypted snapshots can be expensive in both time and cross-region data transfer costs.

Retrofit consideration

Existing unencrypted snapshots cannot be encrypted in place. Each must be copied with encryption enabled via aws_ebs_snapshot_copy, then the original deleted. In large environments with thousands of snapshots, this requires scripted migration and can incur significant data transfer costs.

Implementation

Choose the approach that matches how you manage Terraform.

Use AWS provider resources directly. See docs for the resources involved: aws_ebs_snapshot_copy.

resource "aws_ebs_snapshot_copy" "this" {
  source_region      = "us-east-1"
  source_snapshot_id = "snap-1234567890abcdef0"

  encrypted = true
}

What this control checks

Encryption on aws_ebs_snapshot is inherited from the source volume referenced by volume_id. If that source aws_ebs_volume has encrypted = true, the resulting snapshot will also be encrypted. There is no standalone encrypted argument on aws_ebs_snapshot itself. For aws_ebs_snapshot_copy, set encrypted = true and optionally provide a kms_key_id for a customer-managed key. Snapshots without encryption fail this control. The most reliable prevention is enabling account-level default encryption via aws_ebs_encryption_by_default with enabled = true, which covers all newly created volumes and their snapshots automatically. Pair this with aws_ebs_default_kms_key to control which KMS key is used.

Common pitfalls

  • Snapshots inherit encryption from source volume

    aws_ebs_snapshot has no encrypted argument. Encryption is set entirely on the source aws_ebs_volume. Skip encrypted = true on the volume and every snapshot taken from it will be unencrypted. Fix the volume, not the snapshot resource.

  • Account-level default does not retroactively encrypt

    Enabling aws_ebs_encryption_by_default only affects volumes and snapshots created after activation. Pre-existing unencrypted snapshots stay unencrypted and will keep failing this control until replaced.

  • Cross-account shared snapshots may lose KMS access

    Sharing encrypted snapshots via aws_snapshot_create_volume_permission requires the receiving account to have access to the KMS key used for encryption. The default aws/ebs key cannot be shared cross-account, so sharing will fail. Use a customer-managed KMS key with a key policy that grants the target account kms:Decrypt and kms:DescribeKey.

  • AMIs backed by unencrypted snapshots

    AMIs registered via aws_ami or aws_ami_copy reference EBS snapshots underneath. If those snapshots are unencrypted, this control flags them. Using encrypted = true on aws_ami_copy produces new encrypted snapshots, but the original AMI still needs to be deregistered and its underlying snapshots deleted.

  • Snapshot copy costs in multi-region setups

    Cross-region remediation using aws_ebs_snapshot_copy with encrypted = true incurs data transfer charges. For snapshots in the multi-TB range, that cost can be substantial. Factor it into the migration plan before you start.

Audit evidence

Config rule evaluation results for the managed rule encrypted-snapshots or a custom rule targeting snapshot encryption, showing a history of compliant evaluations. A CLI export from aws ec2 describe-snapshots --owner-ids self --query "Snapshots[?Encrypted==\false`]"` returning an empty list is direct evidence. Screenshots from the EC2 console showing encryption status on the Snapshots page work for spot checks.

For the preventive side, look for proof that account-level EBS encryption is enabled. The output of aws ec2 get-ebs-encryption-by-default should show EbsEncryptionByDefault: true. CloudTrail events for CreateSnapshot and CopySnapshot API calls can confirm that encryption was consistently applied over the audit period.

Framework-specific interpretation

NIST Cybersecurity Framework v2.0: PR.DS requires that data at rest be protected through cryptographic controls. EBS snapshots are persistent storage artifacts that outlive the source volume, so they need the same protections applied to the volume itself. Encrypting them meets this requirement.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: ebs_snapshot_encryption_enabled

  • Powerpipe Control: aws_compliance.control.ebs_snapshot_encryption_enabled

  • Prowler Check: ec2_ebs_snapshots_encrypted

Last reviewed: 2026-03-09