Right, so you’ve decided you don’t want your data sitting on a disk in some AWS data center for anyone to stumble upon. Good call. Encrypting your EBS volumes isn’t just a best practice; it’s often a regulatory requirement. And the good news is, AWS makes this almost criminally easy. The key (pun intended) to understanding it all is realizing that EBS encryption is a feature, but the real brains of the operation is the AWS Key Management Service (KMS). Let’s pull back the curtain.

The Default Key is Fine, Until It Isn’t

When you enable encryption on a new volume without specifying a key, AWS uses the default EBS encryption key for your account in that region. It’s a symmetric KMS key aptly named aws/ebs. You can see it in the KMS console.

# This creates a new volume using your account's default EBS key
aws ec2 create-volume --volume-type gp3 --size 10 --availability-zone us-east-1a --encrypted

Notice you didn’t have to specify a --kms-key-id. It just works. This is fantastic for getting started and for teams that don’t want to think about key management. But here’s the rub: this default key is a shared resource. Every EBS volume encrypted with it in your account is protected by the same key. If you ever need to revoke access to a specific volume (say, a developer leaves), you can’t revoke access to just their volume without affecting every other volume using that default key. That’s… suboptimal. For any serious use, you’ll want to use your own Customer Managed Keys (CMKs).

Using Your Own Keys: The Smart Move

Creating and using your own KMS key gives you fine-grained control. You can define who can use it (via key policies and IAM), track its usage via CloudTrail, and even rotate it automatically. This is the way.

# First, create your own KMS key (or use an existing one)
# Note: This requires kms:CreateKey permission
aws kms create-key --description "My Super Secure EBS Key"

# Copy the Key ID from the output (it'll look like a UUID: 1234abcd-12ab-34cd-56ef-1234567890ab)
# Now create a volume using that specific key
aws ec2 create-volume \
  --volume-type gp3 \
  --size 10 \
  --availability-zone us-east-1a \
  --encrypted \
  --kms-key-id alias/my-ebs-key-alias # Using an alias is much easier than the UUID

Why is this better? You can now write IAM policies that grant the kms:Encrypt and kms:Decrypt permissions for this specific key to specific roles or users. Your EC2 instance’s role needs permission to decrypt this key to read the volume. No one else does. Clean, isolated, and secure.

The Encrypted Snapshot Shuffle

This is where people’s brains short-circuit, but it’s simple once you get it. An unencrypted snapshot is, well, unencrypted. You can’t just “encrypt” it. What you actually do is copy it and tell the copy operation to encrypt it this time around. The magic is that you can copy an unencrypted snapshot to an encrypted one, and you can also re-encrypt a snapshot that’s already encrypted—but with a different KMS key.

# Let's say you have an unencrypted snapshot: snap-0123456789abcdef0
# To create an encrypted copy using your custom key:
aws ec2 copy-snapshot \
  --source-region us-east-1 \
  --source-snapshot-id snap-0123456789abcdef0 \
  --encrypted \
  --kms-key-id alias/my-ebs-key-alias \
  --description "Now this snapshot is properly encrypted!"

The most important “gotcha” here? Permissions, permissions, permissions. The IAM user or role performing the copy-snapshot operation must have permission to use the KMS key (kms:Encrypt, kms:Decrypt, etc.) on both ends of the operation.

  • If the source snapshot is encrypted (with Key A), you need kms:Decrypt permission for Key A.
  • For the destination (encrypted with Key B), you need kms:Encrypt permission for Key B.

If you’re crossing accounts, this becomes a delightful IAM/KMS policy dance. The source account must grant permission on their key to the destination account’s user/role, and the destination account must grant its user permission to use its own key. It’s a bit of a paperwork drill, but it’s what makes the whole system secure and auditable.

The Performance Non-Issue

I can see you wondering: “All this crypto must slow down my fancy io2 Block Express volume, right?” Nope. The encryption is handled by the Nitro System hypervisor on the physical host, not on the instance’s CPU. It’s hardware-accelerated AES-256 and happens transparently off-chip. The performance overhead is statistically zero. You get this world-class encryption for free. It’s one of the few things in tech that is both vastly more secure and has no downside. You have no excuse not to turn it on.