Alright, this one is going to take a series but listen up because it’s super important!

There’s a lot to talk about when it comes to AWS KMS, or Key Management Service, so this is going to be the first in a series of cheat sheets dedicated to KMS and data encryption in the AWS cloud. (Here’s the second in the series)

Why you need to learn KMS

KMS is not only really important to understand when you’re building on AWS, but it’s also very important to understand for the AWS Certified Security Specialty exam.

For example, while some services automatically encrypt your data at rest using KMS, it’s important to understand what that actually means from a security perspective.

You also need to understand how to control access to KMS keys, and how to troubleshoot issues in AWS environments related to key access since it adds complexity and multiple layers of defense.

On top of that, there are some serious cost considerations when using KMS.

But I’m getting ahead of myself. First, we need to talk about what KMS is in the first place…

What is KMS?

KMS is AWS’ native & managed service that lets you:

  • Create,
  • Manage, and
  • Control…

…cryptographic keys for your applications (in or outside of AWS) and AWS services to encrypt/decrypt and protect your data.

With KMS, you can more easily add encryption and digital signature functionality to your app code either directly via the API or using the AWS SDK.

You can use it to:

  • Encrypt, decrypt, and re-encrypt data
  • Sign and verify messages with asymmetric KMS keys
  • Generate & export symmetric data keys & asymmetric data key pairs
  • Generate & verify HMAC codes
  • Generate random numbers for cryptographic applications

It also natively integrates with many AWS services (EC2, S3, EBS, CodePipeline, and much more), which means you can use it to encrypt data, and to control who/what can decrypt that data.

As an example, Amazon S3 automatically (and by default) encrypts your data at rest by using AWS KMS under the hood, but you may want to change this default setting to use a different type of key instead. Much more on this in a future cheat sheet.

That’s it for now, as the rest is in the cheat sheet. I’ll also be partnering with AWS data & permissions security experts to produce the next few, because a) this is a topic that I’m still very much learning (cryptography has never been my strong suit), and b) this is a topic where technical accuracy is critical so I want to make sure I get a second or third pair of eyes before I release it to you.

If this is helpful, or if you or someone you know needs to learn more about AWS KMS, please consider sharing with them and feel free to download this cheat sheet!

AWS Key Management Service (KMS)

Getting Started Cheat Sheet

AWS KMS

What is Key Management Service (KMS)?

KMS lets you create, manage, and control cryptographic keys for your applications and AWS services to encrypt/decrypt and protect your data.

Under the hood, it uses hardware security modules (HSM) to protect KMS keys. These HSMs are validated under the FIPS 140-3 Cryptographic Module Validation Program at Security Level 3.

With KMS, you can more easily add encryption and digital signature functionality to your application code directly via the API or using the AWS SDK. It natively integrates with many AWS services, which means you can use it to encrypt data at rest, and to control who/what can decrypt the data.

For example, KMS works with:

  • Amazon EC2
  • Amazon S3
  • Amazon EBS
  • AWS CodePipeline
  • And many more...

About KMS Keys

An AWS KMS key has:

  • Metadata, including key ID, key spec, key usage, creation date, description, and key state.
  • A reference to the key material, which is what gets used when you perform cryptographic operations with the KMS key.

Each KMS key has an ARN that includes a unique key identifier (key ID):

arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

Types of KMS Keys

AWS owned key
Created and exclusively used by AWS for internal encryption operations across AWS services. Customers have no visibility into the key policies or key usage, even in CloudTrail
AWS managed key
AWS creates and controls the lifecycle and key policies, but they’re resources in the customer’s AWS account. You can view CloudTrail events but can’t manage any aspect of these keys. They’re created & managed on your behalf by an AWS service integrated with KMS. These don’t have monthly fees.
Customer managed key
Customers create and control the lifecycle and key policies. All requests are logged and viewable in CloudTrail, but trails can be configured to exclude KMS events. Whenever you create a key via the API, you are creating a customer managed key. These have monthly and usage fees.

Alias

User-friendly name associated with a KMS key, and the alias can be used instead of the key ID in many of the AWS KMS API operations

For example: alias/my-app-key

Data Keys

Symmetric keys you use to encrypt data (including large amounts of data) and other data encryption keys. This is what you use for operations outside of AWS KMS, unlike symmetric KMS keys which can’t be downloaded.

Data Key Pairs

Asymmetric data keys with related public & private key pair. Designed for use in client-side encryption and decryption or signing and verification outside of AWS KMS.

KMS Abilities

KMS Abilities
KMS AbilitiesAWS KMS: Create, manage, and control: Symmetric keys; Asymmetric key pairs. For encryption/decryption, or for signing/verification. Encrypt, decrypt, and re-encrypt data Sign and verify messages with asymmetric KMS keys Generate & export symmetric data keys & asymmetric data key pairs Generate & verify HMAC codes Generate random numbers for cryptographic applicationsCreate, manage, and control:Use casesAWS KMSSymmetric keysAsymmetric key pairsFor encryption/decryption,or for signing/verificationEncrypt, decrypt, and re-encrypt dataSign and verify messages withasymmetric KMS keysGenerate & export symmetric datakeys & asymmetric data key pairsGenerate & verify HMAC codesGenerate random numbers forcryptographic applications
KMS Abilities

Drag the background to pan. Use the controls to zoom or fit the full diagram. Press Escape to close.

Controlling access to KMS keys

You can control access to your KMS keys by using:

  1. Key Policies
    • Policy attached to a KMS key that defines permissions on the key
    • All KMS keys must have a key policy
    • These only apply to the key they’re associated with. To allow access through IAM policies, the key policy must enable the account to use IAM policies.
  2. IAM Policies
    • Used to control access to KMS operations
    • Gives permission to create keys (kms:CreateKey) which should only be granted to principals who need it!
  3. Grants
    • Typically used for temporary permissions: create a grant, use its permissions, and delete it w/o changing key or IAM policies
  4. VPC Endpoint Policies
    • Limit access to KMS resources when using endpoints
    • These restrict access through the endpoint; they don’t replace key policies or IAM permissions.

Cost considerations with KMS!

Cost can quickly get out of hand, because pricing is based not only on the number of keys you have (monthly cost), but also on requests made to KMS. With a single command from, say, Athena processing terabytes of S3 data, you could very quickly balloon your costs. KMS request charges depend on the number of API calls, not the amount of data processed.

View AWS KMS pricing or estimate your costs with the AWS Pricing Calculator.

Use this cheat sheet with AI

Copy a ready-to-use prompt into your preferred AI assistant.

Preview prompt

> More AWS Security cheat sheets <

> KMS Cheat Sheet #2 <