# Using AWS KMS encryption with AWS services
With AWS Key Management Service, you can provide encryption keys for protecting data in other AWS services. Using AWS KMS encryption with AWS services refers to the process of integrating AWS KMS with other AWS services to encrypt and decrypt data at rest or in transit. Developers, system administrators, and security professionals might be interested in this topic to secure sensitive data stored or transmitted through AWS services, meet regulatory compliance requirements, or implement encryption best practices. Common use cases include encrypting Amazon EBS volumes, Amazon S3 buckets, and Amazon RDS databases. The following sections will cover the steps to configure and manage AWS KMS encryption keys for specific AWS services, ensuring data confidentiality and integrity across your AWS environment.For the complete list of AWS services integrated with AWS KMS, see [AWS Service Integration](https://aws.amazon.com/kms/features/#AWS_Service_Integration).
The following topics discuss in detail how particular services use AWS KMS, including the KMS keys they support, how they manage data keys, the permissions they require, and how to track each service's use of the KMS keys in your account.
**Important**
[AWS services that are integrated with AWS KMS](https://aws.amazon.com/kms/features/#AWS_Service_Integration) use only symmetric encryption KMS keys to encrypt your data. These services do not support encryption with asymmetric KMS keys. For help determining whether a KMS key is symmetric or asymmetric, see [Identify different key types](identify-key-types.md).
**Topics**
+ [Amazon Elastic Block Store (Amazon EBS)](services-ebs.md)
+ [Amazon EMR](services-emr.md)
+ [Amazon Redshift](services-redshift.md)
# How Amazon Elastic Block Store (Amazon EBS) uses AWS KMS
This topic discusses in detail how [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) uses AWS KMS to encrypt volumes and snapshots. For basic instructions about encrypting Amazon EBS volumes, see [Amazon EBS Encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html).
**Topics**
+ [
## Amazon EBS encryption
](#ebs-encrypt)
+ [
## Using KMS keys and data keys
](#ebs-cmk)
+ [
## Amazon EBS encryption context
](#ebs-encryption-context)
+ [
## Detecting Amazon EBS failures
](#ebs-failures)
+ [
## Using AWS CloudFormation to create encrypted Amazon EBS volumes
](#ebs-encryption-using-cloudformation)
## Amazon EBS encryption
When you attach an encrypted Amazon EBS volume to a [supported Amazon Elastic Compute Cloud (Amazon EC2) instance type](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption-requirements.html#ebs-encryption_supported_instances), data stored at rest on the volume, disk I/O, and snapshots created from the volume are all encrypted. The encryption occurs on the servers that host Amazon EC2 instances.
This feature is supported on all [Amazon EBS volume types](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption-requirements.html#ebs-encryption-volume-types). You access encrypted volumes the same way you access other volumes; encryption and decryption are handled transparently and they require no additional action from you, your EC2 instance, or your application. Snapshots of encrypted volumes are automatically encrypted, and volumes that are created from encrypted snapshots are also automatically encrypted.
The encryption status of an EBS volume is determined when you create the volume. You cannot change the encryption status of an existing volume. However, you can [migrate data](https://docs.aws.amazon.com//ebs/latest/userguide/how-ebs-encryption-works.html) between encrypted and unencrypted volumes and apply a new encryption status while copying a snapshot.
Amazon EBS supports optional encryption by default. You can enable encryption automatically on all new EBS volumes and snapshot copies in your AWS account and Region. This configuration setting doesn't affect existing volumes or snapshots. For details, see [Amazon EBS encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) in the *Amazon EBS User Guide*.
## Using KMS keys and data keys
When you [create an encrypted Amazon EBS volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html), you specify an AWS KMS key. By default, Amazon EBS uses the [AWS managed key](concepts.md#aws-managed-key) for Amazon EBS in your account (`aws/ebs`). However, you can specify a [customer managed key](concepts.md#customer-mgn-key) that you create and manage.
To use a customer managed key, you must give Amazon EBS permission to use the KMS key on your behalf. For more information , see [How Amazon EBS encryption works](https://docs.aws.amazon.com//ebs/latest/userguide/how-ebs-encryption-works.html) in *Amazon EBS User Guide*.
**Important**
Amazon EBS supports only [symmetric KMS keys](symm-asymm-choose-key-spec.md#symmetric-cmks). You cannot use an [asymmetric KMS key](symmetric-asymmetric.md) to encrypt an Amazon EBS volume. For help determining whether a KMS key is symmetric or asymmetric, see [Identify different key types](identify-key-types.md).
For each volume, Amazon EBS asks AWS KMS to generate a unique data key encrypted under the KMS key that you specify. Amazon EBS stores the encrypted data key with the volume. Then, when you attach the volume to an Amazon EC2 instance, Amazon EBS calls AWS KMS to decrypt the data key. Amazon EBS uses the plaintext data key in hypervisor memory to encrypt all disk I/O to the volume. For details, see *How EBS encryption works* in the [Amazon EC2 User Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#how-ebs-encryption-works) or [Amazon EC2 User Guide](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EBSEncryption.html#how-ebs-encryption-works).
## Amazon EBS encryption context
In its [GenerateDataKeyWithoutPlaintext](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyWithoutPlaintext) and [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) requests to AWS KMS, Amazon EBS uses an encryption context with a name-value pair that identifies the volume or snapshot in the request. The name in the encryption context does not vary.
An [encryption context](encrypt_context.md) is a set of key–value pairs that contain arbitrary nonsecret data. When you include an encryption context in a request to encrypt data, AWS KMS cryptographically binds the encryption context to the encrypted data. To decrypt the data, you must pass in the same encryption context.
For all volumes and for encrypted snapshots created with the Amazon EBS [CreateSnapshot](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSnapshot.html) operation, Amazon EBS uses the volume ID as encryption context value. In the `requestParameters` field of a CloudTrail log entry, the encryption context looks similar to the following:
```
"encryptionContext": {
"aws:ebs:id": "vol-0cfb133e847d28be9"
}
```
For encrypted snapshots created with the Amazon EC2 [CopySnapshot](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CopySnapshot.html) operation, Amazon EBS uses the snapshot ID as encryption context value. In the `requestParameters` field of a CloudTrail log entry, the encryption context looks similar to the following:
```
"encryptionContext": {
"aws:ebs:id": "snap-069a655b568de654f"
}
```
## Detecting Amazon EBS failures
To create an encrypted EBS volume or attach the volume to an EC2 instance, Amazon EBS and the Amazon EC2 infrastructure must be able to use the KMS key that you specified for EBS volume encryption. When the KMS key is not usable—for example, when its [key state](key-state.md) is not `Enabled` —the volume creation or volume attachment fails.
In this case, Amazon EBS sends an *event* to Amazon EventBridge (formerly CloudWatch Events) to notify you about the failure. In EventBridge, you can establish rules that trigger automatic actions in response to these events. For more information, see [Amazon CloudWatch Events for Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-cloud-watch-events.html) in the *Amazon EBS User Guide*, especially the following sections:
+ [Invalid Encryption Key on Volume Attach or Reattach](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-cloud-watch-events.html#attach-fail-key)
+ [Invalid Encryption Key on Create Volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-cloud-watch-events.html#create-fail-key)
To fix these failures, ensure that the KMS key that you specified for EBS volume encryption is enabled. To do this, first [view the KMS key](viewing-keys.md) to determine its current key state (the **Status** column in the AWS Management Console). Then, see the information at one of the following links:
+ If the KMS key's key state is disabled, [enable it](enabling-keys.md).
+ If the KMS key's key state is pending import, [import key material](importing-keys.md).
+ If the KMS key's key state is pending deletion, [cancel key deletion](deleting-keys-scheduling-key-deletion.md).
## Using AWS CloudFormation to create encrypted Amazon EBS volumes
You can use [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/) to create encrypted Amazon EBS volumes. For more information, see [AWS::EC2::Volume](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volume.html) in the *AWS CloudFormation User Guide*.
# How Amazon EMR uses AWS KMS
When you use an [Amazon EMR](https://aws.amazon.com/emr/) cluster, you can configure the cluster to encrypt data *at rest* before saving it to a persistent storage location. You can encrypt data at rest on the EMR File System (EMRFS), on the storage volumes of cluster nodes, or both. To encrypt data at rest, you can use an AWS KMS key. The following topics explain how an Amazon EMR cluster uses a KMS key to encrypt data at rest.
**Important**
Amazon EMR supports only [symmetric KMS keys](symm-asymm-choose-key-spec.md#symmetric-cmks). You cannot use an [asymmetric KMS key](symmetric-asymmetric.md) to encrypt data at rest in an Amazon EMR cluster. For help determining whether a KMS key is symmetric or asymmetric, see [Identify different key types](identify-key-types.md).
Amazon EMR clusters also encrypt data *in transit*, which means the cluster encrypts data before sending it through the network. You cannot use a KMS key to encrypt data in transit. For more information, see [In-Transit Data Encryption](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options.html#emr-encryption-intransit) in the *Amazon EMR Management Guide*.
For more information about all the encryption options available in Amazon EMR, see [Encryption Options](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options.html) in the *Amazon EMR Management Guide*.
**Topics**
+ [
## Encrypting data on the EMR file system (EMRFS)
](#emrfs-encryption)
+ [
## Encrypting data on the storage volumes of cluster nodes
](#emr-local-disk-encryption)
+ [
## Encryption context
](#emr-encryption-context)
## Encrypting data on the EMR file system (EMRFS)
Amazon EMR clusters use two distributed files systems:
+ The Hadoop Distributed File System (HDFS). HDFS encryption does not use a KMS key in AWS KMS.
+ The EMR File System (EMRFS). EMRFS is an implementation of HDFS that allows Amazon EMR clusters to store data in Amazon Simple Storage Service (Amazon S3). EMRFS supports four encryption options, two of which use a KMS key in AWS KMS. For more information about all four of the EMRFS encryption options, see [Encryption Options](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-data-encryption-options.html) in the *Amazon EMR Management Guide*.
The two EMRFS encryption options that use a KMS key use the following encryption features offered by Amazon S3:
+ [Protecting data using server-side encryption with AWS Key Management Service (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html). The Amazon EMR cluster sends data to Amazon S3. Amazon S3 uses a KMS key to encrypt the data before saving it to an S3 bucket. For more information about how this works, see [Process for encrypting data on EMRFS with SSE-KMS](#emrfs-encryption-sse-kms).
+ [Protecting data using client-side encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) (CSE-KMS). Data in an Amazon EMR is encrypted under an AWS KMS key before it's sent to Amazon S3 for storage. For more information about how this works, see [Process for encrypting data on EMRFS with CSE-KMS](#emrfs-encryption-cse-kms).
When you configure an Amazon EMR cluster to encrypt data on EMRFS with a KMS key, you choose the KMS key that you want Amazon S3 or the Amazon EMR cluster to use. With SSE-KMS, you can choose the AWS managed key for Amazon S3 with the alias **aws/s3**, or a symmetric customer managed key that you create. With client-side encryption, you must choose a symmetric customer managed key that you create. When you choose a customer managed key, you must ensure that your Amazon EMR cluster has permission to use the KMS key. For more information, see [Using AWS KMS keys for encryption](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html#emr-awskms-keys) in the *Amazon EMR Management Guide*.
For both server-side and client-side encryption, the KMS key you choose is the root key in an [envelope encryption](kms-cryptography.md#enveloping) workflow. The data is encrypted with a unique [data key](data-keys.md) that is encrypted under the KMS key in AWS KMS. The encrypted data and an encrypted copy of its data key are stored together as a single encrypted object in an S3 bucket. For more information about how this works, see the following topics.
**Topics**
+ [
### Process for encrypting data on EMRFS with SSE-KMS
](#emrfs-encryption-sse-kms)
+ [
### Process for encrypting data on EMRFS with CSE-KMS
](#emrfs-encryption-cse-kms)
### Process for encrypting data on EMRFS with SSE-KMS
When you configure an Amazon EMR cluster to use SSE-KMS, the encryption process works like this:
1. The cluster sends data to Amazon S3 for storage in an S3 bucket.
1. Amazon S3 sends a [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) request to AWS KMS, specifying the key ID of the KMS key that you chose when you configured the cluster to use SSE-KMS. The request includes encryption context; for more information, see [Encryption context](#emr-encryption-context).
1. AWS KMS generates a unique data encryption key (data key) and then sends two copies of this data key to Amazon S3. One copy is unencrypted (plaintext), and the other copy is encrypted under the KMS key.
1. Amazon S3 uses the plaintext data key to encrypt the data that it received in step 1, and then removes the plaintext data key from memory as soon as possible after use.
1. Amazon S3 stores the encrypted data and the encrypted copy of the data key together as a single encrypted object in an S3 bucket.
The decryption process works like this:
1. The cluster requests an encrypted data object from an S3 bucket.
1. Amazon S3 extracts the encrypted data key from the S3 object, and then sends the encrypted data key to AWS KMS with a [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) request. The request includes an [encryption context](encrypt_context.md).
1. AWS KMS decrypts the encrypted data key using the same KMS key that was used to encrypt it, and then sends the decrypted (plaintext) data key to Amazon S3.
1. Amazon S3 uses the plaintext data key to decrypt the encrypted data, and then removes the plaintext data key from memory as soon as possible after use.
1. Amazon S3 sends the decrypted data to the cluster.
### Process for encrypting data on EMRFS with CSE-KMS
When you configure an Amazon EMR cluster to use CSE-KMS, the encryption process works like this:
1. When it's ready to store data in Amazon S3, the cluster sends a [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) request to AWS KMS, specifying the key ID of the KMS key that you chose when you configured the cluster to use CSE-KMS. The request includes encryption context; for more information, see [Encryption context](#emr-encryption-context).
1. AWS KMS generates a unique data encryption key (data key) and then sends two copies of this data key to the cluster. One copy is unencrypted (plaintext), and the other copy is encrypted under the KMS key.
1. The cluster uses the plaintext data key to encrypt the data, and then removes the plaintext data key from memory as soon as possible after use.
1. The cluster combines the encrypted data and the encrypted copy of the data key together into a single encrypted object.
1. The cluster sends the encrypted object to Amazon S3 for storage.
The decryption process works like this:
1. The cluster requests the encrypted data object from an S3 bucket.
1. Amazon S3 sends the encrypted object to the cluster.
1. The cluster extracts the encrypted data key from the encrypted object, and then sends the encrypted data key to AWS KMS with a [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) request. The request includes [encryption context](encrypt_context.md).
1. AWS KMS decrypts the encrypted data key using the same KMS key that was used to encrypt it, and then sends the decrypted (plaintext) data key to the cluster.
1. The cluster uses the plaintext data key to decrypt the encrypted data, and then removes the plaintext data key from memory as soon as possible after use.
## Encrypting data on the storage volumes of cluster nodes
An Amazon EMR cluster is a collection of Amazon Elastic Compute Cloud (Amazon EC2) instances. Each instance in the cluster is called a *cluster node* or *node*. Each node can have two types of storage volumes: instance store volumes, and Amazon Elastic Block Store (Amazon EBS) volumes. You can configure the cluster to use [Linux Unified Key Setup (LUKS)](https://gitlab.com/cryptsetup/cryptsetup/blob/master/README.md) to encrypt both types of storage volumes on the nodes (but not the boot volume of each node). This is called *local disk encryption*.
When you enable local disk encryption for a cluster, you can choose to encrypt the LUKS key with a KMS key in AWS KMS. You must choose a [customer managed key](concepts.md#customer-mgn-key) that you create; you cannot use an [AWS managed key](concepts.md#aws-managed-key). If you choose a customer managed key, you must ensure that your Amazon EMR cluster has permission to use the KMS key. For more information, see [Using AWS KMS keys for encryption](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-encryption-enable.html#emr-awskms-keys) in the *Amazon EMR Management Guide*.
When you enable local disk encryption using a KMS key, the encryption process works like this:
1. When each cluster node launches, it sends a [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) request to AWS KMS, specifying the key ID of the KMS key that you chose when you enabled local disk encryption for the cluster.
1. AWS KMS generates a unique data encryption key (data key) and then sends two copies of this data key to the node. One copy is unencrypted (plaintext), and the other copy is encrypted under the KMS key.
1. The node uses a base64-encoded version of the plaintext data key as the password that protects the LUKS key. The node saves the encrypted copy of the data key on its boot volume.
1. If the node reboots, the rebooted node sends the encrypted data key to AWS KMS with a [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) request.
1. AWS KMS decrypts the encrypted data key using the same KMS key that was used to encrypt it, and then sends the decrypted (plaintext) data key to the node.
1. The node uses the base64-encoded version of the plaintext data key as the password to unlock the LUKS key.
## Encryption context
Each AWS service integrated with AWS KMS can specify an [encryption context](encrypt_context.md) when the service uses AWS KMS to generate data keys or to encrypt or decrypt data. Encryption context is additional authenticated information that AWS KMS uses to check for data integrity. When a service specifies encryption context for an encryption operation, it must specify the same encryption context for the corresponding decryption operation or decryption will fail. Encryption context is also written to AWS CloudTrail log files, which can help you understand why a specific KMS key was used.
The following section explain the encryption context that is used in each Amazon EMR encryption scenario that uses a KMS key.
### Encryption context for EMRFS encryption with SSE-KMS
With SSE-KMS, the Amazon EMR cluster sends data to Amazon S3, and then Amazon S3 uses a KMS key to encrypt the data before saving it to an S3 bucket. In this case, Amazon S3 uses the Amazon Resource Name (ARN) of the S3 object as encryption context with each [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) and [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) request that it sends to AWS KMS. The following example shows a JSON representation of the encryption context that Amazon S3 uses.
```
{ "aws:s3:arn" : "arn:aws:s3:::S3_bucket_name/S3_object_key" }
```
### Encryption context for EMRFS encryption with CSE-KMS
With CSE-KMS, the Amazon EMR cluster uses a KMS key to encrypt data before sending it to Amazon S3 for storage. In this case, the cluster uses the Amazon Resource Name (ARN) of the KMS key as encryption context with each [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) and [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) request that it sends to AWS KMS. The following example shows a JSON representation of the encryption context that the cluster uses.
```
{ "kms_cmk_id" : "arn:aws:kms:us-east-2:111122223333:key/0987ab65-43cd-21ef-09ab-87654321cdef" }
```
### Encryption context for local disk encryption with LUKS
When an Amazon EMR cluster uses local disk encryption with LUKS, the cluster nodes do not specify encryption context with the [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) and [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) requests that they send to AWS KMS.
# How Amazon Redshift uses AWS KMS
This topic discusses how Amazon Redshift uses AWS KMS to encrypt data.
**Topics**
+ [
## Amazon Redshift encryption
](#rs-encryption)
+ [
## Encryption context
](#rs-encryptioncontext)
## Amazon Redshift encryption
An Amazon Redshift data warehouse is a collection of computing resources called nodes, which are organized into a group called a cluster. Each cluster runs an Amazon Redshift engine and contains one or more databases.
Amazon Redshift uses a four-tier, key-based architecture for encryption. The architecture consists of data encryption keys, a database key, a cluster key, and a root key. You can use an AWS KMS key as the root key.
Data encryption keys encrypt data blocks in the cluster. Each data block is assigned a randomly-generated AES-256 key. These keys are encrypted by using the database key for the cluster.
The database key encrypts data encryption keys in the cluster. The database key is a randomly-generated AES-256 key. It is stored on disk in a separate network from the Amazon Redshift cluster and passed to the cluster across a secure channel.
The cluster key encrypts the database key for the Amazon Redshift cluster. You can use AWS KMS, AWS CloudHSM, or an external hardware security module (HSM) to manage the cluster key. See the [ Amazon Redshift Database Encryption ](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-db-encryption.html) documentation for more details.
You can request encryption by checking the appropriate box in the Amazon Redshift console. You can specify a [customer managed key](concepts.md#customer-mgn-key) by choosing one from the list that appears below the encryption box. If you do not specify a customer managed key, Amazon Redshift uses the [AWS managed key](concepts.md#aws-managed-key) for Amazon Redshift under your account.
**Important**
Amazon Redshift supports only symmetric encryption KMS keys. You cannot use an asymmetric KMS key in an Amazon Redshift encryption workflow. For help determining whether a KMS key is symmetric or asymmetric, see [Identify different key types](identify-key-types.md).
## Encryption context
Each service that is integrated with AWS KMS specifies an [encryption context](encrypt_context.md) when requesting data keys, encrypting, and decrypting. The encryption context is additional authenticated data (AAD) that AWS KMS uses to check for data integrity. That is, when an encryption context is specified for an encryption operation, the service also specifies it for the decryption operation or decryption will not succeed. Amazon Redshift uses the cluster ID and the creation time for the encryption context. In the `requestParameters` field of a CloudTrail log file, the encryption context will look similar to this.
```
"encryptionContext": {
"aws:redshift:arn": "arn:aws:redshift:region:account_ID:cluster:cluster_name",
"aws:redshift:createtime": "20150206T1832Z"
},
```
You can search on the cluster name in your CloudTrail logs to understand what operations were performed by using an AWS KMS key (KMS key). The operations include cluster encryption, cluster decryption, and generating data keys.