2.2 Encryption & AWS KMS

Encryption at Rest vs in Transit

• At rest — protecting stored data (S3 objects, EBS volumes, DynamoDB tables, RDS, snapshots). This is AWS Key Management Service (KMS) territory.
• In transit — protecting data on the wire with Transport Layer Security (TLS). You enforce it with a policy Condition: aws:SecureTransport = false → Deny, which rejects any plaintext HTTP request.

Envelope Encryption

A KMS key cannot directly encrypt a payload larger than 4 KB, so KMS uses envelope encryption for real data:

1. Call GenerateDataKey; KMS returns a plaintext data key and an encrypted (wrapped) data key.
2. Encrypt your data locally with the plaintext data key, then discard the plaintext from memory immediately.
3. Store the encrypted data key next to the ciphertext.
4. To decrypt, send the encrypted data key to KMS Decrypt to unwrap it, then decrypt the data locally.

This keeps the heavy data local while KMS only ever handles the tiny key. GenerateDataKeyWithoutPlaintext is the variant for systems that want to store an encrypted key now and encrypt later, never holding the plaintext key in the meantime.

Key Types

Use a customer managed key when an answer needs a custom key policy, cross-account sharing, audited rotation, or grants — temporary, fine-grained permissions handed to a principal, often used by integrated AWS services for short-lived operations.

Rotation Facts (Exam Gold)

• Automatic rotation works only on symmetric encryption KMS keys whose material AWS KMS generated — not asymmetric, HMAC, or imported-material keys.
• The default rotation period is 365 days; you can configure it from 90 to 2,560 days.
• When KMS rotates a key, the key ID and ARN stay the same, so aliases and applications keep working. Old key material is retained so previously encrypted data still decrypts.
• Rotating a key does not re-encrypt existing data; new data uses new material, old data uses the retained material.

Service Integration

• S3 — SSE-S3 (S3-managed AES-256, no per-object audit trail) vs SSE-KMS (a KMS key, CloudTrail audit, fine-grained access control). Enable an S3 Bucket Key to collapse many KMS calls into one and cut request costs on high-volume buckets. SSE-C lets the caller supply the key.
• EBS — volume encryption is transparent; snapshots and any volume restored from an encrypted snapshot inherit encryption automatically.
• DynamoDB — encrypted at rest by default; you choose an AWS owned, AWS managed, or customer managed KMS key.
• CloudTrail logs every Decrypt/GenerateDataKey call, which is exactly why SSE-KMS is the answer when auditing key usage is required.

Key Policies, Grants, and Access Control

A KMS key's key policy is the primary access control document — unlike most resources, a CMK is not automatically usable by everyone in the account; the key policy must explicitly delegate to IAM. Three patterns recur on the exam:

• Key policy statements name principals and the KMS actions (kms:Encrypt, kms:Decrypt, kms:GenerateDataKey) they may perform.
• Grants provide temporary, programmatic permissions that AWS services and applications use for short-lived operations; they are easy to create and revoke and avoid editing the key policy.
• kms:ViaService conditions restrict a key so it can only be used through a specific service (for example, only via dynamodb.us-east-1.amazonaws.com).

If an application throws an AccessDeniedException only when encryption is involved, the cause is almost always a missing kms:Decrypt (or GenerateDataKey) permission on the key policy or the caller's IAM policy — not the data-layer permission.

Choosing the Right Encryption Answer

When a scenario stresses no audit trail needed, simplest, cheapest for S3, the answer is SSE-S3. When it stresses per-key access control, CloudTrail visibility, or compliance, the answer is SSE-KMS with a customer managed key. When it stresses the customer must hold the key material, it is SSE-C or imported key material. For very high request volumes against one bucket, the S3 Bucket Key is the cost-control answer because it dramatically reduces the number of KMS API requests by deriving object keys from a single bucket-level key.

Symmetric vs Asymmetric and Other Key Specs

KMS supports more than the default symmetric key, and the exam expects you to match the spec to the job. Symmetric keys (AES-256) handle the vast majority of encrypt/decrypt and GenerateDataKey work and are the only type eligible for automatic rotation. Asymmetric keys (RSA or elliptic-curve pairs) are for cases where a partner must encrypt with a public key without calling KMS, or for signing and verification (Sign/Verify). HMAC keys generate and verify message authentication codes.

A worked example: to let an external system encrypt data it sends you without granting it KMS access, hand out the public half of an asymmetric KMS key; only your account, holding the private half, can Decrypt. Because asymmetric, HMAC, and imported-material keys cannot auto-rotate, you must rotate them manually by creating a new key and re-pointing the alias.