AWS Key Management Service (KMS) gives you centralized control over the cryptographic keys used to protect your data. The service is integrated with other AWS services making it easy to encrypt data you store in these services and control access to the keys that decrypt it. AWS KMS is also integrated with AWS CloudTrail, which provides you the ability to audit who used which keys, on which resources, and when. AWS KMS enables developers to easily add encryption or digital signature functionality to their application code either directly or by using the AWS SDK. The AWS Encryption SDK supports AWS KMS as a master key provider for developers who need to encrypt/decrypt data locally within their applications.
Centralized Key Management
AWS KMS provides you with centralized control over the lifecycle and permissions of your keys. You can create new keys whenever you wish, and you can control who can manage keys separately from who can use them. As an alternative to using keys generated by AWS KMS, you can import keys from your own key management infrastructure, or use keys stored in your AWS CloudHSM cluster. You can choose automatic rotation of master keys generated in AWS KMS once per year without the need to re-encrypt previously encrypted data. The service automatically keeps older versions of the master key available to decrypt previously encrypted data. You can manage your master keys and audit their usage from the AWS Management Console or by using the AWS SDK or AWS Command Line Interface (CLI).
* The option to import keys is not available for asymmetric keys.
AWS Service Integration
AWS KMS integrates with AWS services to encrypt data at rest, or to facilitate signing and verification using an AWS KMS customer master key (CMK). To protect data at rest, integrated AWS services use envelope encryption, where a data key is used to encrypt data, and is itself encrypted under a CMK stored in AWS KMS. For signing and verification, integrated AWS services use a key pair from an asymmetric CMK in AWS KMS. For more details about how an integrated service uses AWS KMS, see the documentation for your AWS service.
There are two types of CMK resources that can be created in your AWS account: (i) An AWS managed CMK can be created automatically when needed. You can list or inventory AWS Managed CMKs and receive a record of their use in AWS CloudTrail, but permissions for the resource are managed by the AWS service it was created to be used with. (ii) A customer managed CMK gives you the highest degree of control over the the permissions and lifecycle of the key.
|Alexa for Business*||Amazon Fraud Detector||Amazon Relational Database Service (RDS)||AWS CodeCommit*|
|Amazon AppFlow||Amazon FSx for Windows File Server||Amazon Route 53||AWS CodePipeline|
|Amazon Athena||Amazon GuardDuty||Amazon S3||AWS Database Migration Service|
|Amazon Aurora||Amazon Kendra||Amazon SageMaker||AWS Glue|
|Amazon CloudWatch Logs||Amazon Keyspaces (for Apache Cassandra)||Amazon Simple Email Service (SES)||AWS Glue DataBrew|
|Amazon CodeGuru||Amazon Kinesis Data Streams||Amazon Simple Notification Service (SNS)||AWS IoT SiteWise|
|Amazon Comprehend||Amazon Kinesis Firehose||Amazon Simple Queue Service (SQS)||AWS Lambda|
|Amazon Connect||Amazon Kinesis Video Streams||Amazon Textract||AWS License Manager|
|Amazon Connect Customer Profiles||Amazon Lex||Amazon Timestream||AWS Proton|
|Amazon DocumentDB||Amazon Lightsail*||Amazon Transcribe||AWS Secrets Manager|
|Amazon DynamoDB||Amazon Location Service||Amazon Translate||AWS Snowball|
|Amazon DynamoDB Accelerator (DAX)*||Amazon Lookout for Equipment||Amazon WorkMail||AWS Snowball Edge|
|Amazon EBS||Amazon Lookout for Metrics||Amazon WorkSpaces||AWS Snowcone|
|Amazon EC2 Image Builder||Amazon Lookout for Vision||AWS Audit Manager||AWS Snowmobile|
|Amazon EFS||Amazon Macie||AWS Application Cost Profiler||AWS Storage Gateway|
|Amazon Elastic Container Registry (ECR)||Amazon Managed Streaming for Kafka (MSK)||AWS App Runner||AWS Systems Manager|
|Amazon Elastic Kubernetes Service (EKS)||Amazon Managed Workflows for Apache Airflow (MWAA)||AWS Backup||AWS X-Ray|
|Amazon Elastic Transcoder||Amazon Monitron||AWS Certificate Manager*|
|Amazon ElastiCache||Amazon MQ||AWS Cloud9*|
|Amazon Elasticsearch||Amazon Neptune||AWS CloudHSM|
|Amazon EMR||Amazon Nimble Studio||AWS CloudTrail|
|Amazon FinSpace||Amazon Personalize||AWS CodeArtifact|
|Amazon Forecast||Amazon Redshift||AWS CodeBuild|
*Supports only AWS managed AWS KMS keys.
** For list of services integrated with AWS KMS in the AWS China (Beijing) Region, operated by Sinnet and the AWS China (Ningxia) Region, operated by NWCD, please visit AWS KMS Service integration in China.
AWS services not listed above encrypt customer data using keys owned and managed by the respective service.
If you have AWS CloudTrail enabled for your AWS account, each request you make to AWS KMS is recorded in a log file that is delivered to the Amazon S3 bucket that you specified when you enabled AWS CloudTrail. The information recorded includes details of the user, time, date, API action and, when relevant, the key used.
Scalability, Durability, and High Availability
AWS KMS is a fully managed service. As your use of encryption grows, the service automatically scales to meet your needs. It enables you to manage thousands of CMKs in your account and to use them whenever you want. It defines default limits for number of keys and request rates, but you can request increased limits if necessary.
The CMKs you create or ones that are created on your behalf by other AWS services cannot be exported from the service. Therefore AWS KMS takes responsibility for their durability. To help ensure that your keys and your data is highly available, it stores multiple copies of encrypted versions of your keys in systems that are designed for 99.999999999% durability.
If you import keys into the service, you maintain a secure copy of the CMKs so that you can re-import them if they are not available when you need to use them. If you use the custom key store feature to create your CMKs in an AWS CloudHSM cluster, encrypted copies of your keys are automatically backed up and you have full control over the recovery process.
For encrypted data or digital signature workflows that move across Regions (disaster recovery, multi-Region high availability architectures, DynamoDB Global Tables, and globally distributed consistent digital signatures), you can create KMS multi-Region keys, a set of interoperable keys with the same key material and key IDs that can be replicated into multiple Regions.
AWS KMS is designed to be a highly available service with a regional API endpoint. As most AWS services rely on it for encryption and decryption, it is architected to provide a level of availability that supports the rest of AWS and is backed by the AWS KMS Service Level Agreement.
AWS KMS is designed so that no one, including AWS employees, can retrieve your plaintext keys from the service. The service uses hardware security modules (HSMs) that have been validated under FIPS 140-2, or are in the process of being validated, to protect the confidentiality and integrity of your keys. Your plaintext keys are never written to disk and only ever used in volatile memory of the HSMs for the time needed to perform your requested cryptographic operation. This is true regardless of whether you request AWS KMS to create keys on your behalf, import them into the service, or create them in an AWS CloudHSM cluster using the custom key store feature. Keys created by the service AWS KMS are never transmitted outside of the AWS region in which they were created and can only be used in the region in which they were created. Updates to the AWS KMS HSM firmware are controlled by multi-party access control that is audited and reviewed by an independent group within Amazon as well as a NIST accredited lab in compliance with FIPS 140-2.
To learn more about how AWS KMS is architected and the cryptography it uses to secure your keys, read more about the AWS Key Management Service Cryptographic Details.
* In the AWS China (Beijing) Region, operated by Sinnet and the AWS China (Ningxia) Region, operated by NWCD, the HSMs are Chinese government approved (not FIPS 140-2 validated), and the Cryptographic Details Whitepaper mentioned above does not apply.
Custom Key Store
AWS KMS provides the option for you to create your own key store using HSMs that you control. Each custom key store is backed by an AWS CloudHSM cluster. When you create a CMK in a custom key store, the service generates and stores key material for the CMK in an AWS CloudHSM cluster that you own and manage. When you use a CMK in a custom key store, the cryptographic operations under that key are performed in your AWS CloudHSM cluster.
CMKs stored in a custom key store are managed by you like any other CMK and can be used with any AWS service that integrates with AWS KMS.
The use of a custom key store involves the additional cost of the AWS CloudHSM cluster and makes you responsible for the availability of the key material in that cluster. For guidance on whether custom key stores are a good fit for your requirements you can read this blog.
* The Custom Key Store feature is not available in the AWS China (Beijing) Region, operated by Sinnet and the AWS China (Ningxia) Region, operated by NWCD.
** The Custom Key Store option is not available for asymmetric CMKs.
AWS KMS provides you the capability to create and use asymmetric CMKs and data key pairs. You can designate a CMK for use as a signing key pair or an encryption key pair. Key pair generation and asymmetric cryptographic operations using these CMKs are performed inside HSMs. You can request the public portion of the asymmetric CMK for use in your local applications, while the private portion never leaves the service.
You can also request the service to generate an asymmetric data key pair. This operation returns a plaintext copy of the public key and private key as well as a copy of the private key encrypted under a symmetric CMK that you specify. You can use the plaintext public or private key in your local application and store the encrypted copy of the private key for future use.
* Asymmetric keys are not available in the AWS China (Beijing) Region, operated by Sinnet and the AWS China (Ningxia) Region, operated by NWCD.
** Asymmetric keys are not supported with the Custom Key Store option.
Security and quality controls in AWS KMS have been validated and certified by the following compliance regimes:
- AWS Service Organization Controls (SOC 1, SOC 2, and SOC 3) Reports. You can download a copy of these reports from AWS Artifact.
- PCI DSS Level 1. For more details on PCI DSS compliant services in AWS, you can read the PCI DSS FAQs.
- FIPS 140-2. The AWS KMS cryptographic module is validated, or in the process of being validated, at FIPS 140-2 Level 2 overall with Level 3 for several other categories, including physical security. For more details, you can view the FIPS 140-2 certificate for AWS KMS HSM along with the associated Security Policy.
- FedRAMP. You can get more details on AWS FedRAMP compliance at FedRAMP Compliance.
- HIPAA. For more details, you can visit the HIPAA Compliance page.