AWS History and Timeline regarding AWS Key Management Service - Overview, Functions, Features, Summary of Updates, and Introduction to KMS

First Published:
Last Updated:

This is the sixth installment in the series that I started with the "AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)", where I extract features from the history and timeline of AWS services (I've previously written about Amazon S3, AWS Systems Manager, Amazon Route 53, Amazon EventBridge).

This time, I have created a historical timeline for AWS Key Management Service (AWS KMS), a service that provides advanced encryption features across AWS.
Just like before, I am summarizing the main features while following the birth of AWS KMS and tracking its feature additions and updates as a "Current Overview, Functions, Features of AWS KMS".
I hope these will provide clues as to what has remained the same and what has changed, in addition to the features and concepts of each AWS service.

Background and Method of Creating AWS KMS Historical Timeline

This time, the reason for creating a historical timeline of AWS KMS is that since AWS KMS was launched in 2014, it has been widely providing encryption functions, which are at the core of security, across all AWS services. Therefore, I decided to organize the information of AWS KMS with the following approaches.
  • Tracking the history of AWS KMS and organizing the transition of updates
  • Summarizing the feature list and characteristics of AWS KMS
This timeline primarily references the following blogs and document history regarding AWS KMS.
There may be slight variations in the dates on the timeline due to differences in the timing of announcements or article postings in the references used.
The content posted is limited to major features related to the current AWS KMS and necessary for the feature list and overview description.
In other words, please note that the items on this timeline are not all updates to AWS KMS features, but are representative updates that I have picked out.

AWS KMS Historical Timeline (Updates from November 12, 2014)

Now, from here is the timeline regarding the features of AWS KMS. The history of AWS KMS spans more than ten years from November 2014.

2014 | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | 2021 | 2022 | 2023 | 2024 | 2025 | 2026

* You can sort the table by clicking on the column name.
Date Summary
2014-11-12 AWS Key Management Service (AWS KMS) is announced as General Availability (GA).
Amazon S3, Amazon EBS, Amazon Redshift support encryption by AWS KMS. [Source]
2014-11-24 Amazon Elastic Transcoder supports encryption by AWS KMS. [Source]
2015-01-06 Amazon Relational Database Service (Amazon RDS) supports encryption by AWS KMS. [Source]
2015-01-28 Amazon WorkMail supports encryption by AWS KMS. [Source]
2015-10-01 Amazon Simple Email Service (Amazon SES) supports encryption by AWS KMS. [Source]
2015-10-01 AWS CloudTrail supports encryption by AWS KMS. [Source]
2015-10-02 Amazon WorkSpaces supports encryption by AWS KMS. [Source]
2015-10-15 It becomes possible to schedule the deletion of AWS KMS keys after a waiting period of 7 to 30 days. [Source]
2015-12-07 Amazon Aurora supports encryption by AWS KMS. [Source]
2015-12-15 Amazon EC2's EBS boot volume supports encryption by AWS KMS. [Source]
2016-08-11 It becomes possible to import your own key material into symmetric KMS keys. [Source]
2016-08-31 Metrics about AWS KMS are added to Amazon CloudWatch. [Source]
2016-12-01 EC2 Systems Manager (later AWS Systems Manager)'s Parameter Store supports encryption by AWS KMS with SecureString. [Source]
2017-02-15 Tagging of KMS keys is supported. [Source]
2017-04-28 Amazon Simple Queue Service (SQS) supports encryption by AWS KMS. [Source]
2017-07-06 Amazon Kinesis Data Streams supports encryption by AWS KMS. [Source]
2017-08-14 Amazon Elastic File System (EFS) supports encryption by AWS KMS. [Source]
2017-12-07 Amazon Elasticsearch Service (later Amazon OpenSearch Service) supports encryption by AWS KMS. [Source]
2017-12-08 Amazon CloudWatch Logs supports encryption by AWS KMS. [Source]
2018-01-17 Amazon SageMaker's training and hosting storage volumes now support encryption by AWS KMS. [Source]
2018-01-22 AWS KMS can now be privately accessed via the Amazon VPC interface endpoint using AWS PrivateLink. [Source]
2018-02-08 Amazon DynamoDB now supports encryption by AWS managed keys. [Source]
2018-04-05 AWS Secrets Manager now supports encryption by AWS KMS. [Source]
2018-04-25 AWS X-Ray now supports encryption by AWS KMS. [Source]
2018-08-01 AWS Storage Gateway now supports encryption by AWS KMS. [Source]
2018-08-09 Amazon DynamoDB Accelerator (DAX) now supports encryption by AWS managed keys. [Source]
2018-09-04 AWS Glue ETL jobs and development endpoints now support encryption by AWS KMS. [Source]
2018-11-07 Amazon SageMaker Batch Transform now supports encryption by AWS KMS. [Source]
2018-11-15 Amazon SNS now supports encryption by AWS KMS. [Source]
2018-11-15 Amazon DynamoDB now implements encryption for all existing tables using AWS-owned keys. [Source]
2018-11-19 AWS Server Migration Service now supports AWS KMS encryption of on-premises server volume AMIs. [Source]
2018-11-26 AWS KMS now allows generation, storage, and use of KMS keys in a custom key store using an AWS CloudHSM cluster. [Source]
2019-03-28 Amazon Comprehend now supports encryption by AWS KMS. [Source]
2019-04-04 AWS Systems Manager Session Manager now supports encryption by AWS KMS. [Source]
2019-07-22 Amazon MQ supports encryption by AWS KMS. [Source]
2019-08-29 Amazon ElastiCache for Redis supports encryption by AWS KMS. [Source]
2019-09-24 Amazon Transcribe supports encryption by AWS KMS. [Source]
2019-11-04 AWS KMS supports Hybrid Post-Quantum TLS (hybrid post-quantum TLS) as a hybrid post-quantum key exchange option for the Transport Layer Security (TLS) network encryption protocol used to connect to AWS KMS API endpoints. [Source]
2019-11-15 Key policies for AWS-managed keys can now be displayed in the AWS KMS console. [Source]
2019-11-25 AWS KMS supports asymmetric keys and asymmetric data key pairs for RSA, Elliptic Curve (ECC). [Source]
2019-11-26 Amazon Kinesis Data Firehose supports encryption by AWS KMS. [Source]
2019-11-26 Amazon DynamoDB supports encryption by customer-managed keys. [Source]
2020-02-24 Amazon FSx for Lustre supports encryption by AWS KMS. [Source]
2020-03-05 Amazon Elastic Kubernetes Service (EKS) supports AWS KMS encryption of Kubernetes secrets. [Source]
2020-07-07 Amazon EMR supports AWS KMS encryption of log files. [Source]
2020-07-14 AWS KMS supports VPC endpoint policies. [Source]
2020-07-29 Amazon Elastic Container Registry (ECR) supports encryption by AWS KMS. [Source]
2020-11-06 Amazon DynamoDB Global Tables support encryption by customer-managed keys. [Source]
2020-11-17 Amazon SageMaker Studio supports encryption by AWS KMS. [Source]
2020-11-19 Amazon Textract now supports encryption via AWS KMS. [Source]
2020-12-17 Amazon Route 53's Domain Name System Security Extensions (DNSSEC) signing with AWS KMS's asymmetric customer-managed keys is announced. [Source]
2020-12-17 AWS KMS supports attribute-based access control (ABAC) in key policies. [Source]
2021-01-27 AWS KMS encryption can be applied to existing domains in Amazon Elasticsearch Service (later Amazon OpenSearch Service). [Source]
2021-03-01 AWS KMS encryption of Kubernetes secrets can be applied to existing clusters in Amazon Elastic Kubernetes Service (EKS). [Source]
2021-04-19 Amazon Comprehend supports enforcing Amazon VPC rules for jobs and AWS KMS customer managed key encryption for custom models. [Source]
2021-05-05 Amazon CodeGuru Reviewer supports encryption with customer-managed keys. [Source]
2021-06-01 Amazon Keyspaces supports encryption with customer-managed keys. [Source]
2021-06-10 Amazon Managed Blockchain supports encryption with customer-managed keys. [Source]
2021-06-16 Supports multi-region keys that can replicate a KMS key created in one region to another region to perform encryption operations. [Source]
2021-06-25 Amazon Rekognition Custom Labels now supports encryption via AWS KMS. [Source]
2021-07-23 Amazon QLDB supports encryption with customer-managed keys. [Source]
2021-07-28 AWS Control Tower supports AWS KMS encryption for AWS services it deploys and Amazon S3 data. [Source]
2021-08-30 The term previously used, "Customer Master Key (CMK)", is replaced with "AWS KMS key" and "KMS key".
* No functional changes. [Source]
2021-10-14 Amazon SageMaker Data Wrangler now supports encryption via AWS KMS. [Source]
2021-11-05 Amazon Translate now supports encryption via AWS KMS. [Source]
2022-01-31 Amazon SageMaker JumpStart now supports encryption via AWS KMS. [Source]
2022-03-16 AWS KMS supports the latest hybrid post-quantum TLS. [Source]
2022-04-19 AWS KMS supports HMAC KMS keys that can generate and verify hash-based message authentication codes (HMAC). [Source]
2022-07-28 Amazon SageMaker Canvas supports encryption with customer-managed keys. [Source]
2022-08-25 Amazon CloudFront's Origin Access Control (OAC) now allows the use of SSE-KMS encrypted data at Amazon S3 origins. [Source]
2022-11-29 AWS KMS now allows generation, storage, and use of KMS keys in a custom key store using a External Key Store outside of AWS. [Source]
2023-01-05 Amazon S3 now automatically encrypts all new objects with SSE-S3 by default. Amazon S3 applies server-side encryption (SSE-S3, 256-bit AES) as the base level of encryption for all new objects, and customers can still choose SSE-KMS (encryption with AWS KMS keys), DSSE-KMS, or SSE-C instead. [Source]
2023-05-24 The hardware security modules (HSMs) used in AWS KMS are certified at FIPS 140-2 Security Level 3. AWS KMS HSMs had been certified at FIPS 140-2 overall Security Level 2 continuously since 2017; the new certification assures that all cryptographic operations involving customer keys in AWS KMS happen within an HSM certified at FIPS 140-2 Security Level 3. [Source]
2023-06-05 It becomes possible to import your own asymmetric and HMAC key material into AWS KMS. This extends the bring-your-own-key (BYOK) import model, previously limited to symmetric encryption keys, to RSA, elliptic curve, and HMAC key material (EXTERNAL origin), giving direct control over key generation, lifecycle, and durability. [Source]
2024-04-12 Flexible automatic key rotation periods and on-demand rotation are introduced for customer managed keys. The automatic rotation period for symmetric encryption KMS keys can be customized from 90 days up to 2,560 days (about 7 years), and rotation can also be triggered immediately with the new on-demand rotation capability regardless of the automatic schedule. [Source]
2024-06-17 AWS KMS supports Elliptic Curve Diffie-Hellman (ECDH) key agreement. Two parties can derive a shared secret by combining their own elliptic curve KMS key with another party's public key, entirely within the AWS KMS HSM security boundary, using the new DeriveSharedSecret API and the KEY_AGREEMENT key usage. [Source]
2025-04-07 AWS KMS API endpoints support ML-KEM for hybrid post-quantum TLS key agreement. AWS KMS, AWS Certificate Manager, and AWS Secrets Manager endpoints add support for the NIST-standardized ML-KEM (FIPS 203) in hybrid post-quantum TLS, replacing the earlier pre-standard CRYSTALS-Kyber support, to protect TLS connections against harvest-now-decrypt-later quantum attacks. [Source]
2025-06-06 On-demand key rotation becomes available for symmetric KMS keys with imported key material. Customers using bring-your-own-key (BYOK, EXTERNAL origin) symmetric encryption keys can rotate the underlying key material on demand without changing the key ARN or alias, complementing the on-demand rotation introduced in 2024 for keys with AWS KMS generated key material. [Source]
2025-06-13 AWS KMS supports post-quantum ML-DSA digital signatures. Three new key specs (ML_DSA_44, ML_DSA_65, ML_DSA_87) implement the NIST FIPS 204 Module-Lattice-Based Digital Signature Standard and are usable through the existing CreateKey, Sign, and Verify APIs with the ML_DSA_SHAKE_256 signing algorithm. [Source]
2026-04-27 AWS KMS now tracks the last usage of all KMS keys. The console and API surface when a key was last used for a cryptographic operation, which operation was performed, and the associated AWS CloudTrail event ID, and the new kms:TrailingDaysWithoutKeyUsage IAM condition key lets administrators gate key disabling or deletion on a minimum number of days since last use. [Source]

At the initial stage when AWS KMS was announced as GA, interfaces related to its core internal mechanisms and encryption operations were already established. Therefore, updates to AWS KMS itself are infrequent, such as the addition of KMS key specifications it can handle, or those related to access permissions. On the other hand, updates integrating AWS KMS with other AWS services continue to this day.
The updates regarding the integration of AWS KMS and AWS services mentioned above are only a part, and many new AWS services are compatible with encryption by AWS KMS from the beginning.

Current Overview, Functions, Features of AWS KMS

From here, I introduce the current list of AWS KMS features and overview.
AWS Key Management Service (AWS KMS) is a fully managed service that uses FIPS 140-3 Security Level 3 validated hardware security modules (HSMs) to generate, store, audit, and centrally manage keys used in cryptographic operations, providing a solution for integrated data encryption and decryption across AWS services and cryptographic operations such as data encryption and digital signatures in proprietary applications.
(The HSMs used in AWS KMS were certified at FIPS 140-2 overall Security Level 2 from 2017, upgraded to FIPS 140-2 Security Level 3 on 2023-05-24, and are currently validated at FIPS 140-3 Security Level 3.)

The terms used in AWS KMS at the time of writing this article are referred to by different names than when AWS KMS was first introduced.
Specifically, the name "Customer Master Keys (CMK)" has been replaced with "KMS keys (AWS KMS keys)".
Therefore, in this article, I will refer to the previously used name as the old name and also describe the correspondence with the currently used name.

AWS KMS Use Cases

AWS KMS is typically used in the following scenarios:
  • Encryption at rest across AWS services: Encrypting data stored in AWS services such as Amazon S3, Amazon EBS, Amazon RDS, and Amazon DynamoDB with AWS managed keys or customer managed keys.
  • Envelope encryption in applications: Generating data keys from a symmetric KMS key to encrypt and decrypt application data outside AWS KMS.
  • Digital signatures: Signing and verifying with asymmetric KMS keys (RSA, ECC), including post-quantum ML-DSA signing keys.
  • Message authentication: Generating and verifying hash-based message authentication codes with HMAC KMS keys.
  • Shared secret derivation: Deriving shared secrets between two parties with Elliptic Curve Diffie-Hellman (ECDH) key agreement.
  • Regulatory key control: Meeting compliance requirements with imported key material (BYOK), custom key stores backed by AWS CloudHSM, or the External Key Store (XKS) that keeps key material outside AWS.
  • Multi-Region architectures: Encrypting and decrypting across AWS Regions with multi-Region keys.
  • Access control and auditing: Controlling key usage with key policies, grants, and attribute-based access control (ABAC), and auditing every key usage with AWS CloudTrail.

AWS KMS Key Functions and Features

The main functions and features that AWS KMS currently provides are as follows. Each of them is described in detail in the sections below.
  • KMS keys: Symmetric encryption keys, HMAC keys, asymmetric keys (RSA, ECC, SM2), key agreement (ECDH), and post-quantum ML-DSA signing keys.
  • Key material origins: AWS KMS generated, imported (EXTERNAL), AWS CloudHSM custom key stores, and External Key Store (XKS).
  • Key rotation: Automatic rotation with a customizable rotation period, on-demand rotation, and on-demand rotation of imported key material.
  • Multi-Region keys: Replicating a KMS key to other Regions with the same key material and key ID.
  • Data keys and envelope encryption: Generating data keys and data key pairs for cryptographic operations outside AWS KMS.
  • Access control: Key policies, grants, ABAC, and VPC endpoint policies.
  • Hybrid post-quantum TLS: Protecting connections to AWS KMS API endpoints with ML-KEM based hybrid key agreement.
  • Monitoring and auditing: Amazon CloudWatch metrics, AWS CloudTrail logging, and last-usage tracking of KMS keys.

Key Material

Key Material is a bit string used in cryptographic algorithms to encrypt and decrypt data, which is referred to in the following KMS key.
There are multiple origins of key material (sources that identify the generation method of key material), and for symmetric encryption KMS keys, key material generated by AWS KMS (AWS_KMS), key material imported by oneself (EXTERNAL), key material generated by AWS CloudHSM clusters in custom key stores (AWS_CLOUDHSM), and key material held in an external key manager outside of AWS through the External Key Store (EXTERNAL_KEY_STORE, added on 2022-11-29). If AWS KMS key material is used for symmetric encryption KMS keys, automatic rotation of key material can be set.
Also, each KMS key has a unique key material by default, but you can create multi-region keys with the same key material.

Import of Key Material

The import of key material can be utilized when there is a security requirement to generate key material independently outside of AWS, but the user needs to bear responsibility for the availability and durability of the key material.
Initially, only symmetric KMS keys (including multi-region keys) could import and use your own key material, but since 2023-06-05 it is also possible to import asymmetric (RSA, ECC) and HMAC key material.
The origin of the imported key material will be EXTERNAL.
Key rotation of imported key material used to be a fully manual process, but since 2025-06-06, on-demand rotation of imported key material is supported for symmetric encryption KMS keys without changing the key ARN or alias.

Custom Key Stores

Custom Key Stores are a method of generating key material in an AWS CloudHSM cluster associated with the origin of KMS keys.
When you use a KMS key with a custom key store set as its origin, the key material generation and cryptographic operations will be performed in the HSM inside the AWS CloudHSM cluster.
Custom Key Stores can be used when there is a security requirement to generate and perform cryptographic operations with non-extractable key material within the AWS CloudHSM cluster, without storing key material in a shared environment.
In addition, the External Key Store (XKS), added on 2022-11-29, is a second type of custom key store that lets you keep key material in an external key manager outside of AWS that you control, and AWS KMS forwards cryptographic requests to your external key store proxy. XKS is intended for workloads with regulatory requirements to hold keys outside the cloud provider, at the cost of taking over responsibility for the availability, durability, and latency of the external key manager.

KMS Keys (AWS KMS keys) | Formerly: Customer Master Key (CMK)

KMS keys are logical representations of encryption keys used for encryption and decryption in AWS KMS, equipped with metadata such as KeySpec(Key Specification), KeyUsage, Origin, Enabled, MultiRegion, KeyManager, EncryptionAlgorithms, SigningAlgorithms, Description, CreationDate, CustomerMasterKeySpec, KeyState, KeyId, ARN, AWSAccountId.
KMS keys perform encryption and decryption operations referring to the key material (by default, the key material generated by AWS KMS).

In the case of the subsequent symmetric KMS keys, you can generate data keys used for general encryption and decryption of data without using API operations such as Encrypt and Decrypt outside of AWS KMS (note 1).
(Note 1) In AWS KMS, you either use API operations like Encrypt, Decrypt, or use data keys generated from the KMS key to actually encrypt and decrypt the data. However, in the case where encryption operations are performed within fully managed AWS services, the encryption and decryption flow using data keys may be omitted in the expression of execution, such as "Encrypting with a customer-managed key (a KMS key created by the user)".

KMS keys can be classified into types such as "Customer Managed Keys (Customer-managed keys)", "AWS Managed Keys", and "AWS Owned Keys" depending on the management style. More details will be discussed later.

The metadata of KMS keys mainly includes the following.

KeySpec, KeyUsage

The KMS keys that can be created in AWS KMS can be broadly divided into symmetric keys that use the same key for encryption and decryption, employing a symmetric encryption algorithm, and asymmetric keys that use a pair of different keys for encryption and decryption, utilizing a public key encryption algorithm.
The symmetric and asymmetric keys are classified on the AWS KMS management console as "key types" (however, there is no field called key type in the metadata of the KMS key).

This key type indicating symmetric or asymmetric keys, and the KeySpec and KeyUsage among the metadata of the KMS keys, are interrelated, and the key type, key spec, and key usage are determined, and you can classify KMS keys into the following types according to KeySpec.


Key Type KMS Key Type Classified by KeySpec KeySpec KeyUsage
Symmetric Symmetric KMS Key SYMMETRIC_DEFAULT ENCRYPT_DECRYPT (Encryption and Decryption)
Symmetric HMAC KMS Key HMAC_224, HMAC_256, HMAC_384, HMAC_512 GENERATE_VERIFY_MAC (Generate and Verify HMAC)
Asymmetric Asymmetric KMS Key (RSA Key Pair) RSA_2048, RSA_3072, RSA_4096 ENCRYPT_DECRYPT (Encryption and Decryption)
SIGN_VERIFY (Signing and Verification)
Asymmetric Asymmetric KMS Key (ECC Key Pair) ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521, ECC_SECG_P256K1 SIGN_VERIFY (Signing and Verification)
KEY_AGREEMENT (Deriving Shared Secrets, NIST curves only, added 2024-06-17)
Asymmetric Asymmetric KMS Key (ML-DSA Key Pair, Post-Quantum)
* Added 2025-06-13		 ML_DSA_44, ML_DSA_65, ML_DSA_87 SIGN_VERIFY (Signing and Verification)
Asymmetric Asymmetric KMS Key (SM2 Key Pair)
* Only in the China region		 SM2
* Only in the China region		 ENCRYPT_DECRYPT (Encryption and Decryption)
SIGN_VERIFY (Signing and Verification)
KEY_AGREEMENT (Deriving Shared Secrets)

Origin

This is a field that indicates the origin of the key material that the KMS key is using. The values of this field are as follows:

AWS_KMS: Key material generated by AWS KMS
EXTERNAL: Key material imported independently
AWS_CLOUDHSM: Key material generation by the AWS CloudHSM cluster of the custom key store
EXTERNAL_KEY_STORE: Key material held in an external key manager outside of AWS (External Key Store)

On the AWS Management Console, the field is also labeled as "Origin".

Enabled (Status)

This is a field that indicates whether the target KMS key is enabled. The values of this field are as follows:

True: The target KMS key is enabled  
False: The target KMS key is disabled

On the AWS Management Console, the field is labeled as "Status", and the values are expressed as "Enabled" and "Disabled".

MultiRegion (Regionality)

This is a field that indicates whether it is a multi-region key. Multi-region keys are a feature that enables encryption operations by replica keys by replicating customer-managed keys created in one region to other regions.
Multi-region keys are ultimately an inter-region replica function of KMS keys created in one region and are not global resources.
In addition, multi-region keys can only be specified at creation, and existing single-region keys cannot be changed to multi-region keys.
Multi-region keys can be created for symmetric KMS keys other than custom key stores, HMAC KMS keys, and asymmetric KMS keys.

The values of this field are as follows:

True: It is a multi-region key  
False: It is not a multi-region key (it is a single-region key)

On the AWS Management Console, the field is labeled as "Regionality", and the values are expressed as "Multi-Region" and "Single-Region".

KeyManager

This is a field that indicates whether the KMS key is a "Customer Managed Key" or an "AWS Managed Key". The values of this field are as follows:

CUSTOMER: Customer Managed Key  
AWS: AWS Managed Key

On the AWS Management Console, customer managed keys and AWS managed keys are displayed on separate screens and distinguished.

EncryptionAlgorithms

Encryption algorithms used in KeySpec when ENCRYPT_DECRYPT (encryption and decryption) is specified in KeyUsage by the KMS key are displayed.
On the AWS Management Console, the field is labeled as "Encryption Algorithm", and the encryption algorithms used in KeySpec are displayed.

SigningAlgorithms

Signature algorithms used in KeySpec when GENERATE_VERIFY_MAC (generate and verify HMAC) or SIGN_VERIFY (sign and verify) is specified in KeyUsage by the KMS key are displayed.
On the AWS Management Console, the field is labeled as "MAC Algorithm" or "Signature Algorithm", and the signature algorithms used in KeySpec are displayed.

Description

This is a field where you can describe the KMS key. This field can be edited even after the AWS KMS key is created.
On the AWS Management Console, the field is also labeled as "description".

CreationDate

This is a field where the date and time the KMS key was created is recorded.
On the AWS Management Console, the field is also labeled as "CreationDate".

KeyId

This is a field of a value that uniquely identifies the created KMS key.

ARN

This is a field where the ARN (Amazon Resource Name), which uniquely identifies the created KMS key as an AWS resource, is displayed.
It is expressed as follows using the aforementioned KeyId:

#Format
arn:aws:kms:[AWS Region Identifier]:[AWS Account ID]:key/[KeyId]

#Example
arn:aws:kms:ap-northeast-1:123456789012:key/a2345678-b234-c234-d234-e234567890fg

CustomerMasterKeySpec: *Deprecated Field

As of the time of writing this article, CustomerMasterKeySpec is considered a deprecated field, and it is recommended to use the KeySpec field instead.
At the time of writing this article, it seems that the same value as KeySpec is included.

KeyRotationEnabled (Key Rotation Activation): *Referenced by KeyId

This is a field that indicates whether key rotation is enabled or disabled, managed in connection with the KeyId of the KMS key.
The values of the field are as follows.

True: Key rotation is enabled
False: Key rotation is disabled

Automatic key rotation used to occur on a fixed yearly schedule, but since 2024-04-12, the automatic rotation period for symmetric encryption KMS keys can be customized from 90 days up to 2,560 days, and rotation can also be triggered immediately with on-demand rotation. Since 2025-06-06, on-demand rotation is also available for symmetric encryption keys with imported (EXTERNAL origin) key material.

AliasName: *Referenced by KeyId

This is a field for entering an alias of the KMS key, managed in connection with the KeyId of the KMS key.
In the case of a customer-managed key, the actual value of the AliasName field is the string entered and displayed as an alias by the user in the AWS Management Console, prefixed with alias/.
Also, in the case of AWS-managed keys, the actual value of the AliasName field is the string specified and displayed for each AWS service, prefixed with alias/.

#* In the case of customer-managed keys  
#Format  
alias/[String entered by the user]
#Example
alias/MyKmsKey

#* In the case of AWS-managed keys  
#Format  
alias/[String specified for each AWS service]
#Example
alias/aws/s3
alias/aws/lambda

Policy (Key Policy): *Referenced by KeyId

This is a field for specifying a policy to control access to the KMS key, managed in connection with the KeyId of the KMS key.
In the key policy, you specify the AWS accounts, IAM users, IAM roles, AWS resources, conditions, etc. that can use the KMS key, and set the actions that can be performed on the KMS key.
The policy syntax used in the KMS key policy uses the same JSON policy document structure as IAM.

Next, an example of a key policy for a KMS key is provided.

{
    "Id": "key-consolepolicy-sample",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/admin"
            },
            "Action": [
                "kms:Create*",
                "kms:Describe*",
                "kms:Enable*",
                "kms:List*",
                "kms:Put*",
                "kms:Update*",
                "kms:Revoke*",
                "kms:Disable*",
                "kms:Get*",
                "kms:Delete*",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/admin"
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:DescribeKey",
                "kms:GetPublicKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow attachment of persistent resources",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/admin"
            },
            "Action": [
                "kms:CreateGrant",
                "kms:ListGrants",
                "kms:RevokeGrant"
            ],
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "kms:GrantIsForAWSResource": "true"
                }
            }
        }
    ]
}

Customer Managed Keys | Formerly: Customer Managed CMK

Customer Managed Keys are a type of KMS key management form that users can create, own, and manage within their AWS account.
While you can create a Customer Managed Key according to your needs using AWS KMS, some AWS services allow you to choose between using a Customer Managed Key or an AWS Managed Key when using AWS KMS. If you choose to use a Customer Managed Key, you will have to create a Customer Managed Key.
You can choose whether or not to perform automatic key rotation for a Customer Managed Key.
* The rotation period was originally fixed at once a year (approximately 365 days); since 2024-04-12 it can be customized from 90 days up to 2,560 days, and rotation can also be triggered immediately with on-demand rotation (see the timeline above).

The fields of the metadata that a KMS key has that you can create, edit, and refer to with a Customer Managed Key include the following:

  • Main metadata that can be specified at the time of creation with a Customer Managed Key
KeyUsage, KeySpec, Origin, MultiRegion, Description, KeyRotationEnabled, AliasName, Policy (Key Policy)
  • Main metadata that can be added/edited after creation with a Customer Managed Key
Description, KeyRotationEnabled, AliasName, Policy (Key Policy)
  • Main metadata that can be referred to with a Customer Managed Key
KeyUsage, KeySpec, Origin, Enabled (Status), MultiRegion, KeyManager, EncryptionAlgorithms, SigningAlgorithms, Description, CreationDate, ARN, KeyId, KeyRotationEnabled, AliasName, Policy (Key Policy)

AWS Managed Keys | Formerly: AWS Managed CMK

AWS Managed Keys are a type of KMS key management form that AWS services create on behalf of users within their AWS account when using AWS KMS.
AWS services may automatically create an AWS Managed Key. However, some AWS services allow you to choose between using a Customer Managed Key or an AWS Managed Key when using AWS KMS. If you choose to use an AWS Managed Key, an AWS Managed Key will be created.
The key rotation of AWS Managed Keys is executed once a year.
* As of May 2022, the rotation schedule for AWS Managed Keys has been changed from every three years (approximately 1,095 days) to every year (approximately 365 days).

Although you cannot specify or edit the metadata that a KMS key has in an AWS Managed Key, you can primarily refer to the following:

  • Main metadata that can be referred to with an AWS Managed Key (creation-time specification, post-creation editing not possible)
KeyUsage, KeySpec, Origin, Enabled (Status), MultiRegion, Description, CreationDate, ARN, KeyId, Policy (Key Policy)

AWS Owned Keys | Formerly: AWS Managed CMK

AWS Owned Keys are a type of KMS key that AWS owns and manages and does not create within an individual AWS account for use across multiple AWS accounts.
AWS Owned Keys are not created within an AWS account, so they are not displayed in the AWS KMS console. Some AWS services allow you to choose whether to use a customer-managed key or an AWS owned key when specifying encryption.
The key rotation of AWS owned keys varies depending on the AWS service.

Encryption Operations

Encryption operations are actions taken on AWS KMS via APIs such as the AWS CLI, AWS SDK.
The relationship between the main encryption operations and their KeyUsage is as follows:

Operation KeyUsage Overview
Decrypt ENCRYPT_DECRYPT Decrypt using symmetric keys or asymmetric keys
Encrypt ENCRYPT_DECRYPT Encrypt using symmetric keys or asymmetric keys
ReEncrypt ENCRYPT_DECRYPT Re-encrypt using symmetric keys or asymmetric keys
GenerateDataKey ENCRYPT_DECRYPT Generate a data key with a symmetric key
GenerateDataKeyWithoutPlaintext ENCRYPT_DECRYPT Generate a data key with a symmetric key
* The plaintext data key is not included in the response.
GenerateDataKeyPair ENCRYPT_DECRYPT Generate an asymmetric key pair protected with symmetric key encryption
GenerateDataKeyPairWithoutPlaintext ENCRYPT_DECRYPT Generate an asymmetric key pair protected with symmetric key encryption
* The plaintext private key is not included in the response.
GenerateMac GENERATE_VERIFY_MAC Generate a HMAC key
VerifyMac GENERATE_VERIFY_MAC Verify a HMAC key
Sign SIGN_VERIFY Sign using an asymmetric key
Verify SIGN_VERIFY Verify a signature using an asymmetric key
GenerateRandom N/A Return a cryptographically secure random byte string

Data Key

A Data Key is an encryption key generated from a symmetric KMS key to be used for generic encryption and decryption of data, without using the Encrypt or Decrypt API operations in AWS KMS. However, as we'll discuss later, the Data Key itself is protected using the KMS key and API operations for encryption and decryption, known as Envelope Encryption.

Data Keys can be generated from a specified symmetric KMS key by calling the GenerateDataKey or GenerateDataKeyWithoutPlaintext operation through the AWS CLI, AWS SDK, or other APIs. Upon creation, the following parameters are returned:

KeyId: The KeyId of the symmetric KMS key used to generate the Data Key
Plaintext: The plaintext Data Key to be used for data encryption. It is not returned in GenerateDataKeyWithoutPlaintext.
CiphertextBlob: The encrypted Data Key, which can be stored along with the data to be encrypted

Below is an example of how to use a Data Key with the GenerateDataKey operation:

Example of Encryption Flow Using Data Key

  1. Generate a Data Key by specifying the KeyId of a symmetric KMS key and invoking the GenerateDataKey operation through the AWS CLI, AWS SDK, or other APIs.
  2. Use the Data Key specified in the Plaintext returned by the GenerateDataKey operation to encrypt the data without using the Encrypt API operation.
  3. Do not save the Data Key specified in Plaintext anywhere, and discard it from memory.
  4. Store the encrypted data along with the CiphertextBlob returned in the response of the GenerateDataKey operation.

Example of Decryption Flow Using Data Key

  1. Retrieve the Data Key by decrypting the CiphertextBlob that was stored with the encrypted data, specifying the KeyId of a symmetric KMS key, and invoking the Decrypt operation through the AWS CLI, AWS SDK, or other APIs.
  2. Decrypt the encrypted data using the decrypted Data Key, without using the Decrypt API operation.

* With AWS KMS, you can either use API operations like Encrypt and Decrypt, or use a Data Key generated from a KMS key to actually encrypt and decrypt data. However, in cases where encryption operations are performed internally in fully managed AWS services, the expression in the text, such as "Encrypt using a customer-managed key (a KMS key created by the user)", may omit the encryption and decryption flow using a Data Key.

Data Key Pair

A data key pair is a cryptographic key pair generated from an asymmetric KMS key, used for generic data encryption and decryption without using the Encrypt and Decrypt API operations outside of AWS KMS.

A data key pair can be generated from a specified asymmetric KMS key by invoking the GenerateDataKeyPair or GenerateDataKeyPairWithoutPlaintext operations via AWS CLI, AWS SDK, or other APIs. When created, the following parameters are returned:

KeyId: The KeyId of the asymmetric KMS key used to generate the data key pair
KeyPairSpec: The KeySpec of the asymmetric KMS key used to generate the data key pair
PrivateKeyCiphertextBlob: Encrypted secret key that can be used for storage
PrivateKeyPlaintext: Plaintext secret key used for data decryption * Not returned in GenerateDataKeyPairWithoutPlaintext
PublicKey: Plaintext public key used for data encryption

Example usage of a data key pair using the GenerateDataKeyPair or GenerateDataKeyPairWithoutPlaintext operations is as follows:

Preparation of Secret Key and Public Key

  1. Generate a data key pair with the GenerateDataKeyPair or GenerateDataKeyPairWithoutPlaintext operation by specifying the KeyId and KeySpec of an asymmetric KMS key via the AWS CLI, AWS SDK, or other APIs.
  2. Pass the PublicKey from the response returned by GenerateDataKeyPair or GenerateDataKeyPairWithoutPlaintext to the entity (function, node, user, etc.) that encrypts the data.
  3. Store the PrivateKeyCiphertextBlob from the response returned by GenerateDataKeyPair or GenerateDataKeyPairWithoutPlaintext in the entity (function, node, user, etc.) that decrypts the encrypted data.

Example of Encryption Flow using Data Key Pair

  1. Encrypt the target data without using the Encrypt operation, using the public key specified in the PublicKey at the entity (function, node, user, etc.) that encrypts the data.
  2. Pass the encrypted data to the entity (function, node, user, etc.) that decrypts it.

Example of Decryption Flow using Data Key Pair

  1. Receive the encrypted data at the entity (function, node, user, etc.) that decrypts it.
  2. Obtain the secret key by decrypting the PrivateKeyCiphertextBlob at the entity (function, node, user, etc.) that decrypts the encrypted data, using the Decrypt operation by specifying the KeyId of an asymmetric KMS key via the AWS CLI, AWS SDK, or other APIs.
  3. Decrypt the encrypted data without using the Decrypt API operation using the decrypted secret key.

Envelope Encryption

Envelope encryption is a method where plaintext data is encrypted with a data key, and then the data key used for encryption is encrypted with another key.
Specifically, the usage is similar to the "Example of encryption flow using a data key" explained in the previous section, where the Plaintext data key is discarded from memory after use for encryption, and the encrypted data key, CiphertextBlob, which is encrypted with a KMS key, is stored together with the target data for encryption.

The benefits of envelope encryption include the following:

  • Protects the data key itself through encryption and simplifies key management
  • By combining symmetric keys, which allow fast and smaller encrypted data but are difficult to control access for key exchange, with asymmetric keys, which have slower and larger encrypted data but easier access control for key exchange, it enables effective key management that takes advantage of the benefits of both

Hybrid Post-Quantum TLS

Currently, the encryption communication protocol used to connect to the AWS KMS API endpoint, Transport Layer Security (TLS), uses classical key exchange algorithms such as Finite Field Diffie-Hellman Ephemeral (FFDHE) and Elliptic Curve Diffie-Hellman Ephemeral (ECDHE).

There is a potential risk that the encryption of TLS by these traditional algorithms could eventually be deciphered by large-scale quantum computers. Hybrid post-quantum TLS is a measure to avoid this risk.

Hybrid post-quantum TLS is a hybrid cryptographic suite of TLS that combines classical ECDHE with a post-quantum cryptographic key encapsulation mechanism (KEM).

AWS KMS initially supported pre-standard KEM candidates such as Kyber, BIKE, and SIKE through the open source s2n-tls.
Since 2025-04-07, AWS KMS API endpoints support ML-KEM (NIST FIPS 203), the standardized successor of CRYSTALS-Kyber, for hybrid post-quantum TLS key agreement, protecting connections against harvest-now-decrypt-later quantum attacks.
In addition to protecting the communication channel, AWS KMS also supports post-quantum digital signatures with ML-DSA keys (NIST FIPS 204) since 2025-06-13, as described in the KeySpec and KeyUsage section above.

AWS KMS Key Management and Data Key Generation Internals

The internal management of KMS keys and data key generation in AWS KMS mainly consists of the following elements.

  • Domain Key
    A key that is held in HSM's memory for version control and encryption of KMS keys within a region.
    Rotated daily.

  • HSM Backing Key(HBK)
    The actual key of the KMS key created from key material generated in HSM or imported key material, and held in HSM's memory. (KMS key deployed on HSM's memory)
    The HSM Backing Key(HBK) is encrypted with the Domain Key for permanent retention and is saved in the high durability storage within AWS KMS as the Exported Key Token(EKT) described below.
    Rotated annually.

  • Exported Key Token(EKT)
    The encrypted HSM Backing Key(HBK) with the Domain Key deployed on the memory of HSM and stored in the high durability storage within AWS KMS. (KMS key encrypted and stored in high durability storage)
    When using the KMS key, it is decrypted and the HSM Backing Key(HBK) is placed in the memory on HSM.
    When the key material expires, the Exported Key Token(EKT) is deleted.

  • Customer Data Key(CDK)
    A symmetric or asymmetric key that can be used outside AWS KMS that is generated from the HSM Backing Key(HBK) and exported from HSM.
    It corresponds to what is referred to as a "data key" in plaintext.

  • Derived Encryption Key
    A key that is used to encrypt data or Customer Data Key and is held in HSM's memory.
    Derived for each encryption from the HSM Backing Key(HBK).
    Used once per encryption and regenerated at the time of decryption.

  • Ciphertext(CT)
    The encrypted text of the Customer Data Key(CDK) with the Derived Encryption Key.
    It corresponds to the encrypted data key mentioned above.

Overview Diagram of AWS KMS Key Management and Data Key Usage

The following is a summary of the overview diagram regarding the management of KMS keys in AWS KMS and the use of data keys in symmetric KMS keys.
In AWS KMS, the diagram mainly illustrates the concepts of internal KMS key management and data key generation, while in the Client, it illustrates the flow of concepts of encryption and decryption using a data key in a symmetric KMS key.

Overview Diagram of AWS KMS Key Management and Data Key Usage
Overview Diagram of AWS KMS Key Management and Data Key Usage


References:
Tech Blog with curated related content
AWS Documentation(AWS Key Management Service)
AWS Documentation(AWS KMS Cryptographic Details)
Round 2 post-quantum TLS is now supported in AWS KMS
ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager
AWS Key Management Service (AWS KMS)
What's New with AWS?
AWS News Blog

Frequently Asked Questions about AWS KMS History

When did AWS KMS launch?
AWS Key Management Service (AWS KMS) was announced as generally available on November 12, 2014, at AWS re:Invent 2014, with Amazon S3, Amazon EBS, and Amazon Redshift supporting AWS KMS encryption from the start.
When did AWS KMS support importing your own key material (BYOK)?
Importing your own key material into symmetric KMS keys became possible on August 11, 2016. Support was extended to asymmetric (RSA, elliptic curve) and HMAC key material on June 5, 2023, and on-demand rotation of imported key material was added on June 6, 2025.
When did custom key stores and the External Key Store (XKS) launch?
Custom key stores backed by AWS CloudHSM clusters launched on November 26, 2018. The External Key Store (XKS), which lets customers keep key material in an external key manager outside of AWS, launched on November 29, 2022.
How have the key types supported by AWS KMS expanded over time?
AWS KMS started with symmetric encryption keys in 2014. Asymmetric keys and data key pairs (RSA, elliptic curve) were added on November 25, 2019, HMAC KMS keys on April 19, 2022, Elliptic Curve Diffie-Hellman (ECDH) key agreement on June 17, 2024, and post-quantum ML-DSA digital signature keys (NIST FIPS 204) on June 13, 2025.
What happened to the term "Customer Master Key (CMK)"?
On August 30, 2021, AWS replaced the term "Customer Master Key (CMK)" with "AWS KMS key" and "KMS key" across the documentation. There were no functional changes, and legacy identifiers such as the CustomerMasterKeySpec field remain for backward compatibility.
How has AWS KMS key rotation evolved?
Automatic rotation of AWS KMS generated key material was originally a fixed yearly schedule. On April 12, 2024, AWS KMS introduced customizable rotation periods (90 to 2,560 days) and on-demand rotation for customer managed keys, and on June 6, 2025, on-demand rotation was extended to symmetric keys with imported key material.
When did multi-Region keys launch?
AWS KMS multi-Region keys launched on June 16, 2021. They allow a KMS key to be replicated into other AWS Regions with the same key material and key ID, so that data encrypted in one Region can be decrypted in another.
What is the FIPS validation status of the AWS KMS HSMs?
The hardware security modules used by AWS KMS were certified at FIPS 140-2 overall Security Level 2 from 2017, upgraded to FIPS 140-2 Security Level 3 on May 24, 2023, and are currently validated at FIPS 140-3 Security Level 3 according to the AWS KMS Developer Guide.
All dates above follow the primary AWS sources referenced in this article (AWS What's New, AWS News Blog, AWS Security Blog, and the AWS KMS Developer Guide document history). This article is reviewed regularly to incorporate new AWS KMS launches.

Summary

This time, I have created a timeline of AWS KMS and looked at the feature list and overview of AWS KMS.

AWS KMS enables encryption and decryption of data with KMS keys integrated across AWS services now and in the future, while also providing secure encryption and decryption operations with data key generation and envelope encryption outside AWS KMS.
In particular, in recent years, the number of KeySpec and KeyUsage that can be handled by KMS keys has been increasing, including HMAC generation and verification with HMAC KMS keys, encryption/decryption/signature and verification with asymmetric KMS keys (RSA), signature and verification with asymmetric KMS keys (ECC), shared secret derivation with ECDH key agreement, and post-quantum digital signatures with ML-DSA KMS keys, expanding its applications.
In addition, there have been updates such as multi-region keys, the External Key Store (XKS), flexible and on-demand key rotation, ML-KEM based hybrid post-quantum TLS, and access control through key policies, enabling more flexible usage while maintaining security.

I would like to continue watching the trends of what kind of features AWS KMS will continue to provide in the future.

In addition, there is also a timeline of the entire AWS services including AWS KMS, so please have a look if you are interested.

AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)
I have also written related historical timelines for the services that AWS KMS works most closely with:
This timeline will be updated as AWS KMS continues to evolve.

Written by Hidekazu Konishi