AWS CDK AWS Logs (v1)

Common errors

• jsii.errors.JavaScriptError: Error: There is already a LogGroup named...

  cause A CloudWatch Log Group with the same name already exists in the AWS account and region where the stack is being deployed.
  fix If the log group is intended to be managed by this stack, ensure its name is unique. If you want to reference an existing log group, use `logs.LogGroup.from_log_group_name(self, 'ExistingLogGroup', 'MyExistingLogGroupName')` or `logs.LogGroup.from_log_group_arn(...)` instead of creating a new one. Alternatively, if the log group is implicitly created by a service, allow CDK to generate a unique name.

• jsii.errors.JSIIError: No resource 'LogGroup' exists with id '...' in stack '...'.

  cause This error can occur when trying to reference a LogGroup that hasn't been defined or imported correctly within the CDK stack, or if there's a typo in the construct ID.
  fix Verify that the LogGroup construct has been instantiated with the correct ID or that `LogGroup.from_log_group_name()`/`from_log_group_arn()` is used to import an existing log group before attempting to reference it. Check for typos in construct IDs. Ensure the stack contains the LogGroup definition.

• Error: Stack 'MyStack' failed to deploy: UPDATE_ROLLBACK_COMPLETE: ... The specified KMS key does not exist or is not accessible.

  cause When encrypting a LogGroup with a KMS key, the specified `encryptionKey` ARN is either invalid, the key does not exist, or the CloudFormation service role (or the entity creating the log group) does not have sufficient permissions to use the key.
  fix Verify the KMS key ARN is correct. Ensure the IAM role used by CloudFormation (or the resource deploying the log group) has `kms:Encrypt`, `kms:Decrypt`, `kms:ReEncrypt*`, `kms:GenerateDataKey*`, and `kms:DescribeKey` permissions on the specified KMS key. Ensure the KMS key is in the same region as the log group.

Warnings

• breaking AWS CDK v1, including `aws-cdk-aws-logs`, reached End-of-Support on June 1, 2023. This package is no longer being updated or receiving security patches. All users should migrate to AWS CDK v2 to ensure continued support, security, and access to new features.
  Fix: Migrate your CDK applications to AWS CDK v2. For the `aws-logs` library, this means replacing `pip install aws-cdk-aws-logs` with `pip install aws-cdk-lib` and updating import statements from `import aws_cdk.aws_logs as logs` to `from aws_cdk import aws_logs`. Consult the official AWS CDK v2 migration guide for detailed steps.
• gotcha The import paths for CDK constructs changed significantly from v1 to v2. Code written for `aws-cdk-aws-logs` (v1) will not work directly with `aws-cdk-lib` (v2) without updating imports.
  Fix: In AWS CDK v1, service constructs were in separate packages (e.g., `aws_cdk.aws_logs`). In v2, they are consolidated under `aws_cdk.aws_logs` within the `aws_cdk_lib` package. Update your imports from `import aws_cdk.aws_logs as logs` to `from aws_cdk import aws_logs`.
• gotcha CloudWatch Log Group names must be unique within an AWS Region for a given account. Attempting to deploy a CDK stack with a duplicate Log Group name will result in a CloudFormation deployment failure.
  Fix: Ensure that `log_group_name` property (if explicitly set) is unique, or allow CDK to generate a unique name by omitting it. If reusing log groups, import existing ones using `LogGroup.from_log_group_arn()` or `LogGroup.from_log_group_name()`.
• gotcha Incorrect or insufficient IAM permissions are a common cause of CloudFormation deployment failures when interacting with CloudWatch Logs, manifesting as 'You don't have permissions to perform this action' errors.
  Fix: Review the CloudFormation error messages to identify the missing permissions. Grant the necessary `logs:CreateLogGroup`, `logs:PutRetentionPolicy`, `logs:CreateLogStream`, `logs:PutLogEvents`, etc., permissions to the IAM role deploying the stack or to the resources interacting with the logs. Always apply the principle of least privilege.

Install

• pip install aws-cdk-aws-logs Install v1 package

Imports

• LogGroup
  wrong:

  from aws_cdk.aws_logs import LogGroup

  correct:

  from aws_cdk import core
  from aws_cdk import aws_logs as logs
  
  class MyStack(core.Stack):
      def __init__(self, scope: core.Construct, id: str, **kwargs) -> None:
          super().__init__(scope, id, **kwargs)
  
          log_group = logs.LogGroup(self, 'MyLogGroup')
  

  CDK v1 typically uses `import aws_cdk.aws_logs as logs` and accesses constructs as `logs.LogGroup`. Direct import `from aws_cdk.aws_logs import LogGroup` is less common for services in v1 and changed in v2.
• RetentionDays
  wrong:

  from aws_cdk.aws_logs.RetentionDays

  correct:

  from aws_cdk import aws_logs as logs
  
  logs.RetentionDays.ONE_WEEK

  RetentionDays is an enum within the `aws_logs` module, accessed via the module alias.

Quickstart

This quickstart demonstrates how to create a basic CloudWatch Log Group using `aws-cdk-aws-logs` with a 7-day retention policy. It also sets the removal policy to `DESTROY` for easier cleanup in development environments and outputs the log group name. Remember that `aws-cdk-aws-logs` is a CDK v1 package.

import os
from aws_cdk import core
from aws_cdk import aws_logs as logs

class MyLogStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs) -> None:
        super().__init__(scope, id, **kwargs)

        # Create a CloudWatch Log Group with a retention period of 7 days
        log_group = logs.LogGroup(self, 'ApplicationLogGroup',
            retention=logs.RetentionDays.ONE_WEEK,
            removal_policy=core.RemovalPolicy.DESTROY
        )

        core.CfnOutput(self, "LogGroupName", value=log_group.log_group_name)

app = core.App()
MyLogStack(app, "CdkLogsQuickstartStack",
    env=core.Environment(
        account=os.environ.get('CDK_DEFAULT_ACCOUNT'),
        region=os.environ.get('CDK_DEFAULT_REGION')
    )
)
app.synth()