AWS Key Management Service FAQs

AWS KMS enforces usage and management policies that you define. You can choose to allow IAM users and roles from your account or other accounts to use and manage your keys.

AWS KMS is designed so that no one, including AWS employees, can retrieve your plaintext KMS keys from the service. AWS KMS 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 KMS keys never leave the HSMs, are never written to disk, and are only ever used in the volatile memory of the HSMs for the time needed to perform your requested cryptographic operation. Updates to software on the service hosts and to the AWS KMS HSM firmware is controlled by multi-party access control that is audited and reviewed by an independent group within Amazon and a NIST-certified lab in compliance with FIPS 140-2.

More details about these security controls can be found in the AWS KMS cryptographic details tech paper. You can also review the FIPS 140-2 certificate for AWS KMS HSMs along with the associated Security Policy to get more details about how AWS KMS HSMs meets the security requirements of FIPS 140-2. Also, you can download a copy of the System and Organization Controls (SOC) report from AWS Artifact to learn more about security controls used by the service to protect your KMS keys.

You do not need to do anything. All AWS KMS keys, regardless of their creation date or origin are automatically protected using HSMs that have been validated under FIPS 140-2 Security Level 3.

FIPS 140-2 Security Level 3 validated HSMs are deployed in all AWS Regions where AWS KMS is offered.
NOTE: By regulation, AWS KMS in China Regions cannot use NIST FIPS HSMs and uses China's Office of the State Commercial Cryptographic Administration (OSCCA) certified HSMs instead.

AWS KMS is a two-tier service. The API endpoints receive client requests over an HTTPS connection using only TLS ciphersuites that support perfect forward secrecy. These API endpoints authenticate and authorize the request before passing the request for a cryptographic operation to the AWS KMS HSMs or your AWS CloudHSM cluster if you’re using the KMS custom key store feature.

You configure your applications to connect to the unique regional FIPS 140-2 validated HTTPS endpoints. AWS KMS FIPS 140-2 validated HTTPS endpoints are powered by the OpenSSL FIPS Object Module. You can review the security policy of the OpenSSL module here. FIPS 140-2 validated API endpoints are available in all commercial Regions where AWS KMS is available.

Yes. AWS KMS has been validated as having the functionality and security controls to help you meet the encryption and key management requirements (primarily referenced in sections 3.5 and 3.6) of the PCI DSS 3.2.1.

For more details on PCI DSS compliant services in AWS, you can read the PCI DSS FAQs.

You can request that AWS KMS generate data keys and return them for use in your own application. The data keys are encrypted under a root key you define in AWS KMS so that you can safely store the encrypted data key along with your encrypted data. Your encrypted data key (and therefore your source data) can be decrypted by only users with permissions to use the original root key to decrypt your encrypted data key.

No. AWS KMS keys are created and used only within the service to help verify their security, implement your policies to be consistently enforced, and provide a centralized log of their use.

A single-Region KMS key generated by AWS KMS is stored and used only in the Region in which it was created. With AWS KMS multi-Region keys you can choose to replicate a multi-Region primary key into multiple Regions within the same AWS partition.

Logs in AWS CloudTrail will show all AWS KMS API requests, including both management requests (such as create, rotate, disable, policy edits) and cryptographic requests (such as encrypt/decrypt). Turn on CloudTrail in your account to view these logs.

CloudHSM provides you with a validated single-tenant HSM cluster in your Amazon Virtual Private Cloud (VPC) to store and use your keys. You have exclusive control over how your keys are used through an authentication mechanism independent from AWS. You interact with keys in your CloudHSM cluster similar to the way you interact with your applications running in Amazon EC2. You can use CloudHSM to support a variety of use cases, such as Digital Rights Management (DRM), Public Key Infrastructure (PKI), document signing, and cryptographic functions using PKCS#11, Java JCE, or Microsoft CNG interfaces.
 

AWS KMS helps you to create and control the encryption keys used by your applications and supported AWS services in multiple Regions around the world from a single console. The service uses a FIPS HSM that has been validated under FIPS 140-2, or are in the process of being validated, to protect the security of your keys. Centralized management of all your keys in AWS KMS helps you enforce who can use your keys under which conditions, when they get rotated, and who can manage them. AWS KMS integration with CloudTrail gives you the ability to audit the use of your keys to support your regulatory and compliance activities. You interact with AWS KMS from your applications using the AWS SDK if you want to call the service APIs directly, through other AWS services that are integrated with AWS KMS or by using the AWS Encryption SDK if you want to perform client-side encryption.

With AWS KMS, you pay only for what you use; there is no minimum fee. There are no set-up fees or commitments to begin using the service. At the end of the month, your credit card will automatically be charged for that month’s usage.

You are charged for all KMS keys you create and for API requests made to the service each month above a free tier.
 

For current pricing information, please visit the AWS KMS pricing page.

Yes. With the AWS Free Tier you can get started with AWS KMS for free* in all Regions. AWS managed AWS KMS keys that are created on your behalf by AWS services are free to store in your account. There is a free tier for usage that provides a free number of requests to the service each month. For current information on pricing, including the Free Tier, please visit the AWS KMS pricing page.

*API requests involving asymmetric KMS keys and API requests to the GenerateDataKeyPair and GenerateDataKeyPairWithoutPlaintext APIs are excluded from the Free Tier.

Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT and applicable sales tax. For customers with a Japanese billing address, use of AWS services is subject to Japanese Consumption Tax. You can learn more here.

Yes. You can import a copy of your key from your own key management infrastructure to AWS KMS and use it with any integrated AWS service or from within your own applications.

You can use an imported key to get greater control over the creation, lifecycle management, and durability of your key in AWS KMS. Imported keys are designed to help you meet your compliance requirements which may include the ability to generate or maintain a secure copy of the key in your infrastructure, and the ability to immediately delete the imported copy of the key from AWS infrastructure.

You can import symmetric keys, asymmetric keys (RSA and elliptic curve), and HMAC keys.

During the import process, your key must be wrapped by an AWS KMS-provided public key using the supported wrapping algorithm. This verifies that your encrypted key can be decrypted by only AWS KMS.

There are two main differences:
 

1. You are responsible for maintaining a copy of your imported keys in your key management infrastructure so that you can re-import them at any time. AWS, however, verifies the availability, security, and durability of keys generated by AWS KMS on your behalf until you schedule the keys for deletion.
2. You may set an expiration period for an imported key. AWS KMS will automatically delete the key material after the expiration period. You can also delete imported key material on demand. In both cases the key material itself is deleted but the KMS key reference in AWS KMS and associated metadata are retained so that the key material can be re-imported in the future. Keys generated by AWS KMS do not have an expiration time and cannot be deleted immediately; there is a mandatory 7 to 30 day wait period. All customer managed KMS keys, regardless of whether the key material was imported, can be manually disabled or scheduled for deletion. In this case the KMS key itself is deleted, not just the underlying key material.

You can re-import your copy of the key material with a valid expiration period to AWS KMS under the original AWS KMS key so it can be used.

Yes. Once you import your key to an AWS KMS key, you will receive a CloudWatch Metric every few minutes that counts down the time to expiration of the imported key. You will also receive a CloudWatch Event once the imported key under your AWS KMS key expires. You can build logic that acts on these metrics or events and automatically re-imports the key with a new expiration period to avoid an availability risk.

AWS KMS supports 256-bit keys when creating a KMS key for encryption and decryption. Generated data keys returned to the caller can be 256-bit, 128-bit, or an arbitrary value up to 1024-bytes. When AWS KMS uses a 256-bit KMS key on your behalf to encrypt or decrypt, the AES algorithm in Galois Counter Mode (AES-GCM) is used.

AWS KMS supports the following asymmetric key types: RSA 2048, RSA 3072, RSA 4096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521, and ECC SECG P-256k1. AWS KMS supports the RSAES_OAEP_SHA_1 and RSAES_OAEP_SHA_256 encryption algorithms with RSA 2048, RSA 3072, and RSA 4096 key types. Encryption algorithms cannot be used with the elliptic curve key types (ECC NIST P-256, ECC NIST P-384, ECC NIST-521, and ECC SECG P-256k1).

When using elliptic curve key types, AWS KMS supports the ECDH key agreement algorithms.

When using RSA key types, AWS KMS supports the RSASSA_PSS_SHA_256, RSASSA_PSS_SHA_384, RSASSA_PSS_SHA_512, RSASSA_PKCS1_V1_5_SHA_256, RSASSA_PKCS1_V1_5_SHA_384, and RSASSA_PKCS1_V1_5_SHA_512 signing algorithms. When using elliptic curve key types, AWS KMS supports the ECDSA_SHA_256, ECDSA_SHA_384, and ECDSA_SHA_512 signing algorithms.

The public portion of the asymmetric key material is generated in AWS KMS and can be used for digital signature verification by calling the “Verify” API, or for public key encryption by calling the “Encrypt” API. The public key can also be used outside of AWS KMS for verification or encryption. You can call the GetPublicKey API to retrieve the public portion of the asymmetric KMS key.

The size limit is 4 KB. If you want to digitally sign data larger than 4 KB, you have the option to create a message digest of the data and send it to AWS KMS. The digital signature is created over the digest of the data and returned. You specify whether you are sending the full message or a message digest as a parameter in the Sign API request. Any data submitted to the Encrypt, Decrypt, or Re-Encrypt APIs that require use of asymmetric operations must also be less than 4 KB.

In the console, each key will have a new field called Key Type. It will have the value Asymmetric Key or Symmetric Key to indicate the type of key. The DescribeKey API will return a KeyUsage field that will specify if the key can be used to sign, generate HMACs, or encrypt.

No. Automatic key rotation is not supported for asymmetric or HMAC KMS keys. In general, rotation of asymmetric or HMAC keys can be highly disruptive to your existing workload because you need to retire and replace all instances of keys in which you shared with other parties in the past. If necessary, you can manually rotate them by creating a new KMS key and mapping an existing key alias from the old KMS key to the new KMS key.

No. When creating a KMS key, you must specify whether the key can be used for decrypt or sign operations. An RSA key type can be used for signing or encryption operations, but not both. Elliptic curve key types can be used for only signing operations.

Yes. The request per second rate limits are different for different key types and algorithms. Refer to the AWS KMS limits page for details.

No. You cannot use the custom key store functionality with asymmetric keys.

Not directly. AWS KMS doesn’t store or associate digital certificates with asymmetric KMS keys it creates. You could choose to have a certificate authority such as AWS Private Certificate Authority issue a certificate for the public portion of your asymmetric KMS key. This will allow the entities that are consuming your public key to verify that the public key indeed belongs to you.

The AWS KMS custom key store feature combines the controls provided by CloudHSM with the integration and ease of use of AWS KMS. You can configure your own CloudHSM cluster and authorize AWS KMS to use it as a dedicated key store for your keys rather than the default AWS KMS key store. When you create keys in AWS KMS you can chose to generate the key material in your CloudHSM cluster. KMS keys that are generated in your custom key store never leave the HSMs in the CloudHSM cluster in plaintext and all AWS KMS operations that use those keys are performed in only your HSMs. In all other respects KMS keys stored in your custom key store are consistent with other AWS KMS keys.

Additional guidance for deciding if using a custom key store it is right for you can be found in this blog.

Since you control your CloudHSM cluster, you have the option to manage the lifecycle of your KMS keys independently of AWS KMS. There are three reasons why you might find a custom key store useful. First, you might have keys that are explicitly required to be protected in a single tenant HSM or in an HSM over which you have direct control. Second, you might need the ability to immediately remove key material from AWS KMS and to prove you have done so by independent means. Third, you might have a requirement to be able to audit all use of your keys independently of AWS KMS or CloudTrail.

There are two differences when managing keys in a custom key store backed by CloudHSM compared to the default AWS KMS key store. You cannot import key material into your custom key store and you cannot have AWS KMS automatically rotate keys. In all other respects, including the type of keys that can be generated, the way that keys use aliases and how policies are defined, keys that are stored in a custom key store are managed in the same way as any other AWS KMS customer managed KMS key.

No, only customer managed KMS keys can be stored and managed in an AWS KMS custom key store backed by CloudHSM. AWS managed KMS keys that are created on your behalf by other AWS services to encrypt your data are always generated and stored in the AWS KMS default key store.

No, API requests to AWS KMS to use a KMS key to encrypt and decrypt data are handled in the same way. Authentication and authorization processes operate independently of where the key is stored. All activity using a key in a custom key store backed by CloudHSM is also logged to CloudTrail in the same way. However, the actual cryptographic operations happen exclusively in either the custom key store or the default AWS KMS key store.

In addition to the activity that is logged to CloudTrail by AWS KMS, the use of a custom key store provides three further auditing mechanisms. First, CloudHSM also logs all API activity to CloudTrail, such as creating clusters and adding or removing HSMs. Second, each cluster also captures its own local logs to record user and key management activity. Third, each CloudHSM instance copies the local user and key management activity logs to AWS CloudWatch.

The use of an AWS KMS custom key store helps you be responsible for verifying that your keys are available for use by AWS KMS. Errors in configuration of CloudHSM and accidental deletion of key material within a CloudHSM cluster could impact availability. The number of HSMs you use and your choice of Availability Zones (AZs) can also affect the resilience of your cluster. As in any key management system, it is important to understand how the availability of keys can impact the recovery of your encrypted data.

The rate at which keys stored in an AWS KMS custom key store backed by CloudHSM can be used through AWS KMS API calls are lower than for keys stored in the default AWS KMS key store. See the AWS KMS Developer Guide for the current performance limits.

AWS KMS prices are unaffected by the use of a custom key store. However, each custom key store does require that your AWS CloudHSM cluster contains at least two HSMs. These HSMs are charged at the standard AWS CloudHSM prices. There are no additional charges for using a custom key store.

AWS KMS users that want to use a custom key store will need to set up an AWS CloudHSM cluster, add HSMs, manage HSMs users and potentially restore HSMs from backup. These are security sensitive tasks and you can verify that you have the appropriate resources and organizational controls in place.

No, the ability to import your own key material into an AWS KMS custom key store is not supported. Keys that are stored in a custom key store can only be generated in the HSMs that form your CloudHSM cluster.

No, the ability to migrate keys between the different types of AWS KMS key store is not currently supported. All keys must be created in the key store in which they will be used, except in situations where you import you own key material into the default AWS KMS key store.

The ability to automatically rotate key material in an AWS KMS custom key store is not supported. Key rotation must be performed manually by creating new keys and re-mapping AWS KMS key aliases used by your application code to use the new keys for future encryption operations.

Yes, AWS KMS does not require exclusive access to your CloudHSM cluster. If you already have a cluster you can use it as a custom key store and continue to use it for your other applications. However, if your cluster is supporting high, non-AWS KMS, workloads you may experience reduced throughput for operations using KMS keys in your custom key store. Similarly, a high AWS KMS request rate to your custom key store could impact your other applications.

Visit the AWS CloudHSM website for an overview of the service and for more details on configuring and using the service read the AWS CloudHSM User Guide.

An external key store is a custom key store backed by an external key management infrastructure that you own and manage outside of AWS. All encryption or decryption operations that use a KMS key in an external key store are performed in your key manager with cryptographic keys and operations that are under your control and are physically inaccessible to AWS.

XKS can help you comply with rules or regulations that require encryption keys to be stored and used outside of AWS under your control.

Requests to AWS KMS from integrated AWS services on your behalf or from your own applications are forwarded to a component in your network called an XKS Proxy. The XKS Proxy is an open source API specification that helps you and your key management vendor build a service that accepts these requests and forwards them to your key management infrastructure to use its keys for encryption and decryption.

Thales, Entrust, Atos, Fortanix, DuoKey, Securonix, Utimaco, Salesforce, T-Systems, and HashiCorp have solutions that integrate with the XKS Proxy specification. For information about availability, pricing, and how to use solutions from these vendors, see their respective documentation. We encourage you and your key management infrastructure partner to leverage the open source XKS Proxy specification to build a solution that meets your needs. The API specification for XKS Proxy is published here.

External keys support the following symmetric encryption operations: Encrypt, ReEncrypt, Decrypt, and GenerateDataKey.

You can use XKS keys to encrypt data in any AWS service that integrates with AWS KMS using customer managed keys. See the list of supported services here. AWS services call the AWS KMS GenerateDataKey API to request a unique plaintext data key to encrypt your data. The plaintext data key is returned to the service along with an encrypted copy of the data key to be stored alongside your encrypted data. To produce the encrypted copy of the data key, the plaintext data key is first encrypted by a key stored in AWS KMS unique to your AWS account. This encrypted data key is then forwarded to your XKS Proxy implementation connected to your external key manager to be encrypted a second time under the key you define in your external key manager. The resulting double-encrypted data key is returned in the response to the GenerateDataKey API request.

The network connection between AWS KMS, your XKS Proxy implementation, and your external key manager should be protected with a point-to-point encryption protocol like TLS. However, in order to protect your data leaving AWS KMS until it reaches your external key manager, AWS KMS first encrypts it with an internally managed KMS key in your account specific to each KMS key defined in your external key store. The resulting ciphertext is forwarded to your external key manager, which encrypts it using the key in your external key manager. Double encryption provides the security control that no ciphertext can ever be decrypted without using the key material in your external key manager. It also provides the security control that the ciphertext leaving the AWS network is encrypted using the FIPS 140 certified AWS KMS HSMs. Because your external key manager must be used to decrypt data, if you revoke access to AWS KMS, your underlying encrypted data becomes is inaccessible.

Yes. XKS keys can also be used from within your own applications when using a client-side symmetric encryption solution that uses AWS KMS as its key provider. AWS open source client-side encryption solutions like the AWS Encryption SDK, S3 Encryption Client and DynamoDB Encryption Client support XKS keys.

All XKS keys must be created as new keys in KMS. You cannot migrate existing KMS keys into XKS keys hosted in your external key manager.

You can re-encrypt existing data under newly generated XKS keys, assuming the AWS service or your own application supports the action. Many AWS services will help you copy an encrypted resource and designate a new KMS key to use to encrypt the copy. You can configure the XKS key in the COPY command provided by the AWS service. You can re-encrypt client-side encrypted data in your own applications by calling the KMS ReEncrypt API and configuring the XKS key.

Like all customer managed keys, XKS keys are priced at $1 per month per key until they are deleted. Requests under XKS keys are charged at the same rate as any other AWS KMS symmetric key. Learn more about pricing on the AWS KMS pricing page.

Yes. Automatic key rotation is supported by the XKS specification, and it is a capability provided by most vendors that support XKS. Automatic rotation for XKS keys occurs entirely in the external key manager and works in a similar way to the automatic key rotation for AWS KMS keys created and managed within KMS. When you use a rotated KMS XKS key to encrypt data, your external key manager uses the current key material. When you use the rotated XKS key to decrypt ciphertext, your external key manager uses the version of the key material that was used to encrypt it. As long as previous XKS keys used to create earlier ciphertexts are still enabled in external key manager, you will be able to successfully make Decrypt API request under those versions of you XKS keys.

For services that do not cache keys, the next API call using this XKS KMS key will fail. Some services implement data key caching or other key derivation schemes for performance, latency, or KMS cost management. Caching of these keys can vary from 5 mins to 24 hrs. Any protected resource that is currently in use (such as RDS database or EC2 instance) will respond differently after you deny access to the key. See the relevant AWS service documentation for details.

To authenticate to your external key store proxy, AWS KMS signs all requests to the proxy using AWS SigV4 credentials that you configure on your proxy and provide to KMS. AWS KMS authenticates your external key store proxy using server-side TLS certificates. Optionally, your proxy can enable mutual TLS for additional assurance that it only accepts requests from AWS KMS.

All of the usual AWS KMS authorization mechanisms — IAM policies, AWS KMS key policies, grants — that you use with other KMS keys, work the same way for KMS keys in external key stores.

In addition, your and/or your external key manager partners have the ability to implement a secondary layer of authorization controls based on request metadata included with each request sent from AWS KMS to the XKS Proxy. This metadata includes the calling AWS user/role, the KMS key ARN, and the specific KMS API that was requested. This allows you to apply fine-grained authorization policy on the use of a key in your external key manager beyond simply trusting any request from AWS KMS. The choice of policy enforcement using these request attributes are left to your individual XKS Proxy implementations.

The unique ID generated for every request coming to AWS KMS involving XKS keys is also forwarded to the XKS proxy. You can use the log data (if available) from your XKS proxy or external key manager to reconcile requests made to AWS KMS with the ones made to your external key manager. This feature allows you to verify that all requests to use keys in your external key manager originated from a call you initiated to AWS KMS either directly or through an integrated AWS service.

Availability risk: You are responsible for the availability of the XKS Proxy and external key material. This system must have high availability to verify that whenever you need an XKS key to decrypt an encrypted resource or encrypt new data, AWS KMS can successfully connect to the XKS proxy, which itself can connect to your external key manager to complete the necessary cryptographic operation using the key. For example, suppose you encrypted an EBS volume using an XKS key and now you want to launch an EC2 instance and attach that encrypted volume. The EC2 service will pass the unique encrypted data key for that volume to AWS KMS to decrypt it so it can be provisioned in volatile memory of the Nitro card in order to decrypt and encrypt read/write operations to the volume. If your XKS Proxy or external key manager isn’t available to decrypt the volume key, your EC2 instance will fail to launch. In these types of failures, AWS KMS returns a KMSInvalidStateException stating that the XKS Proxy is not available. It is now up to you to determine why your XKS Proxy and key manager is unavailable based on the error messages provided by KMS.

Durability risk: Because keys are under your control in systems outside of AWS, you are solely responsible for the durability of all external keys you create. If the external key for a XKS key is permanently lost or deleted, all ciphertext encrypted under the XKS key is unrecoverable.

Performance risk: You are responsible for verifying that your XKS Proxy and external key store infrastructure is designed with sufficient performance characteristics to meet your needs. Since every request using XKS keys requires a connection to your external key store, your XKS proxy can become a bottleneck if the request rate from AWS KMS exceeds the request rate your XKS Proxy or external key manager can support. Also, if the elapsed time of a single request (including one retry) from AWS KMS to your XKS Proxy takes more than 500ms*, AWS KMS will return a 400 error to its calling client, effectively communicating that your XKS key is unavailable and the calling client should not retry. This behavior is designed to minimize the risk of upstream AWS services or your own applications having to react to sporadic excessive latency caused by connectivity issues to your infrastructure.

*AWS KMS will attempt a single retry for any request that takes 250ms. If the retry request also takes more than 250ms, a 400 error will be returned to the calling client.

Because AWS cannot control the end-to-end availability of the connection between AWS KMS and your external key store infrastructure, we specifically exclude the use of XKS in our public KMS availability SLA. Also, XKS keys are excluded in the availability SLA for any AWS service in which an XKS key is configured by you to encrypt data within the service.