AWS KMS Explained: Keys, Key Policies and Envelope Encryption

How AWS Key Management Service protects your data: AWS managed vs customer managed keys, key policies vs IAM, envelope encryption with data keys, rotation, grants and the AccessDenied traps.

Encryption on AWS almost always means AWS Key Management Service (KMS). When you tick "encrypt" on an S3 bucket, an EBS volume, an RDS database or a Secrets Manager secret, KMS manages the keys behind it. Understanding how KMS works explains both how your data is protected and why "AccessDenied" sometimes appears where you least expect it.

KMS keys

A KMS key (formerly "customer master key") is a logical key whose key material never leaves KMS's hardware security modules unencrypted. You never download it; you ask KMS to use it.

TypeWho managesKey policyUse when
AWS owned keysAWS, shared across accountsNot visibleDefault encryption you do not need to control
AWS managed keys (aws/s3, aws/ebs)AWS, in your accountFixed by AWSSimple encryption within one account
Customer managed keysYouYou write itControl over access, rotation, cross-account use, auditing

Keys can be symmetric (AES-256, the default, used for most encryption) or asymmetric (RSA, ECC, for signing or public-key encryption), and HMAC keys exist for message authentication.

Envelope encryption: why KMS can encrypt terabytes

KMS's Encrypt API only accepts up to 4 KB. Services encrypt large data with envelope encryption:

  1. The service calls GenerateDataKey. KMS returns a data key twice: in plaintext and encrypted under your KMS key.
  2. The service encrypts your data locally with the plaintext data key, then discards the plaintext copy.
  3. It stores the encrypted data key next to the encrypted data.
  4. To decrypt, it sends the encrypted data key to KMS's Decrypt API, gets the plaintext data key back (if allowed), and decrypts locally.

The data never travels to KMS, which keeps encryption fast, and access to the KMS key controls access to every piece of data protected by it. Disable the key and all of that data becomes unreadable.

Key policies: the most important KMS concept

Every KMS key has a key policy, a resource-based policy. Unlike most AWS resources, IAM policies alone cannot grant access to a KMS key unless the key policy allows it. The default key policy contains a statement that delegates to IAM:

{
  "Sid": "Enable IAM policies",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
  "Action": "kms:*",
  "Resource": "*"
}

With this statement, IAM policies in the account can grant KMS permissions. Without it, only principals named in the key policy can use the key. Remove it carelessly and you can lock everyone out, which is why KMS refuses some policy changes that would make a key unmanageable.

Separate key administrators (manage the key) from key users (use it to encrypt and decrypt) in the key policy.

Grants and service integrations

Grants give temporary, narrowly scoped permissions to use a key, often created automatically by AWS services (for example EBS attaching an encrypted volume). The condition key kms:ViaService restricts a key so it can only be used through a specific service, such as S3 in one Region.

Rotation

  • Automatic rotation for customer managed symmetric keys creates new key material on a schedule you choose (yearly by default). Old material is kept to decrypt old data, so nothing needs re-encrypting and the key ID stays the same.
  • AWS managed keys rotate automatically.
  • Imported key material (bring your own key) cannot rotate automatically; you rotate manually by creating a new key and switching aliases.

Cross-account and multi-Region

To let another account use a key, allow its principals in the key policy and grant them KMS permissions in their own IAM policies. AWS managed keys cannot be shared, which is why cross-account S3 access to SSE-KMS objects needs a customer managed key. Multi-Region keys are related keys in different Regions with the same key material, useful for global applications and disaster recovery.

Common KMS errors

  • S3 says AccessDenied on SSE-KMS objects: the caller lacks kms:Decrypt, or the key policy does not allow it.
  • ThrottlingException: very high request rates; use S3 Bucket Keys to cut KMS calls dramatically.
  • KMSInvalidStateException: the key is disabled or pending deletion. Deletion has a 7–30 day waiting period; cancel it if it was a mistake.

CloudTrail logs every KMS API call, which makes it the best tool for finding which principal and which key failed.

Practice it

Encrypt S3 with your own key in KMS Encryption: Customer Managed Key, S3 SSE-KMS and Key Rotation, secure a whole stack in KMS-Encrypted App Stack, and import key material in KMS Bring Your Own Key. Then fix Finance Reports Fail with KMS AccessDenied.

FAQ

Can AWS employees see my data in KMS?

KMS is designed so that plaintext key material is never available to anyone, including AWS operators, outside the HSMs.

How much does KMS cost?

A monthly fee per customer managed key plus a charge per API request, with a free tier of requests. AWS managed keys have no monthly fee.

Browse all AWS tutorials · Hands-on AWS labs