Service 33

AWS KMS

SecurityEncryptionManaged

AWS KMS (Key Management Service) creates and manages encryption keys. Whenever an AWS service offers "encryption at rest" — S3, EBS, RDS, Secrets Manager, DynamoDB — it almost always does the work through KMS behind the scenes. KMS holds the key material in tamper-resistant hardware, exposes an API to use keys without revealing the bytes, and logs every use to CloudTrail.

Your application never sees the key itself; it sees only the result of an encrypt or decrypt call.

Key Types

Customer Managed Keys (CMKs) are yours: you set policies, rotation, and deletion, at USD 1 per key per month plus per request. AWS Managed Keys (like aws/s3) are created per service, free, and not policy-editable. AWS Owned Keys are invisible, shared inside AWS services.

Most KMS keys are symmetric (AES-256) for envelope encryption; KMS also supports asymmetric (RSA, ECC) keys for signatures and public-key encryption, and HMAC keys.

Envelope Encryption

Envelope encryption is why KMS scales to billions of requests without becoming a bottleneck. To encrypt a large object, a service asks KMS for a data key, gets it back in plaintext and ciphertext form, encrypts the object locally with the plaintext key, discards the plaintext, and stores the encrypted data key beside the object.

Envelope Encryption — A Data Key Wrapped by the KMS Key

Your datalarge object, encrypted locally

→

Data keyrandom AES key encrypts the object; plaintext discarded

→

KMS keywraps the data key; never leaves KMS

The encrypted data key is stored beside the object. To read it, the service asks KMS to unwrap the data key — so the KMS key only ever encrypts a few kilobytes and scales to billions of operations.

To decrypt, the service sends the encrypted data key to KMS, gets the plaintext back, decrypts the object, and discards the key again. The KMS key never leaves KMS, the plaintext data key is never persisted, and the CMK only ever encrypts a few kilobytes.

Key Policies, Rotation, and Multi-Region

A KMS key has a key policy — a resource-based policy that is the primary authorization mechanism; unlike most of AWS, an IAM policy alone is usually not enough, the key policy must allow the action too. Grants give temporary narrow permission, used when a service acts on your behalf (EBS creates grants when an encrypted volume attaches).

Automatic annual rotation for symmetric CMKs is one setting and transparent to applications. Multi-Region keys share key material and key ID across Regions so ciphertext is portable for cross-Region replication.

KMS vs CloudHSM vs Secrets Manager

KMS — managed encryption keys for AWS-service encryption at rest — the default for almost everyone.

CloudHSM — single-tenant FIPS 140-3 Level 3 hardware you control, only when shared HSM is unacceptable for compliance.

Secrets Manager — application secrets (passwords, API keys) — built on KMS, with rotation and access control on top.

Common Mistakes

Assuming an IAM policy alone grants KMS access — most actions also require an explicit allow in the key policy.
Leaving the default key policy in place, which grants broad account access instead of restricting to specific roles.
Re-encrypting data on the wire for cross-Region replication instead of using multi-Region keys.
Hard-coding raw key IDs in application config instead of aliases, so swapping a key requires code changes.
Scheduling a CMK for deletion without realizing all data encrypted under it becomes unrecoverable once gone.
Reaching for CloudHSM when KMS (itself backed by FIPS 140-3 Level 3 HSMs) is sufficient, adding cost and operational burden.

Best Practices

Use Customer Managed Keys for important data and AWS Managed Keys where you do not need policy control.
Tighten key policies to specific roles and actions instead of the permissive default.
Turn on automatic rotation for symmetric CMKs unless policy forbids it.
Use multi-Region keys for cross-Region replicated data to avoid re-encrypting on the wire.
Reference keys by alias, not raw key ID, so you can swap keys without code changes.
Audit every encrypt/decrypt call in CloudTrail and alert on unusual patterns.

Comparable services GCP Cloud KMSAzure Azure Key Vault

Knowledge Check

In envelope encryption, what does KMS actually encrypt?

A small data key, which in turn encrypts the large object locally — KMS never touches the bulk data
The entire object, byte for byte, streamed all the way up to the service on every single encrypt request
Only the object's metadata and tags, leaving the actual payload bytes in the clear
Nothing at all — it simply stores the plaintext data key on your behalf for later

Why is a KMS key policy different from most AWS authorization?

The key policy is resource-based and required — an IAM policy alone is usually not enough to use the key
The key policy is evaluated only for the account root user and is silently ignored for everyone else entirely
The key policy overrides any SCP or permission boundary that would otherwise deny the action
A single key policy grants access to every KMS key in the whole account at once

What problem do multi-Region KMS keys solve?

They share key material and key ID across Regions so ciphertext is portable for cross-Region replication
They make a single key cheaper to operate by spreading its monthly charge across several Regions
They replicate the key's policies and grants automatically out to every replica in each of the other Regions
They are the only way to enable asymmetric signing with a KMS key

When is CloudHSM warranted over KMS?

When compliance requires single-tenant hardware and shared HSM is unacceptable
For essentially all production encryption work, since the HSMs behind KMS are not FIPS-validated
Whenever you need keys rotated automatically on a fixed schedule with no manual effort
For securely storing application passwords and database connection strings

You got correct