EBS Encryption

EBS Encryption provides seamless encryption for Amazon Elastic Block Store volumes. When enabled, it encrypts data at rest, data in transit between EC2 and EBS, all snapshots, and all volumes created from encrypted snapshots. It is one of the rare security controls with essentially no downside: no code changes, no key handling in your application, and no measurable performance penalty on modern instances.

How It Works

• Uses AES-256 encryption algorithm
• Keys managed by AWS KMS: use the AWS managed key (aws/ebs) or a customer managed key
• Encryption/decryption happens on the EC2 host, with no performance impact on modern instances (Nitro-based)
• Default Encryption: enable per-region to automatically encrypt all new volumes

Best Practices

• Enable default EBS encryption in every region you use
• Use customer managed KMS keys for cross-account snapshot sharing and granular key policies
• Copy unencrypted snapshots as encrypted to migrate existing data
• Use SCPs to enforce encryption across all accounts in your organization

What Default Encryption Does and Does Not Do

Encryption by default is an account-level, per-Region setting. Once enabled, every newly created volume in that Region is encrypted, whether it comes from the console, the CLI, an Auto Scaling group, or a CloudFormation template that forgot the flag. Two documented caveats matter. First, the setting has no effect on volumes that already exist: everything created before you flipped the switch stays unencrypted until you migrate it via the snapshot-copy path. Second, after enabling it you can no longer launch the small set of legacy instance types that do not support encryption, which is worth checking before enabling it in an account still running very old instance families. Migration of existing data is a four-step dance: snapshot the unencrypted volume, copy the snapshot with encryption enabled, create a new volume from the encrypted copy, and swap it onto the instance.

How It Goes Wrong in Practice

The classic failure is uneven coverage that everyone assumes is universal. A team enables default encryption in its primary Region during a compliance push, the audit passes, and the topic is closed. But the setting is per-Region and per-account: the disaster recovery Region, the sandbox account, and the new Region someone expanded into last quarter all still create unencrypted volumes. Years later, an unencrypted snapshot from one of those gaps gets shared to the wrong account, or copied around during an incident, and the "everything is encrypted" assumption collapses in front of the auditor. A second recurring trap involves sharing: snapshots encrypted with the default AWS managed key cannot be meaningfully shared cross-account, because the other account can never use that key. Cross-account workflows need customer managed keys with a key policy granting the target account access, which is why the best practice above exists. The fix for both is mechanical enforcement: enable the setting in every Region of every account (a few lines of script across your organization), verify it continuously with AWS Config, and add an SCP or Config rule so drift gets caught rather than trusted.

A Practical Check: Auditing and Enabling per Region

Check the current Region's status:

aws ec2 get-ebs-encryption-by-default

It returns "EbsEncryptionByDefault": true or false. Enabling it is equally short:

aws ec2 enable-ebs-encryption-by-default

Both commands act on the Region you target, so a complete audit loops over every Region with --region. Anything returning false in a Region where you run workloads is a gap worth closing today, since it costs one command and breaks nothing that is already running.

Frequently Asked Questions

Does enabling default encryption encrypt my existing volumes?

No. It only affects volumes created after the setting is enabled. Existing unencrypted volumes must be migrated manually: snapshot, copy the snapshot with encryption, restore, and swap the volume.

Is there a performance cost to EBS encryption?

On Nitro-based instances the cryptography is handled in dedicated hardware on the host, and AWS positions the impact as negligible for typical workloads. There is no practical reason to leave volumes unencrypted for performance.

Can I encrypt a volume in place, or change its key?

Neither happens in place. Encryption status and the KMS key are fixed at volume creation, so both changes go through the same path: snapshot the volume, copy the snapshot specifying the encryption state and key you want, and create a new volume from the copy.

Which key should I use, aws/ebs or a customer managed key?

The AWS managed aws/ebs key is fine for single-account setups with no sharing needs. Choose a customer managed key when you need cross-account snapshot sharing, your own key policy, rotation control, or the ability to revoke a key as a kill switch over the data it protects.