Cheat Sheet: AWS KMS

Level up on AWS KMS, IAM, and learn to secure AMK (AWS) and CMK (Client managed) keys and manage access

Kyler Middleton

by Kyler Middleton

Feb 16, 2022


AWS documentation is comprehensive, but it sometimes feels like you're reading the encyclopedia - there's just so much data! That's why we read the encyclopedia for you, and distilled down what we think are the most important flags for resources and services, and provide example IAM resource policies to give you a running start. Keep an eye out for this series as we build it out to include the most common (and most commonly misconfigured) services.


KMS, or Key Management Service, is the AWS service that stores both Amazon Managed Keys (AMKs) and Customer Managed Keys (CMKs). Keys are used to encrypt data stored in the AWS cloud.

KMS can help provide an extra layer of security beyond IAM - even if a resource is able to access a specific data store or secret, if that resource isn’t also able to access the key that data is encrypted with, it isn’t able to access the clear-text data.

How Does IAM Fit?

Access to keys is managed via IAM resource policies, so IAM is critical here. It’s also possible (and easy!) to accidentally block the root user of the account from accessing the key, which requires AWS support to fix, and that can take some time (read: weeks).



  • KMS keys (and KMS key aliases) exist by default in a single region only
    • The “regionality” flag can be set to permit replicating the key to other regions, but key policies (resource IAM policies) are not replicated
  • CMK (Customer Managed Keys) mean AWS doesn’t possess the private key, and is unable to read your encrypted data, great for regulated industries like healthcare and payment card info/PCI
  • KMS key policies can lock the root user out of managing the key, be cautious to include a root user permission along with any other changes you make

KMS IAM Policy Examples

This is the default KMS resource policy. If you build a new policy, make sure to add on to this existing policy template, or else you might lock your root user (and yourself!) out of reading or writing this key.

2  "Version": "2012-10-17",
3  "Id": "key-default-1",
4  "Statement": [
5    {
6      "Sid": "Enable IAM Root Permissions",
7      "Effect": "Allow",
8      "Principal": {
9        "AWS": "arn:aws:iam::1111111111:root"
10      },
11      "Action": "kms:*",
12      "Resource": "*"
13    }
14  ]

Permitting access to remote IAM roles (those in other accounts) to decrypt the KMS key. Note we added permissions on top of the root admin rights.

2  "Version" : "2012-10-17",
3  "Id" : "Cross Account Permits",
4  "Statement" : [
5    {
6      "Sid": "Enable IAM User Permissions",
7      "Effect": "Allow",
8      "Principal": {
9        "AWS": "arn:aws:iam::1111111111:root"
10      },
11      "Action": "kms:*",
12      "Resource": "*"
13    },
14    {
15      "Sid" : "Cross Account Permits",
16      "Effect" : "Allow",
17      "Action" : [
18        "kms:Decrypt",
19        "kms:DescribeKey"
20      ],
21      "Resource" : "*",
22      "Principal" : {
23        "AWS" : [
24          "arn:aws:iam::22222222222:role/RoleName1",
25          "arn:aws:iam::33333333333:role/RoleName2"
26        ]
27      }
28    }
29  ]

KMS Configuration Options

IAM-Related Options

  • Resource Policy (root user access only) - Controls who can access the key. By default only accessible to the root user.

Other Options

  • Alias (set, not set) - Alias is a human-readable name that is linked to a specific key. This is required if building a key in the console, but isn’t required if building via API (or Terraform). Multiple aliases to a single key are supported.
    • Recommendation: Set Alias to something memorable
  • Key Type (Symmetrical, Asymmetrical) - Keys can be used for simple data encryption, or for other purposes. More information in the docs
    • Recommendation: Leave as SYMMETRICAL_DEFAULT unless you have a specific use case.
  • Regionality (Single-Region, Multi-Region) - Keys exist in one region by default, unless this is set on key creation. If set to multi-region, key and contents can be replicated to other regions and be accessible locally to services there. If replicating keys, policies are not replicated
    • Recommendation: Leave as single region unless you may need it in other regions in the future
    • Risk: Regionality cannot be changed later - recreating the key is the only way to change this setting

    Related Cheat Sheets


    Cheat Sheet: AWS Elastic Container Registry (ECR)

    Use this graphic and write-up to upskill on AWS ECR super fast. You'll know enou...

    Mar 16, 2022 by Kyler Middleton


    Cheat Sheet: AWS Secrets Manager

    Level up on AWS Secrets Manager, IAM, and learn to store and manage secrets

    Mar 03, 2022 by Kyler Middleton


    Cheat Sheet: AWS S3

    Level up on AWS S3, IAM, and learn to store data and manage permissions to the r...

    Feb 01, 2022 by Kyler Middleton


    Join the beta waitlist

    Enter your email to get notified when our product becomes available to try.

    Sign Up for the community

    Create your member profile to get involved with our content, programs, and events.