Deleting KMS CMKs

It deletes the key material and all metadata associated with the CMK and is irreversible.
After a CMK is deleted, you can no longer decrypt the data that was encrypted under that CMK, which means that data becomes unrecoverable.
You should delete a CMK only when you are sure that you don't need to use it anymore. If you are not sure, consider disabling the CMK instead of deleting it because you can reenable it with that.
Because it is destructive and potentially dangerous to delete a CMK, KMS enforces a waiting period (minimum of 7 days up to a maximum of 30 days) and during the waiting period, the CMK cannot be used in any cryptographic operation.

How deleting customer master keys affects AWS services integrated with KMS

Some services, such as EBS and Redshift, use a KMS CMK to generate a data key and then use the data key to encrypt your data. These plaintext data keys persist in memory as long as the data they are protecting is actively in use.
Scheduling a CMK for deletion makes it unusable, but it does not prevent the AWS service from using data keys in memory to encrypt and decrypt your data. The service is not affected until it needs to use the CMK that is pending deletion or deleted.

You create an encrypted EBS volume and specify a CMK.
EBS asks KMS to use your CMK to generate an encrypted data key for the volume and EBS stores the encrypted data key with the volume.
When you attach the EBS volume to an EC2 instance, EC2 asks KMS to use your CMK to decrypt the EBS volume's encrypted data key. EC2 stores the plaintext data key in hypervisor memory and uses it to encrypt disk I/O to the EBS volume. The data key persists in memory as long as the EBS volume is attached to the EC2 instance.
You schedule the CMK for deletion, which makes it unusable. This has no immediate effect on the EC2 instance or the EBS volume, because EC2 is using the plaintext data key (not the CMK) to encrypt disk I/O to the EBS volume.
However, when the encrypted EBS volume is detached from the EC2 instance, EBS removes the plaintext key from memory.
The next time the encrypted EBS volume is attached to an EC2 instance, the attachment fails, because EBS cannot use the CMK to decrypt the volume's encrypted data key.

PreviousData Key Caching NextDefault KMS Key Policy

Last updated 4 years ago

Was this helpful?

How deleting customer master keys affects AWS services integrated with KMS

Some services, such as EBS and Redshift, use a KMS CMK to generate a data key and then use the data key to encrypt your data. These plaintext data keys persist in memory as long as the data they are protecting is actively in use.

Scheduling a CMK for deletion makes it unusable, but it does not prevent the AWS service from using data keys in memory to encrypt and decrypt your data. The service is not affected until it needs to use the CMK that is pending deletion or deleted.

You create an encrypted EBS volume and specify a CMK.

EBS asks KMS to use your CMK to generate an encrypted data key for the volume and EBS stores the encrypted data key with the volume.

When you attach the EBS volume to an EC2 instance, EC2 asks KMS to use your CMK to decrypt the EBS volume's encrypted data key. EC2 stores the plaintext data key in hypervisor memory and uses it to encrypt disk I/O to the EBS volume. The data key persists in memory as long as the EBS volume is attached to the EC2 instance.

You schedule the CMK for deletion, which makes it unusable. This has no immediate effect on the EC2 instance or the EBS volume, because EC2 is using the plaintext data key (not the CMK) to encrypt disk I/O to the EBS volume.

However, when the encrypted EBS volume is detached from the EC2 instance, EBS removes the plaintext key from memory.

The next time the encrypted EBS volume is attached to an EC2 instance, the attachment fails, because EBS cannot use the CMK to decrypt the volume's encrypted data key.