AWS Key Management Service (KMS)

Getting Started Cheat Sheet

https://cybr.com ↗ Christophe Limpalair ↗

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

Controlling access to KMS keys

You can control access to your KMS keys by using:

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.
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!
Grants
- Typically used for temporary permissions: create a grant, use its permissions, and delete it w/o changing key or IAM policies
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.

Goal

Preview prompt

Prompt

Use this Cybr cheat sheet as reference: AWS Key Management Service (KMS)
Source: https://cybr.com/cheat-sheets/about-kms/

My goal: Help me understand KMS

Teach me the KMS concepts in this reference. Ask about my experience, then explain KMS keys versus data keys, aliases, key ownership, key policies, IAM policies, and grants using a concrete application example. Explain how permissions and request volume affect a design.

Use the included reference material even if you cannot open the source URL. Ask for missing context rather than inventing my environment. Explain assumptions. For version-sensitive service behavior or commands, consult current official documentation when available, cite it, and explain any differences from this reference. If you cannot verify something, say so.

Reference material from the cheat sheet (structured text or a curated summary):

{
  "subtitle": "Getting Started Cheat Sheet",
  "intro": "KMS lets you create, manage, and control cryptographic keys for your applications and AWS services to encrypt/decrypt and protect your data.",
  "hsm": "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.",
  "integration": "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.",
  "metadata": "An AWS KMS key has:",
  "metadataPoints": [
    "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."
  ],
  "arn": "Each KMS key has an ARN that includes a unique key identifier (key ID):",
  "arnExample": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab",
  "keyTypes": [
    {
      "title": "AWS owned key",
      "text": "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"
    },
    {
      "title": "AWS managed key",
      "text": "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."
    },
    {
      "title": "Customer managed key",
      "text": "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",
  "dataKeys": "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.",
  "dataKeyPairs": "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.",
  "abilities": [
    "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"
  ],
  "access": [
    {
      "title": "Key Policies",
      "points": [
        "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."
      ]
    },
    {
      "title": "IAM Policies",
      "points": [
        "Used to control access to KMS operations",
        "Gives permission to create keys (kms:CreateKey) which should only be granted to principals who need it!"
      ]
    },
    {
      "title": "Grants",
      "points": [
        "Typically used for temporary permissions: create a grant, use its permissions, and delete it w/o changing key or IAM policies"
      ]
    },
    {
      "title": "VPC Endpoint Policies",
      "points": [
        "Limit access to KMS resources when using endpoints",
        "These restrict access through the endpoint; they don’t replace key policies or IAM permissions."
      ]
    }
  ],
  "cost": "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.",
  "sources": [
    {
      "label": "About KMS & Getting Started",
      "href": "https://aws.amazon.com/kms/"
    },
    {
      "label": "KMS Documentation",
      "href": "https://docs.aws.amazon.com/kms/latest/developerguide/overview.html"
    },
    {
      "label": "About Data Keys",
      "href": "https://docs.aws.amazon.com/kms/latest/developerguide/data-keys.html"
    },
    {
      "label": "Auth & Access Control",
      "href": "https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html"
    }
  ]
}

More cheat sheets