How Does AWS KMS Encrypt EC2 EBS Volumes at Rest and Transit?

AWS Key Management Service integrates with Amazon EC2 to provide automated, transparent encryption for Amazon Elastic Block Store volumes both at rest and in transit. By using envelope encryption and hardware-accelerated cryptographic engines on Nitro-based instances, AWS ensures that sensitive data stored on block devices, transferred between instances and storage clusters, and backed up in snapshots remains protected without requiring manual key distribution or application-level changes.

Envelope Encryption Architecture

Amazon EBS encryption relies on an envelope encryption model managed by AWS Key Management Service (AWS KMS). Instead of using the KMS key directly to encrypt gigabytes or terabytes of storage blocks, the architecture establishes a two-tiered key hierarchy:

  1. KMS Key (Customer Master Key): Stored and protected within AWS KMS hardware security modules (HSMs) validated under FIPS 140-2 or FIPS 140-3. This can be either an AWS managed key (aws/ebs) or a customer managed key (CMK) created in KMS.
  2. Data Key: A unique 256-bit symmetric key generated specifically for an individual EBS volume.

In mathematical notation, if \(K_{M}\) represents the KMS key, \(K_{D}\) represents the plaintext data key, and \(P\) represents the plaintext volume blocks, the encryption relationship is defined as:

\[C_{\text{key}} = \text{Encrypt}(K_{M}, K_{D})\]

\[C_{\text{data}} = \text{AES-XTS}_{256}(K_{D}, P)\]

Here, \(C_{\text{key}}\) is the encrypted data key stored alongside the EBS volume metadata, and \(C_{\text{data}}\) is the encrypted block storage data. The plaintext data key \(K_{D}\) is never persisted to disk.

Step-by-Step Integration Workflow

When an encrypted EBS volume is created and attached to an Amazon EC2 instance, EC2, EBS, and KMS coordinate through the following sequence:

1. Volume Creation

When you create an encrypted EBS volume and specify a KMS key (or rely on account-level default encryption), Amazon EBS calls the AWS KMS GenerateDataKeyWithoutPlaintext API. KMS generates a unique data key encrypted under the specified KMS key and returns the ciphertext data key (\(C_{\text{key}}\)) to Amazon EBS. EBS stores this encrypted data key within the volume metadata.

2. Volume Attachment and Key Decryption

When the encrypted volume is attached to an Amazon EC2 instance, the EC2 host sends a request to AWS KMS calling the Decrypt API with the volume's encrypted data key (\(C_{\text{key}}\)) and an encryption context restricting the operation to that specific volume ID.

3. In-Memory Key Caching on the EC2 Host

If the IAM permissions, KMS key policy, and KMS grants authorize the operation, AWS KMS returns the plaintext data key (\(K_{D}\)) over an authenticated TLS session to the underlying EC2 physical host (hypervisor). The EC2 host stores \(K_{D}\) exclusively in volatile memory (RAM) for as long as the volume remains attached to the instance.

4. Cryptographic Offloading via the AWS Nitro System

On modern Nitro-based EC2 instances, encryption and decryption operations are offloaded to dedicated Nitro Security Chips and Nitro Cards for EBS. The plaintext data key is programmed into the dedicated hardware controller, which performs line-rate XTS-AES-256 encryption and decryption without consuming guest CPU cycles.

How Data Is Protected at Rest and in Transit

When you enable EBS encryption via AWS KMS, multiple layers of data are secured simultaneously:

  • Data at rest inside the volume: Every block written to the physical storage media in the EBS cluster is stored as ciphertext using the XTS-AES-256 algorithm.
  • Data in transit between EC2 and EBS: Because the encryption and decryption occur on the EC2 host hardware before the storage traffic leaves the host, all I/O operations traversing the AWS network between the EC2 instance and the EBS storage fleet are already encrypted with the volume's data key. Additionally, Nitro instances apply link-layer encryption to traffic between the EC2 host and the EBS storage backend.
  • Snapshots: Any snapshot created from an encrypted volume is automatically encrypted using the same data key.
  • Volumes created from snapshots: Any new volume restored from an encrypted snapshot inherits encryption automatically, and you can optionally re-encrypt it under a different KMS key during creation.

Key Management Options: AWS Managed vs. Customer Managed Keys

When configuring EBS encryption with KMS, you can choose between two key types depending on your compliance and operational requirements:

Feature AWS Managed Key (aws/ebs) Customer Managed Key (CMK)
Creation & Lifecycle Automatically created on first use Created and managed by the customer
Key Rotation Automatic every year Configurable automatic annual rotation or on-demand
Key Policy Customization Read-only policy Fully customizable key policy
Cross-Account Sharing Cannot be shared across AWS accounts Supports sharing encrypted snapshots and AMIs across accounts
Granular Revocation Cannot be manually disabled or deleted Can be disabled, scheduled for deletion, or have grants revoked

Enforcing Default EBS Encryption

To prevent unencrypted volumes from being launched accidentally, you can enable EBS encryption by default at the AWS Region level within your account. Once enabled, every new EBS volume or snapshot copy created in that Region is automatically encrypted using your designated default KMS key, even if the Encrypted parameter is omitted from the RunInstances or CreateVolume API calls.

You can enable default encryption and specify a custom KMS key using the AWS CLI:

aws ec2 enable-ebs-encryption-by-default \
    --region us-east-1

aws ec2 modify-ebs-default-kms-key-id \
    --kms-key-id arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012 \
    --region us-east-1

IAM and KMS Grant Mechanics

When an IAM principal launches an EC2 instance with an encrypted EBS volume using a customer managed key, the principal requires permission to use the KMS key so that EC2 and EBS can perform cryptographic operations on its behalf. Specifically, the IAM policy or KMS key policy must allow the following actions:

  • kms:CreateGrant
  • kms:Decrypt
  • kms:DescribeKey
  • kms:GenerateDataKeyWithoutPlaintext
  • kms:ReEncryptFrom and kms:ReEncryptTo (when copying snapshots or changing keys)

To make sure only the Amazon EC2 and EBS services can use the grant, policies frequently apply the kms:ViaService condition key (for example, ec2.us-east-1.amazonaws.com) alongside kms:EncryptionContext:aws:ebs:id to scope cryptographic calls strictly to valid EBS volume lifecycles.