How do you encrypt an Amazon CloudWatch Logs log group with a customer managed KMS key, and what must that key's policy contain for it to work?

## Start from what is already true CloudWatch Logs encrypts stored log data at rest by default, using an AWS-owned key you never see. So a customer managed key (CMK) does not add encryption where there was none — it changes **who controls the key**. What you gain is: an auditable key policy you own, CloudTrail records of every KMS use, independent rotation, and the ability to revoke access to the data by disabling the key. Those are compliance properties, and that is the honest reason to do it. ## Associating the key The association is per log group, at creation or afterwards: ```bash aws logs create-log-group \ --log-group-name /myapp/api \ --kms-key-id arn:aws:kms:us-east-1:111122223333:key/1234abcd-... # or on an existing group aws logs associate-kms-key \ --log-group-name /myapp/api \ --kms-key-id arn:aws:kms:us-east-1:111122223333:key/1234abcd-... ``` `DisassociateKmsKey` removes it. Two constraints: the key must be **symmetric** — asymmetric KMS keys are not supported — and it must be in the **same region** as the log group, because KMS keys are regional. ## The key policy is the whole exam question When CloudWatch Logs encrypts and decrypts your data, it calls KMS **as a service**, using the regional service principal `logs.<region>.amazonaws.com`. Your own IAM permissions are irrelevant to that call. So the key's resource policy must allow that principal: ```json { "Effect": "Allow", "Principal": { "Service": "logs.us-east-1.amazonaws.com" }, "Action": [ "kms:Encrypt*", "kms:Decrypt*", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:Describe*" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:us-east-1:111122223333:log-group:*" } } } ``` Two details worth calling out in an interview: - `"Resource": "*"` inside a key policy means *this key*, not every key. Key policies are attached to one key; the wildcard is idiomatic, not a wildcard grant across KMS. - The **encryption context** condition is the security control that matters. CloudWatch Logs supplies `aws:logs:arn` as encryption context on every call, and the `ArnLike` condition confines the key's usability to log groups in your account. Grant the service principal unconditionally and any log group anywhere that knows the key ARN could, in principle, be pointed at it. Scoping the condition down to a specific group ARN rather than a wildcard is tighter still. If the grant is missing, the association fails immediately with an access-denied style error — a useful property, because the misconfiguration surfaces at configure time rather than silently later. ## Lifecycle traps **Disabling or deleting the key breaks the log group.** Existing data cannot be decrypted, so reads fail, and ingestion into the group stops working. KMS's mandatory waiting period before key deletion is your safety net, but a key disabled during an unrelated incident takes the log group down with it — which is exactly when you wanted the logs. Treat a key backing log groups as a production dependency: alarm on scheduled deletion and keep its policy under change control. **Rotation is transparent.** With automatic key rotation, KMS keeps prior key material so older data stays readable; the key ARN never changes, so nothing in CloudWatch Logs needs updating. **Association is not retroactive in an operational sense.** Associating a key encrypts subsequent data under it; disassociating stops using it for new data but does not rewrite what is already stored, so the key remains a dependency for reading history. **Cost.** Every encrypt/decrypt is a KMS API request with a charge, plus the monthly key fee. Immaterial for most log groups, worth knowing about for very high-volume ones. ## Where this sits The common interview version of this question is a scenario: "we created the key and the association call is denied." The answer is always the key policy and the `logs.<region>.amazonaws.com` service principal, not the caller's IAM permissions — the caller needs `logs:AssociateKmsKey` and typically `kms:DescribeKey`, but the encryption itself is done by the service on its own behalf.