KMS

Create and control cryptographic keys for encrypting data across AWS services

AWS Key Management Service (KMS) creates and controls the cryptographic keys used to encrypt data across nearly every AWS service. It provides a hardware-backed key store with full auditability through CloudTrail. Understanding KMS is essential because encryption at rest in AWS almost always involves a KMS key somewhere in the chain.

KMS Key Types and Ownership Models

KMS keys come in three management models. Choosing the right model determines who controls key rotation, deletion, and policy.

Key type	Who manages it	Cost	Rotation	Use case
AWS managed key	AWS (auto-created per service, e.g. aws/s3)	Free	Automatic, every 3 years	Default encryption when you don't need control
Customer managed key (CMK)	You	$1/month/key + $0.03 per 10,000 API calls	Optional, annual	Custom key policies, cross-account access, explicit audit trail
AWS owned key	AWS, not visible in your account	Free	AWS managed	Services that manage encryption entirely (DynamoDB default)

💡

Use customer managed keys when you need to: grant cross-account access, set custom key policies, import your own key material, or require the ability to disable or schedule deletion of the key.

Key Policies: The Root of KMS Access Control

Every KMS key has a resource-based policy called a key policy. Unlike most AWS resource policies, a KMS key policy is the primary access control mechanism - IAM policies alone are NOT sufficient to grant access to a KMS key unless the key policy explicitly allows it.

bash

# Minimal key policy that delegates to IAM
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow application role to use the key",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:role/AppRole"},
      "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "*"
    }
  ]
}

⚠️

If the key policy does NOT include the account root principal statement (Enable IAM User Permissions), no IAM policy can grant access to this key - not even the account administrator. This can lock you out of the key entirely. Always include the root principal delegation statement.

Envelope Encryption: How Data is Actually Encrypted

KMS never encrypts your actual data directly (with a few exceptions for small payloads). Instead it uses envelope encryption: a data key is generated by KMS, used to encrypt the data locally, and then the data key itself is encrypted by the KMS key. Only the encrypted data key is stored.

Step	What happens
1. GenerateDataKey	App calls KMS, receives a plaintext data key + an encrypted copy of the data key
2. Encrypt data	App encrypts data locally using the plaintext data key (AES-256-GCM)
3. Discard plaintext key	The plaintext data key is zeroed from memory. Only the encrypted data key is stored alongside the ciphertext
4. Decrypt later	App calls KMS Decrypt on the encrypted data key to get the plaintext key back, then decrypts the data locally

This model means your application handles bulk encryption locally (fast), while KMS handles only key wrapping/unwrapping (small, auditable operations). The AWS Encryption SDK automates this entire flow.

💡

For data smaller than 4KB, you can call kms:Encrypt directly without envelope encryption. For anything larger, use GenerateDataKey and encrypt locally.

Multi-Region Keys and Key Rotation

Feature	Single-region key	Multi-region key
Replication	Cannot be copied to another region	Primary key can replicate to multiple regions
Key material	Unique per region	Same key material in all replicas (same key ID prefix)
Use case	Single-region encryption	Global applications, disaster recovery, cross-region decryption without re-encryption
Availability	All key types	Customer managed keys only

Multi-region keys enable a critical DR pattern: data encrypted in us-east-1 can be decrypted in eu-west-1 using the replica key without needing to re-encrypt or transfer the KMS key. The key ID starts with mrk- to distinguish it from single-region keys.

bash

# Enable automatic key rotation (rotates key material every year)
aws kms enable-key-rotation --key-id alias/my-key

# Check if rotation is enabled
aws kms get-key-rotation-status --key-id alias/my-key

# Create a multi-region primary key
aws kms create-key \
  --multi-region \
  --description "Multi-region primary key"

# Replicate to another region
aws kms replicate-key \
  --key-id arn:aws:kms:us-east-1:123456789012:key/mrk-xxx \
  --replica-region eu-west-1

Grants and Condition Keys for Fine-Grained Access

Grants allow you to delegate temporary use of a KMS key to a principal without modifying the key policy. They are used internally by AWS services (like SSE-KMS in S3 and EBS) and are useful for programmatically delegating key access.

Access control method	Best for
Key policy	Defining baseline access for administrators and primary principals
IAM policy + key policy delegation	Standard IAM role-based access to KMS
Grants	Delegating temporary key access programmatically (e.g., service-to-service)
kms:ViaService condition	Restricting key usage to a specific AWS service only (e.g., only S3 can use this key)
kms:EncryptionContext condition	Enforce that callers include a specific encryption context (adds additional integrity check)

💡

Encryption context is a powerful security feature. It is a set of key-value pairs included with every encrypt/decrypt call and logged in CloudTrail. By requiring specific context (e.g., tenantId:customer123), you can prevent keys from being used for data belonging to a different tenant.

🎯

Interview Focus Points

1Explain envelope encryption and why KMS uses it instead of encrypting data directly.
2What is the difference between an AWS managed key, a customer managed key, and an AWS owned key?
3A developer says "I added kms:Decrypt to my IAM policy but I still get AccessDenied". What are the possible causes?
4What is a KMS key policy and how does it differ from an IAM policy?
5How do multi-region KMS keys enable cross-region disaster recovery?
6What is encryption context and why is it important for security and auditing?
7How does automatic key rotation work in KMS? Does rotating the key invalidate existing encrypted data?
8How would you grant an application in account B the ability to decrypt data using a KMS key in account A?
9What are KMS grants and when would you use them instead of key policy updates?