L11. AWS KMS: Key Policies, Envelope Encryption & Key Rotation

The Key Policy Is the Root of Authorization

Most AWS resources are governed by IAM policies alone: attach a policy to a user or role, and that identity has the permission. KMS keys work differently. Every customer managed key (CMK) has a resource-based key policy attached directly to it, and that key policy is the root of authorization. An IAM policy granting kms:Decrypt on a key is never sufficient by itself; the key policy must also grant access, either directly or by delegating that decision to IAM via the standard "Enable IAM User Permissions" statement. If the key policy does not cooperate, the IAM policy is worthless for that key. KMS grants are a second, more surgical access mechanism: temporary, programmatic, revocable delegated access to a specific key, typically used by an AWS service acting on a customer's behalf (for example, letting an EBS volume use a CMK to encrypt its blocks). Grants can be created and retired without editing the key policy itself, and are well suited to short-lived, service-to-service access.

Envelope Encryption: Keep Bulk Data Off the Wire

KMS does not encrypt large files directly, and the exam expects you to know why. The pattern is envelope encryption:

1. The application calls GenerateDataKey against a CMK.
2. KMS returns a plaintext data key, and that same data key encrypted under the CMK.
3. The application encrypts the actual data locally with the plaintext key, then discards that plaintext copy.
4. The application stores the encrypted data key alongside the ciphertext.

Only the small data key ever crosses the wire to KMS, never the bulk data itself. This keeps encryption fast and avoids KMS API payload limits. To decrypt later, the application sends the encrypted data key back to KMS, gets the plaintext key back, and decrypts the ciphertext locally.

Key Rotation Rules

Rotation replaces the underlying key material while preserving the key ID and ARN, so nothing referencing the key needs to change. Imported key material is the one case where automatic rotation is off the table entirely, since AWS did not generate that material and cannot silently regenerate it for you.

Multi-Region Keys and CloudHSM

Multi-Region keys replicate a CMK across regions as related keys sharing the same key material and key ID. Data encrypted in one region can be decrypted in another using the replica key, with no decrypt-and-re-encrypt round trip during failover, which matters for disaster recovery designs with cross-region replication. AWS CloudHSM provides single-tenant, dedicated hardware validated to FIPS 140-2 Level 3. Standard KMS runs on shared, multi-tenant HSM infrastructure at Level 2. When a scenario mandates full control over key material or a hard Level 3 requirement, CloudHSM is the answer, not KMS. A KMS custom key store backed by CloudHSM offers a middle path: the familiar KMS API surface while key material physically lives in dedicated Level 3 hardware. Exam tip: If an IAM policy "should" grant access to a KMS key but doesn't seem to work, check whether the key policy is the missing piece. Whenever "bulk data" and "KMS" appear together, think envelope encryption and GenerateDataKey, not a direct Encrypt call on the whole payload.