Storage Encryption at Rest: KMS Keys and Volume Encryption (2026)

KMS keys are not just secrets; they are the central orchestrators of your data’s privacy, controlling access to the actual encryption keys that guard your disks.

Let’s see this in action. Imagine you have an EBS volume attached to an EC2 instance. This volume is encrypted. That encryption isn’t a magic spell; it uses a data encryption key (DEK) generated specifically for that volume. But where is the DEK stored? It’s encrypted itself, by a Customer Master Key (CMK) managed by AWS Key Management Service (KMS). When your EC2 instance needs to read data from the encrypted volume, it makes a request. AWS services intercept this request, retrieve the encrypted DEK, and then make a call to KMS to decrypt the DEK using your CMK. Once the DEK is decrypted, it’s sent back to the EC2 instance, which can then use it to decrypt the data on the volume. The DEK is ephemeral; it’s only decrypted when needed and is not stored persistently on the volume itself.

The problem this solves is managing the lifecycle of encryption keys for a vast number of resources without requiring you to become a cryptography expert. KMS handles the secure generation, storage, rotation, and access control of your CMKs. These CMKs, in turn, protect the DEKs used to encrypt your data. This layered approach ensures that even if an attacker gains physical access to the underlying storage media, the data remains unreadable without the corresponding DEK, which itself is protected by a KMS CMK.

Here’s a typical setup in AWS:

{
    "Id": "KeyPolicy",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for EC2 to encrypt/decrypt volumes",
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "kms:ViaService": "ec2.amazonaws.com"
                },
                "ArnLike": {
                    "kms:EncryptionContext:aws:ec2:arn": "arn:aws:ec2:us-east-1:111122223333:volume/*"
                }
            }
        }
    ]
}

This policy grants the EC2 service permission to use the KMS key for operations related to EBS volumes. The kms:ViaService condition ensures that the request originates from EC2, and kms:EncryptionContext ties the key usage to a specific EBS volume resource.

The levers you control are primarily within KMS and the services that integrate with it. For KMS, you manage:

• Key Policy: This is the IAM policy attached to your CMK, defining who can perform what KMS operations on which KMS keys. This is the most critical control.
• Access Control Lists (ACLs): While not directly on KMS keys, IAM policies for users and roles accessing AWS services (like EC2, S3, RDS) determine if they can request KMS operations.
• Key Rotation: You can enable automatic key rotation for AWS-managed CMKs, which automatically creates a new backing key every year and continues to use the same CMK ID. For customer-managed keys, you control when to create a new backing key.
• Grant Control: Grants are a way to delegate KMS permissions to other AWS services or applications without modifying the key policy.

When you create an encrypted EBS volume, you specify a KMS CMK. For example, using the AWS CLI:

aws ec2 create-volume \
    --availability-zone us-east-1a \
    --size 100 \
    --encrypted \
    --kms-key-id arn:aws:kms:us-east-1:111122223333:key/your-kms-key-id \
    --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=MyEncryptedVolume}]'

Here, --kms-key-id points to the specific CMK that will be used to encrypt the DEK for this volume. If you omit --kms-key-id and use --encrypted, AWS will use the AWS-managed KMS key for EBS in that region (aws/ebs).

A common misunderstanding is that the KMS key itself encrypts the data on the volume. It doesn’t directly. The KMS CMK encrypts the data encryption key (DEK), and the DEK encrypts the volume data. This is a crucial distinction for understanding performance and security. The DEK is used for the bulk encryption/decryption of data blocks on the volume because it can be generated and used locally by the EC2 instance (or other services) without needing a constant round trip to KMS for every block read or write. KMS is involved only when the DEK needs to be decrypted or re-encrypted, which happens less frequently than data access itself.

The next step in managing data protection is often understanding how these encryption mechanisms extend to other services, like S3, and how to implement robust key management strategies across your cloud environment.