Migrate to @aws-cdk/aws-lambda:useCdkManagedLogGroup: true

[MurraySpeight]

Is there a documented process to migrate over to using the flag @aws-cdk/aws-lambda:useCdkManagedLogGroup: true

When I turn this on in a stack already deployed I get errors that the log group already exists. If I delete the log group and try again then I get errors relating to the metrics filter not being found.

"Resource of type 'AWS::Logs::LogGroup' with identifier '{"/properties/LogGroupName":"/aws/lambda/my-stack-name-MyLambda-abcdef12345"}' already exists."

This flag seems valuable to have turned on but it seems difficult to migrate over to.

[DYNOSuprovo]

Hi @MurraySpeight! This is one of the most common friction points when enabling the @aws-cdk/aws-lambda:useCdkManagedLogGroup: true feature flag on pre-existing stacks.

Here is the exact explanation of why this happens and the two documented, zero-downtime ways to migrate successfully:

---

Why the Error Happens

1. Legacy Behavior:
   Before this flag, when a Lambda function executed for the first time, the AWS Lambda service automatically generated the /aws/lambda/<function-name> log group out-of-band in CloudWatch Logs (outside CloudFormation's control). If you set logRetention, CDK spawned an internal custom resource provider (LogRetention) to asynchronously apply retention policies.
2. New Flag Behavior:
   When you set @aws-cdk/aws-lambda:useCdkManagedLogGroup: true, CDK synthesizes an explicit AWS::Logs::LogGroup resource directly into your CloudFormation template.
3. The Collision:
   When you deploy the updated template, CloudFormation attempts to create the new AWS::Logs::LogGroup. Because the log group already exists in CloudWatch (having been created by previous Lambda runs), CloudFormation fails with:

   Resource of type 'AWS::Logs::LogGroup' with identifier '{"/properties/LogGroupName":"/aws/lambda/..."}' already exists.
   

   If you manually delete the log group from CloudWatch, existing Metric Filters or Subscription Filters fail because they reference a log group that no longer exists during the stack update.

---

Solution 1: CloudFormation Resource Import (Zero Log Loss & Zero Downtime - Recommended)

AWS CloudFormation provides a native Resource Import workflow specifically designed to bring pre-existing resources into CloudFormation management without deleting them or losing historical logs.

Steps:

1. Enable the flag and synthesize:
   Ensure @aws-cdk/aws-lambda:useCdkManagedLogGroup: true is set in cdk.json, and run:

   cdk synth

   Locate the synthesized template in cdk.out/<StackName>.template.json. In the template, note the logical ID of the newly generated log group (e.g. MyLambdaLogGroupABC12345).

2. Run CloudFormation Import:

   • Open the AWS CloudFormation Console.
   • Select your existing deployed stack.
   • Click Stack actions (top right) -> Import resources into stack.
   • Click Next, and choose Upload a template file -> select cdk.out/<StackName>.template.json.
   • CloudFormation will identify the new AWS::Logs::LogGroup resource and ask for its identifier.
   • In the LogGroupName field, enter your exact existing log group name:
     /aws/lambda/my-stack-name-MyLambda-abcdef12345
   • Click through the review and click Import resources.

3. Deploy with CDK:
   Once the import completes, CloudFormation now officially tracks the existing log group. Any future cdk deploy will run cleanly with zero errors.

---

Solution 2: Automated Two-Step Migration with logGroup Construct Override

If you are running in an automated CI/CD pipeline and cannot use the AWS Console import wizard, you can explicitly configure the log group with a temporary fallback or retention property:

import * as logs from 'aws-cdk-lib/aws-logs';
import * as cdk from 'aws-cdk-lib';

const fn = new lambda.Function(this, 'MyLambda', {
  // ... your lambda props
});

// Access the underlying CfnLogGroup and mark its deletion policy to Retain:
const cfnLogGroup = fn.logGroup.node.defaultChild as logs.CfnLogGroup;
if (cfnLogGroup) {
  cfnLogGroup.cfnOptions.deletionPolicy = cdk.CfnDeletionPolicy.RETAIN;
}

---

Summary Recommendation

Use Solution 1 (CloudFormation Resource Import). It takes less than 2 minutes, keeps all existing logs and metric alarms intact, and brings the log group under clean, native CloudFormation management going forward.

---

If this clarifies the collision error and guides your migration, please feel free to mark this as the accepted answer!