# Ensure CloudWatch log group is encrypted with an AWS KMS key - Source: https://support.icompaas.com/support/solutions/articles/a_1793292236388545-ensure-cloudwatch-log-group-is-encrypted-with-an-aws-kms-key - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that every Amazon CloudWatch Logs log group is associated with an AWS KMS key. CloudWatch Logs always encrypts log data at rest, but by default it uses keys managed by the service. Associating a KMS key, preferably a customer managed key, encrypts the log group's data with a key that you control. **Rationale** Logs often contain sensitive information such as request details, identifiers and error messages. With service-managed encryption, access to log data is controlled only by IAM permissions, and you cannot rotate, audit or revoke the encryption key yourself. A KMS key adds a key policy as a second access barrier, records key usage in AWS CloudTrail, and lets you disable access quickly during an incident or to meet compliance requirements. **Impact** - Adds key-policy based control over who can read the log data - Provides an audit trail of key usage and supports key rotation and revocation - KMS requests made by CloudWatch Logs are charged - If the KMS key is disabled or deleted, or its key policy no longer allows CloudWatch Logs, the log data encrypted with it cannot be read and new log events cannot be written **Default Value** New log groups are not associated with a KMS key. Their data is encrypted at rest by CloudWatch Logs with service-managed keys. **Pre-Requisites** - IAM permissions: logs:DescribeLogGroups, logs:AssociateKmsKey, logs:DisassociateKmsKey, kms:DescribeKey and kms:PutKeyPolicy - A symmetric customer managed KMS key in the same region as the log group, whose key policy allows the CloudWatch Logs service principal for that region (logs..amazonaws.com) to use it **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon CloudWatch console and select **Log groups** under **Logs**. 3. Select a log group and check the **KMS key ID** in its details. 4. Repeat for each log group in each region in use. 5. If any log group has no KMS key ID, follow the implementation steps. **CLI:** Show the KMS key of each log group in a region: aws logs describe-log-groups --region --query "logGroups\[\].\[logGroupName,kmsKeyId\]" --output table A log group fails if kmsKeyId is empty. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the AWS KMS console and make sure the key policy of the customer managed key allows the CloudWatch Logs service principal for the region to use the key. 3. For new log groups, open the Amazon CloudWatch console, select **Log groups** and choose **Create log group**, then enter the KMS key ARN in the KMS key field and choose **Create**. 4. For existing log groups, use the CLI command below to associate the key. 5. Repeat for each affected log group in each region in use. **CLI:** Associate a KMS key with an existing log group: aws logs associate-kms-key --region --log-group-name --kms-key-id **Backout Plan** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open **AWS CloudShell** from the console toolbar and run the CLI command below to disassociate the KMS key from the log group. **CLI:** aws logs disassociate-kms-key --region --log-group-name Note: after the key is disassociated, new log data is encrypted with service-managed keys, but data ingested while the key was associated stays encrypted with it. Do not disable or delete the key while that data must remain readable. **Reference** - [https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) - [https://docs.aws.amazon.com/cli/latest/reference/logs/associate-kms-key.html](https://docs.aws.amazon.com/cli/latest/reference/logs/associate-kms-key.html) - [https://docs.aws.amazon.com/cli/latest/reference/logs/disassociate-kms-key.html](https://docs.aws.amazon.com/cli/latest/reference/logs/disassociate-kms-key.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.