3.2.1.4. Encryption Options for At-Rest and In-Transit Logs and Metrics (KMS, Client/Server-side)

3.2.1.4. Encrypting Logs & Metrics (KMS, TLS)

If your logs contain PII, API keys, or internal architecture details — and they almost certainly do — unencrypted storage is a compliance violation waiting to happen.

Encryption at rest:

• CloudWatch Logs: Associate a KMS CMK with a log group. All new log events are encrypted automatically.
• S3 log storage: SSE-S3 (simplest), SSE-KMS (audit trail + key rotation), or client-side encryption.
• Kinesis Data Streams: Server-side encryption with KMS key.

Encryption in transit: All AWS API calls use TLS. CloudWatch Agent communicates over HTTPS. VPC endpoints keep log traffic on AWS's private network.

Configuring KMS for CloudWatch Logs:

# Associate KMS key with a log group
aws logs associate-kms-key \
  --log-group-name "/prod/app/api" \
  --kms-key-id "arn:aws:kms:us-east-1:123456789012:key/abcd-1234"

KMS key policy must grant the CloudWatch Logs service principal permission:

{
  "Effect": "Allow",
  "Principal": {"Service": "logs.us-east-1.amazonaws.com"},
  "Action": ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey*"],
  "Resource": "*",
  "Condition": {
    "ArnEquals": {
      "kms:EncryptionContext:aws:logs:arn":
        "arn:aws:logs:us-east-1:123456789012:log-group:/prod/app/api"
    }
  }
}

Exam Trap: Even if IAM grants kms:Decrypt to a user, the KMS key policy must also authorize the CloudWatch Logs service to use the key. Missing the key policy statement is the most common cause of "Unable to encrypt/decrypt log events" errors. Both the IAM policy AND the key policy must allow access — they don't substitute for each other.