--- title: AWS EBS Encryption and Snapshot Hygiene: Default Encryption, Public Snapshot Prevention, and KMS Key Lifecycle description: EBS encryption is one of the easiest controls to get right — and one of the most expensive to retrofit. Account-level default encryption, re-encrypting legacy volumes without downtime, blocking public snapshots, and operating the KMS key lifecycle without losing data to accidental deletion. url: https://www.factualminds.com/blog/aws-ebs-encryption-snapshot-hygiene-kms-lifecycle/ datePublished: 2026-04-28T00:00:00.000Z dateModified: 2026-04-29T00:00:00.000Z author: Palaniappan P category: Security & Compliance tags: ebs, kms, security, aws, compliance --- # AWS EBS Encryption and Snapshot Hygiene: Default Encryption, Public Snapshot Prevention, and KMS Key Lifecycle > EBS encryption is one of the easiest controls to get right — and one of the most expensive to retrofit. Account-level default encryption, re-encrypting legacy volumes without downtime, blocking public snapshots, and operating the KMS key lifecycle without losing data to accidental deletion. EBS encryption is one of the easiest production security controls to get right and one of the most expensive to clean up after the fact. Get it wrong and you end up with a fleet of unencrypted volumes that cannot simply be encrypted in place — every fix is a snapshot, copy, restore, swap. Get it right at the account level and every new volume is encrypted by default, every snapshot inherits the encryption, and the question never comes up in an audit. This guide covers the four EBS-and-KMS controls that compliance scanners will flag if you skip them — and the operational lifecycle of the KMS keys that protect everything underneath. ## EBS Encryption by Default: The One-Click Control Every AWS account in every region has an account-level setting: `EBSEncryptionByDefault`. When enabled, every new EBS volume and every new snapshot is automatically encrypted with the KMS key you designate — no per-volume configuration, no developer remembering to tick a box, no Terraform parameter that someone forgot. ```bash # Check the current state aws ec2 get-ebs-encryption-by-default --region us-east-1 # Enable aws ec2 enable-ebs-encryption-by-default --region us-east-1 # Set the default key (CMK recommended for production) aws ec2 modify-ebs-default-kms-key-id \ --kms-key-id alias/ebs-default-cmk \ --region us-east-1 ``` **Enable in every region, every account.** Use a stack set or a Terraform module so this is part of the account-baseline you apply at provisioning time, not a setting you remember to flip later. The setting is per-region — enabling it in `us-east-1` does nothing for a workload in `eu-west-1`. **Lock it on with an SCP** so a misguided cost-saving experiment cannot turn it off: ```json { "Effect": "Deny", "Action": ["ec2:DisableEbsEncryptionByDefault"], "Resource": "*" } ``` A single cleanup script that flips this setting across an organization closes one of the most common compliance findings in a single afternoon — and unlike most security work, every existing workload keeps running unchanged because the setting only affects new volumes. ## Re-encrypting Legacy Unencrypted Volumes EBS encryption cannot be added to an existing volume in place. If you have an unencrypted volume in production today, the only way to fix it is the snapshot-copy-restore dance: 1. Take a snapshot of the unencrypted volume. 2. Copy the snapshot with `--encrypted` and the destination KMS key — this produces an encrypted snapshot. 3. Create a new volume from the encrypted snapshot. 4. Stop the instance, detach the unencrypted volume, attach the encrypted volume, restart. ```bash # Step 2: encrypted snapshot copy aws ec2 copy-snapshot \ --source-snapshot-id snap-old-unencrypted \ --source-region us-east-1 \ --destination-region us-east-1 \ --encrypted \ --kms-key-id alias/ebs-default-cmk \ --description "Encrypted copy of snap-old-unencrypted" ``` **Plan for downtime.** Step 4 requires stopping the instance. For Multi-AZ workloads (RDS, Aurora, ECS with rolling deployments), the downtime is per-instance, not per-service. For single-instance workloads, schedule a maintenance window. **Track legacy volumes with Config.** The Config rule `encrypted-volumes` flags unencrypted EBS volumes. Pair it with an EventBridge target that opens a Jira ticket so you have a backlog rather than a spreadsheet. ## Default Key vs Customer-Managed Key The EBS default encryption setting accepts either the AWS-managed `aws/ebs` key or a customer-managed CMK. The choice mirrors the [SSE-S3 vs SSE-KMS decision](/blog/aws-s3-security-best-practices-preventing-data-exposure/) for S3 — same trade-offs, different service. | Feature | AWS-managed `aws/ebs` | Customer-managed CMK | | --------------------------------------- | --------------------- | -------------------------------------------- | | Configuration | Zero | Create key + alias | | Cost | Free | $1/month per key + API calls | | Key policy | AWS-controlled | You author it | | Cross-account snapshot sharing | Not supported | Supported | | CloudTrail records every use | Yes | Yes | | Granular access control | No | Yes (per-grant, per-condition) | | Required for some compliance frameworks | No | Yes (FedRAMP High, some HIPAA architectures) | **Recommendation:** for any account that holds regulated data or that ever needs to share snapshots cross-account, use a CMK from day one. The cost is trivial and migrating later means re-encrypting every volume. ## Snapshot Sharing Safety: Block Public Snapshots EBS snapshots can be shared with specific AWS accounts or, dangerously, with `all` — making them publicly restorable by any AWS account in the world. Public snapshots have leaked customer databases, source code, and secrets every year for the past decade. AWS provides a single account-level switch to make this structurally impossible: **block public access for snapshots**. ```bash aws ec2 enable-snapshot-block-public-access \ --state block-all-sharing \ --region us-east-1 ``` The `block-all-sharing` mode prevents any new public sharing _and_ blocks existing public snapshots from being restored — the strongest setting. Two weaker modes exist (`block-new-sharing`, `unblocked`) but there is no production reason to choose them. **Detection and remediation:** - **Config rule:** `ebs-snapshot-public-restorable-check` flags any snapshot currently shared with `all`. - **SCP:** deny `ec2:ModifySnapshotAttribute` when the modification adds `Group: all`: ```json { "Effect": "Deny", "Action": ["ec2:ModifySnapshotAttribute"], "Resource": "*", "Condition": { "StringEquals": { "ec2:Add/group": "all" } } } ``` - **EventBridge auto-remediation:** when the rule flags a public snapshot, run a Lambda that calls `modify-snapshot-attribute` to remove the public group within seconds, before an attacker can clone it. ## KMS Key Lifecycle and Deletion Safety The KMS key that encrypts your EBS volumes (and CloudTrail logs, and S3 objects, and RDS storage) is the single most important key in the account — losing it means losing access to every encrypted artifact it ever protected. AWS deliberately makes deletion difficult, but operators routinely defeat the safeguards by accident. ### The 7–30 Day Waiting Period Calling `kms:ScheduleKeyDeletion` does not delete the key. It puts the key in `PendingDeletion` state for a configurable waiting period (7 to 30 days, default 30). During the waiting period: - The key is unusable — encrypt and decrypt operations fail - Any service that depends on the key (EBS, CloudTrail, S3, RDS) starts failing - An operator with `kms:CancelKeyDeletion` can restore the key and resume normal operation ```bash # If you discover the deletion in time: aws kms cancel-key-deletion --key-id alias/critical-cmk ``` **Always set the waiting period to 30 days,** not 7. The marginal "cost" is zero — keys in `PendingDeletion` do not bill — and the marginal benefit is three extra weeks of recovery window. Most accidental schedules are caught within days, but a key scheduled the morning of an extended team holiday at 7 days is a real incident. ### Automatic Key Rotation Every CMK should have automatic rotation enabled. AWS rotates the key material on a configurable schedule between 90 days and 7 years (default: annually) without changing the key ID — every existing reference, every encrypted artifact, every IAM policy keeps working. There is no operational reason not to enable rotation. ```bash aws kms enable-key-rotation --key-id alias/ebs-default-cmk aws kms put-key-rotation-policy --key-id alias/ebs-default-cmk \ --rotation-period-in-days 365 ``` Rotation does not re-encrypt existing data — that would be impossible at scale. It rotates the key material so that new encryptions use the new material and old encryptions remain decryptable with the historical material AWS continues to hold. The benefit is forward security: a key material compromise affects only the data encrypted in the rotation window before the next rotation. ### Deletion Safety SCPs The most common cause of catastrophic key deletion is a privileged user who runs the wrong command on the wrong key. SCPs prevent this regardless of IAM policies in member accounts: ```json { "Sid": "DenyKeyDeletionExceptBreakGlass", "Effect": "Deny", "Action": ["kms:ScheduleKeyDeletion", "kms:DisableKey"], "Resource": "arn:aws:kms:*:*:key/*", "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws:iam::111122223333:role/KmsBreakGlass" } } } ``` Pair this with a CloudWatch alarm on `ScheduleKeyDeletion` and `DisableKey` API calls — the alarm should page the on-call rotation, not just open a ticket. If a break-glass action triggers it, that is by design; investigate every page. ### Key Aliases as Indirection Reference keys by alias (`alias/ebs-default-cmk`), not by key ID, in your application code, IaC, and policies. The alias is a stable pointer; the key ID behind it can change. If a key is compromised, you can create a new key, repoint the alias, and your applications keep working without redeployment. ### Multi-Region Keys For workloads that span regions and need cross-region disaster recovery for encrypted snapshots, use multi-region KMS keys. A multi-region primary in `us-east-1` and a replica in `us-west-2` share the same key material — you can decrypt in either region without a cross-region copy of the underlying ciphertext. Pre-2021 architectures required a snapshot copy with re-encryption to move encrypted data; multi-region keys eliminate that step. ## Putting It Together: A Production Baseline ``` Account-level baseline (apply via stack set, every region): ✓ EBS encryption by default = enabled ✓ Default key = customer-managed CMK ✓ Block public access for snapshots = block-all-sharing ✓ Config rules: encrypted-volumes, ebs-snapshot-public-restorable-check ✓ SCPs: deny disable-default-encryption, deny modify-snapshot-attribute Group=all ✓ SCPs: deny ScheduleKeyDeletion outside break-glass Every CMK: ✓ Automatic key rotation enabled (365 days) ✓ Key alias used in IaC and policies ✓ Key policy grants minimum required principals ✓ Multi-region key if cross-region DR is required ✓ CloudWatch alarm on ScheduleKeyDeletion / DisableKey Every legacy unencrypted volume: ✓ Tracked in a backlog (Config rule + EventBridge → Jira) ✓ Re-encrypted via snapshot-copy-restore in a scheduled window ``` For deeper KMS topics — including **post-quantum cryptography with ML-KEM and ML-DSA** for hybrid TLS and signatures — see the [post-quantum KMS guide](/blog/aws-kms-post-quantum-cryptography-ml-kem-ml-dsa/). The lifecycle and deletion safety patterns in this post apply to PQC keys as well. ## Common Mistakes ### Mistake 1: Encrypting in `us-east-1` Only Default encryption is per-region. The setting in your home region does nothing for the workload your team launched in `eu-central-1` last quarter. **Enable in every region, lock with an SCP.** ### Mistake 2: Forgetting Snapshots Inherit Source Encryption Copying an unencrypted snapshot to a region with default encryption enabled does _not_ encrypt it unless you pass `--encrypted` explicitly to `copy-snapshot`. Default encryption applies to _new_ snapshots from encrypted volumes, not to copy operations on existing unencrypted snapshots. **Always pass `--encrypted` on cross-region snapshot copies.** ### Mistake 3: Using the AWS-Managed Key for Production `aws/ebs` works fine until you need to share a snapshot cross-account, change who can decrypt, or audit access. By then, every existing snapshot is locked to a key you don't control. **Use a CMK from day one.** ### Mistake 4: 7-Day Deletion Window The default for `ScheduleKeyDeletion` is 30 days; some teams shorten it to 7 to "clean up faster." A 7-day window over a holiday period is a 5-business-day window. **Use 30 days, always.** ### Mistake 5: No Automated Detection of Public Snapshots Block public access for snapshots is one switch. The Config rule that detects existing public snapshots is one rule. Skipping either is the difference between a non-incident and a press release. **Both, in every account, every region.** ## Getting Started EBS encryption and KMS lifecycle are foundational controls — every other data-at-rest control depends on them working correctly. Combined with [S3 server-side encryption](/blog/aws-s3-security-best-practices-preventing-data-exposure/), [CloudTrail KMS encryption](/blog/aws-cloudtrail-production-setup-multi-region-validation-lake/), and [secrets management](/blog/aws-secrets-manager-vs-parameter-store-when-to-use-which/), they form the at-rest encryption baseline for a regulated AWS environment. For organization-wide encryption strategy, KMS key architecture, or [security assessments](/services/aws-cloud-security/) of an existing deployment, talk to our team. [Contact us to harden your AWS encryption posture →](/contact-us/) ## FAQ ### How do I enable EBS encryption by default in AWS? Run `aws ec2 enable-ebs-encryption-by-default` per region, then `aws ec2 modify-ebs-default-kms-key-id` to point at a customer-managed CMK. The setting is per-account and per-region, so apply it via a Terraform module or CloudFormation StackSet to every account/region during baseline provisioning. Lock it on with an SCP that denies `ec2:DisableEbsEncryptionByDefault`. ### How do I re-encrypt existing unencrypted EBS volumes? You cannot encrypt a volume in place. The procedure is: snapshot the unencrypted volume, copy the snapshot with `--encrypted --kms-key-id` set to your CMK, create a new volume from the encrypted copy, then detach and replace. Schedule a maintenance window for stateful workloads or use a rolling replacement for Auto Scaling groups. ### How do I prevent public EBS snapshots account-wide? Enable EBS Snapshot Block Public Access in every region with `aws ec2 enable-snapshot-block-public-access --state block-all-sharing`. This blocks any new public sharing of snapshots and revokes existing public shares — a one-line control that closes a recurring high-severity finding. ### What waiting period should I set when scheduling a KMS key for deletion? Always 30 days, never the 7-day minimum. KMS keys in `PendingDeletion` do not bill, so the marginal cost is zero, while the marginal benefit is three extra weeks to catch an accidental deletion before it becomes a permanent data loss incident. ### How often should AWS KMS keys rotate? Enable automatic rotation on every CMK. AWS rotates the key material on a configurable schedule between 90 days and 7 years (default: annually) without changing the key ID, so existing references and encrypted artifacts keep working. Regulated workloads often choose annual rotation to match audit cycles. --- *Source: https://www.factualminds.com/blog/aws-ebs-encryption-snapshot-hygiene-kms-lifecycle/*