Try AWS Key Management Service

Get Started with AWS
Or Sign In to the Console

Create your free account with Amazon Web Services and receive 12 months of access to free products and services.

View AWS Free Tier Details »

AWS KMS is a managed encryption service that enables you to easily encrypt your data. AWS KMS provides a highly available key storage, management, and auditing solution for you to encrypt your data across AWS services and within your own applications.

If you are a developer who needs to encrypt data in your applications, you should use the AWS SDKs with AWS KMS support to easily use and protect encryption keys. If you’re an IT administrator looking for a scalable key management infrastructure to support your developers and their growing number of applications, you should use AWS KMS to reduce your licensing costs and operational burden. If you’re responsible for proving data security for regulatory or compliance purposes, you should use AWS KMS to verify that data is encrypted consistently across the applications where it is used and stored.

The easiest way is to get started using AWS KMS is to check the box to encrypt your data within supported AWS services and use the default keys that are created in your account for each service. If you want further controls over the management of these keys, you can create keys in AWS KMS and assign them to be used in the supported AWS services when creating encrypted resources as well as use them directly within your own applications. AWS KMS can be accessed from the “Encryption Keys” section of the AWS Identity and Access Management (IAM) console for web-based access, and the AWS KMS Command Line Interface or AWS Software Development Kit for programmatic access. Visit the Getting Started page to learn more.

Availability is listed on our global Products and Services by Region page.

You can perform the following key management functions in AWS KMS:

  • Create keys with a unique alias and description
  • Import your own keys
  • Define which IAM users and roles can manage keys
  • Define which IAM users and roles can use keys to encrypt and decrypt data
  • Choose to have AWS KMS automatically rotate your keys on an annual basis
  • Temporarily disable keys so they cannot be used by anyone
  • Re-enable disabled keys
  • Delete keys that you no longer use
  • Audit use of keys by inspecting logs in AWS CloudTrail

AWS KMS allows you to centrally manage and securely store your keys. You can generate keys in AWS KMS or import them from your key management infrastructure. These keys can be used from within your applications and supported AWS services to protect your data, but the key never leaves AWS KMS. You submit data to AWS KMS to be encrypted, or decrypted, under keys that you control. You set usage policies on these keys that determine which users can use them to encrypt and decrypt data. All requests to use these keys are logged in AWS CloudTrail so you can understand who used which key when.

You can use AWS KMS to help encrypt data locally in your own applications or have it encrypted within a supported AWS service. You can use an AWS SDK with AWS KMS support to do the encryption wherever your applications run. You can also request a supported AWS service to encrypt your data as it is being stored. AWS CloudTrail provides access logs to allow you to audit how your keys were used in either situation.

AWS KMS is seamlessly integrated with several other AWS services to make encrypting data in those services as easy as checking a box and selecting the master key you want to use. See the Product Details page for the list of AWS services currently integrated with AWS KMS. All use of your keys within integrated services appears in AWS CloudTrail logs. See the AWS KMS Developer’s Guide for more information on how integrated services use AWS KMS.

AWS cloud services integrated with AWS KMS use a method called envelope encryption to protect your data. Envelope encryption is an optimized method for encrypting data that uses two different keys. A data key is generated and used by the AWS service to encrypt each piece of data or resource. The data key is encrypted under a master key that you define in AWS KMS. The encrypted data key is then stored by the AWS service. When you need your data decrypted by the AWS service, the encrypted data key is passed to AWS KMS and decrypted under the master key that was originally encrypted under so the service can then decrypt your data.

While AWS KMS does support sending data less than 4 KB to be encrypted, envelope encryption can offer significant performance benefits. When you encrypt data directly with AWS KMS it must be transferred over the network. Envelope encryption reduces the network load for your application or AWS cloud service. Only the request and fulfillment of the data key through AWS KMS must go over the network. Since the data key is always stored in encrypted form, it is easy and safe to distribute that key where you need it to go without worrying about it being exposed. Encrypted data keys are sent to AWS KMS and decrypted under master keys to ultimately allow you to decrypt your data. The data key is available directly in your application without having to send the entire block of data to AWS KMS and suffer network latency.

You have the option of selecting a specific master key to use when you want an AWS service to encrypt data on your behalf. A default master key specific to each service is created in your account as a convenience the first time you try to create an encrypted resource. This key is managed by AWS KMS but you can always audit its use in AWS CloudTrail. You can alternately create a customer master key in AWS KMS that you can then use in your own applications or from within a supported AWS service. AWS will update the policies on default master keys as needed to enable new features in supported services automatically. AWS does not modify policies on keys you create.

Creating a key in AWS KMS gives you more control than you have with default service master keys. When you create a customer master key, you can choose to use key material generated by AWS KMS on your behalf or import your own key material, define an alias, a description, and opt-in to have the key automatically rotated once per year if it backed by key material generated by AWS KMS. You also can define permissions on the key to control who can use and manage the key. Management and usage activity related to the key is available for audit in AWS CloudTrail.

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 delete the imported copy of the key on demand from AWS infrastructure once you no longer need the key.

You can import 256-bit symmetric keys.

During the import, your key must be wrapped by a AWS KMS-provided public key using one of the two RSA PKCS#1 schemes. This ensures that your encrypted key can only be decrypted by AWS KMS.

There are two main differences between a key that you import vs. a key created for you by AWS KMS:
  1. You must securely maintain a copy of your imported keys in your key management infrastructure so that you can re-import them at any time. AWS ensures 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 to automatically delete the key from AWS KMS after the expiration period. You may also delete an imported key on demand without deleting the underlying customer master key. Further, you can manually disable or delete a customer master key with an imported key at any time. A key generated by AWS KMS can only be disabled or scheduled for deletion, it cannot have an expiration time placed on it.

Yes. You can choose to have AWS KMS automatically rotate keys generated by AWS KMS on your behalf every year. Automatic key rotation is not supported for imported keys. If you choose to import keys to AWS KMS, you can manually rotate them whenever you want.

If you choose to have AWS KMS automatically rotate keys generated by AWS KMS on your behalf, you don’t have to re-encrypt your data. AWS KMS keeps previous versions of keys to use for decryption of data encrypted under an old version of a key. All new encryption requests against a key in AWS KMS are encrypted under the newest version of the key.

If you manually rotate your keys, you may have to re-encrypt your data depending on your application’s configuration.  

Yes. You can schedule a customer master key and associated metadata that you created in AWS KMS for deletion, with a configurable waiting period from 7 to 30 days. This waiting period allows you to verify the impact of deleting a key on your applications and users that depend on it. The default waiting period is 30 days. You can cancel the deletion during the waiting period. The key cannot be used if it is scheduled for deletion until you cancel the deletion during the waiting period. The key gets deleted at the end of the configurable waiting period if you don’t cancel the deletion. Once a key gets deleted, you can no longer use it. All data protected under a deleted master key is inaccessible.

For customer master keys with imported key material, you can delete the key material without deleting the customer master key id or metadata in two ways. First, you can delete your imported key material on demand without a waiting period. Second, at the time of importing the key material into the customer master key, you may define an expiration time for how long AWS can use your imported key material before it is deleted. You can re-import your key material into the customer master key if you need to use it again.

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

Yes. Once you import your key to a customer master key, you will receive an Amazon CloudWatch Metric every few minutes that counts down the time to expiration of the imported key. You will also receive an Amazon CloudWatch Event once the imported key under your customer master 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. 

Yes. AWS KMS is supported in AWS SDKs, AWS Encryption SDK, and the Amazon S3 Encryption Client to facilitate encryption of data within your own applications wherever they run. AWS SDK in the Java, Ruby, .NET, and PHP platforms support AWS KMS APIs. Visit the Developing on AWS website for more information.

You can create up to 1000 customer master keys per account per region. As both enabled and disabled customer master keys count towards the limit, we recommend deleting disabled keys that you no longer use. Default master keys created on your behalf for use within supported AWS services do not count against this limit. There is no limit to the number of data keys that can be derived using a master key and used in your application or by AWS services to encrypt data on your behalf. You may request a limit increase for customer master keys by visiting the AWS Support Center.

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 customer master 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 Usage Tier you can get started with AWS KMS for free in all regions. Default master keys created on your behalf are free to store in your account. There is a free tier for usage as well that provides a free number of requests to AWS KMS each month. For current information on pricing, including the free tier, please visit the AWS KMS pricing page.

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.

AWS KMS enforces usage and management policies that you define. You choose to allow AWS Identity and Access Management (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 keys from the service. The service uses FIPS 140-2 validated hardware security modules (HSMs) to protect the confidentiality and integrity of your keys regardless of whether you request AWS KMS to create keys on your behalf or you import them into the service. 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. AWS KMS keys are never transmitted outside of the AWS regions in which they were created. 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.

More details about these security controls can be found in the AWS KMS Cryptographic Details whitepaper. You can also review the FIPS 140-2 certificate for AWS KMS HSM along with the associated Security Policy to get more details about how AWS KMS HSM meets the security requirements of FIPS 140-2. In addition, you can download a copy of the Service Organization Controls (SOC) report from AWS Artifact to learn more about security controls used by AWS KMS to protect your master keys.

All master keys in AWS KMS regardless of their creation date or origin are automatically protected using FIPS 140-2 validated HSMs. No action is required on your end to use the FIPS 140-2 validated HSMs.

FIPS 140-2 validated HSMs are available in all AWS regions where AWS KMS is offered.

Details about this validation can be found in the FIPS 140-2 certificate for AWS KMS HSM along with the associated Security Policy.

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.

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 at 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.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 that can be returned for use in your own application. The data keys are encrypted under a master 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 only be decrypted by users with permissions to use the original master key used in encrypting the data key.

Master keys in AWS KMS are 256-bits in length. Data keys can be generated at 128-bit or 256-bit lengths and encrypted under a master key you define. AWS KMS also provides the ability to generate random data of any length you define suitable for cryptographic use.

No. Master keys are created and used only within AWS KMS to help ensure their security, enable your policies to be consistently enforced, and provide a centralized log of their use.

Keys are only stored and used in the region in which they are created. They cannot be transferred to another region. For example; keys created in the EU-Central (Frankfurt) region are only stored and used within the EU-Central (Frankfurt) region.

Logs in AWS CloudTrail will show requests on your master keys, including both management requests (e.g. create, rotate, disable, policy edits) and cryptographic requests (e.g. encrypt/decrypt). Turn on AWS CloudTrail in your account to view these logs.

AWS CloudHSM provides you with a FIPS 140-2 Level 3 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 via an authentication mechanism independent from AWS. You interact with keys in your AWS CloudHSM cluster similar to the way you interact with your applications running in Amazon EC2. You can use AWS 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 allows 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 140-2 validated HSM to protect the security of your keys. Centralized management of all your keys in AWS KMS lets you enforce who can use your keys under which conditions, when they get rotated, and who can manage them. AWS KMS integration with AWS 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, or the AWS Encryption SDK if you want to perform client-side encryption.