KMS key management

Exam tasks: 5.2.1 (choose KMS and server- or client-side encryption), 5.3.3 (AWS generated key material), 5.3.5 (create and manage KMS keys across one or many Regions)

The decision: which kind of KMS key protects this data, who is allowed to use and administer it (and through which service), and how does it rotate, move between accounts and Regions, and eventually retire?

Picking the keyCopy Anchor Link

Who owns the keyCopy Anchor Link

Key specs and what each can doCopy Anchor Link

• Key usage is fixed at creation. An RSA key created for signing can't later encrypt.
• Asymmetric and HMAC keys don't rotate automatically or on demand. "Rotate" them by creating a new key and moving the alias.
• Asymmetric private keys never leave KMS. If a partner needs to verify your signatures offline, give them the public key from GetPublicKey.

Key policiesCopy Anchor Link

Every KMS key has exactly one key policy, and nothing can use the key unless that policy allows it, directly or by delegating to IAM.

{
  "Sid": "LetAccountIamDecide",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
  "Action": "kms:*",
  "Resource": "*"
}

• That default statement doesn't grant access to everyone in the account. It lets IAM policies in account 444455556666 grant access. Remove it and only principals named in the key policy can use the key.
• Split duties in the policy: key administrators (kms:Create*, kms:Put*, kms:ScheduleKeyDeletion, kms:EnableKeyRotation) and key users (kms:Encrypt, kms:Decrypt, kms:GenerateDataKey*, kms:ReEncrypt*). Administrators usually shouldn't be able to decrypt.
• The policy lockout safety check refuses a policy that would stop the caller from managing the key. If you bypass it and lock yourself out, only AWS Support can help, and only if the account root still has access.
• IAM Access Analyzer reports key policies that grant access outside your organization.

Condition keys worth knowingCopy Anchor Link

GrantsCopy Anchor Link

A grant gives one grantee principal a subset of operations on one key, without editing the key policy.

• Services use grants behind the scenes: EBS creates a grant when a volume attaches, RDS when an instance is created, Secrets Manager and Lambda for their own use.
• Grants support encryption context constraints, so a grant can be limited to one volume or one tenant.
• Grants are eventually consistent. The creator gets a grant token to use the grant immediately.
• Remove them with RetireGrant (the grantee or retiring principal, when the work is done) or RevokeGrant (an administrator, when access must stop). ListGrants shows who holds grants, which is worth checking after a compromise because a grant can outlive a deleted IAM policy.

Envelope encryption and encryption contextCopy Anchor Link

KMS encrypts at most 4 KB directly. Everything bigger uses a data key:

• GenerateDataKeyWithoutPlaintext returns only the encrypted copy. Use it when the component creating the key isn't the one that will encrypt, such as a control plane preparing keys for workers.
• Encryption context is non-secret key-value data bound to the ciphertext as additional authenticated data. Decrypt fails unless the same context is supplied, every CloudTrail entry records it, and key policies and grants can condition on it.
• Don't put secrets in the context: it appears in plaintext in CloudTrail.
• Heavy request rates can hit KMS throttling. Use S3 Bucket Keys, and data key caching in the AWS Encryption SDK, rather than asking for a quota increase first.

RotationCopy Anchor Link

• Rotation never re-encrypts existing data and doesn't rotate data keys. It only changes what new encryptions use.
• For multi-Region keys you enable rotation and trigger on-demand rotation on the primary; KMS copies new material to the replicas.
• KMS emits a RotateKey CloudTrail event and an EventBridge event you can use as audit evidence.

Multi-Region keysCopy Anchor Link

• A primary key and replicas in other Regions share key ID and key material, so ciphertext from one decrypts in the others without a cross-Region call.
• Each replica has its own key policy, grants, aliases and tags. You set the replica's policy when you create it, and later edits to the primary's policy don't propagate, so review each one.
• You can promote a replica to primary (UpdatePrimaryRegion), for example after losing the primary Region.
• Use them for client-side encryption of data that moves between Regions, global tables with the Database Encryption SDK, and signing in several Regions. AWS services that re-encrypt on replication (S3 Replication, EBS snapshot copy, RDS cross-Region replicas) work fine with separate single-Region keys.
• A primary can't be deleted while replicas exist.

Cross-account useCopy Anchor Link

1. The key policy in the key-owning account names the other account (or specific roles in it).
2. An IAM policy in the other account grants its principal the KMS actions on the key ARN (aliases don't resolve cross-account).
3. The other account can't see the key in its console and can't manage it.

Common pattern: a central security account owns customer managed keys per data domain, and workload accounts get use-only permissions, often combined with kms:ViaService so the keys only work through the storage service.

Disabling and deleting keysCopy Anchor Link

• Disable first if you suspect a key is unused. Watch CloudTrail for failed requests, then schedule deletion.
• An EventBridge rule or CloudWatch alarm on use attempts during PendingDeletion catches forgotten dependencies before the key is gone.
• Deleting a KMS key makes every ciphertext it protects permanently unreadable. AWS can't recover it.
• An SCP that denies kms:ScheduleKeyDeletion to everyone except a break-glass role is a common guardrail.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• AWS KMS keys: concepts
• Key policies in AWS KMS
• AWS KMS condition keys
• Rotate AWS KMS keys