AWS CDK: Replacing Lambda Log Retention With Log Groups

Jan 14, 2026 by Editorial Team 56 views

Hey everyone! 👋 Today, we're diving into a crucial update for those of you using the AWS Cloud Development Kit (CDK) and dealing with Lambda functions. We're talking about the deprecated logRetention parameter and its replacement with the more flexible LogGroup object. Let's break down why this change is important, how to implement it, and what benefits it brings.

The Problem: Deprecation of `logRetention`

For a while, the lambda.Function construct in the AWS CDK had a handy logRetention parameter. This allowed you to easily configure how long your Lambda function's logs were kept in CloudWatch. You could specify options like ONE_DAY, THREE_DAYS, ONE_WEEK, and so on. Pretty straightforward, right? Well, the AWS CDK team decided to shift the approach, and the logRetention parameter is now officially deprecated. This means it's still functional for now, but it's no longer the recommended way to manage your Lambda function logs, and it will eventually be removed in future versions. You definitely don't want to get caught off guard when that happens!

So, why the change? The main reason is to provide more granular control and flexibility over your Lambda function logs. By moving to a dedicated LogGroup object, you gain access to a wider range of configuration options and better integration with other AWS services. This gives you more power to fine-tune your logging strategy and meet specific compliance or operational requirements.

Now, you might be thinking, "What's the big deal? logRetention was easy!" And you're right, it was simple. But this change is about making your infrastructure more robust, scalable, and adaptable. It's about taking advantage of the full capabilities of AWS CloudWatch and ensuring your logging setup aligns with best practices.

We'll cover how to replace logRetention with LogGroup in the next section, so keep reading! Also, it's worth noting that if you don't specify a logGroup when creating your lambda.Function, the CDK will automatically create a LogGroup for you with the default settings. However, it's always best to be explicit about your logging configuration.

Also, by using a separate LogGroup, you can now apply CloudWatch log insights queries, metrics, and alarms to the Lambda logs, without impacting the Lambda function definition.

Finally, the old approach was somewhat limited. You could only set the retention period. Now, by using a LogGroup, you get access to all the features of CloudWatch Logs. This includes things like access logging, data protection features, and more.

The Solution: Using `LogGroup` for Log Retention

Alright, let's get down to business and figure out how to swap out logRetention for LogGroup. The good news is, it's not as complicated as it might sound. The core idea is to create a LogGroup resource and then associate it with your Lambda function.

Here's a step-by-step guide:

Import the Necessary Modules: First, you'll need to import the aws_logs module in addition to your existing CDK imports. This is where the LogGroup construct lives.
```
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as logs from 'aws-cdk-lib/aws-logs';
import * as cdk from 'aws-cdk-lib';
```
Create the LogGroup: Next, you'll define your LogGroup. This is where you specify the retention period and any other configurations you need. You'll typically place this definition in the same stack as your Lambda function.
```
const logGroup = new logs.LogGroup(this, 'MyLambdaLogGroup', {
  logGroupName: '/aws/lambda/MyLambdaFunction', // Important: Make sure this matches your function's name
  retention: logs.RetentionDays.THREE_DAYS,
  removalPolicy: cdk.RemovalPolicy.DESTROY, // or RETAIN, depending on your needs
});
```
- logGroupName: This is the name of the log group. It's crucial that this matches the expected format /aws/lambda/<function_name> for your Lambda functions to write logs to it correctly.
- retention: This is where you set the log retention period. You can choose from options like ONE_DAY, THREE_DAYS, ONE_WEEK, ONE_MONTH, THREE_MONTHS, SIX_MONTHS, ONE_YEAR, FIVE_YEARS, or INFINITE. Pick the duration that aligns with your compliance and operational requirements.
- removalPolicy: This defines what happens to the log group when you destroy the stack. DESTROY will remove the log group and its contents. RETAIN will keep the log group, which is useful for audit purposes. Be careful with this setting, as it can impact your AWS costs if you choose to retain logs indefinitely.
Create the Lambda function: Now, create the lambda.Function with the log group.
```
const myFunction = new lambda.Function(this, 'MyLambdaFunction', {
  runtime: lambda.Runtime.NODEJS_16_X,
  handler: 'index.handler',
  code: lambda.Code.fromAsset('lambda-handler'),
  logGroup: logGroup,
});
```
- logGroup: This is the critical part. You pass your LogGroup object to the logGroup parameter of the lambda.Function construct. This tells the Lambda function to use your custom log group.
Deploy: Deploy your stack, and you're good to go! Your Lambda function will now use the custom LogGroup with the retention settings you configured. Verify the logs are going to the proper place by inspecting the logs in CloudWatch.

And that's it, guys! It may seem like a few extra lines of code, but the payoff is well worth the effort in terms of flexibility and control. Plus, by adopting this approach, you'll be future-proofing your infrastructure, as the deprecated logRetention parameter may be removed in future CDK versions. Don't worry, the changes are not complex, and the advantages are significant.

Benefits of Using `LogGroup`

Switching to LogGroup brings several advantages. First and foremost, you get complete control over your log retention policies. You can choose from a range of retention periods to meet your needs. Second, using LogGroup opens the door to advanced CloudWatch features. You can configure things like log insights queries, metrics, and alarms directly on your log group. This is incredibly helpful for monitoring, troubleshooting, and gaining insights into your Lambda function's behavior. The extra control over your logs is another major benefit, it allows you to get more granular data on the performance of your Lambda function.

Another significant benefit is the separation of concerns. By managing your log retention separately, you keep your Lambda function code cleaner and more focused on its core functionality. This separation can also make your infrastructure easier to manage and maintain in the long run.

Plus, you get the latest features as soon as they're available. AWS is continuously updating CloudWatch Logs, adding new features and improving existing ones. By using LogGroup, you're always aligned with the latest advancements in logging, so that you can quickly resolve issues.

Finally, with the LogGroup approach, you can create multiple log groups. This is useful if you have several Lambda functions, and you want to manage their logs differently. It also gives you more control and visibility. For example, you might create one log group for error logs and another for informational logs. In this way, you can easily filter, analyze, and monitor your logs more effectively.

Troubleshooting Common Issues

Even with these clear instructions, you might run into a few common issues. Let's look at some of the common things that can cause problems and how to solve them:

Incorrect logGroupName: The most frequent problem is getting the logGroupName wrong. Remember, this must match the format /aws/lambda/<function_name>. Double-check the function name in your code and make sure the logGroupName matches it precisely. This is how CloudWatch knows where to store the logs. If the names don't match, your logs won't show up.
Permissions: Ensure that your Lambda function has the necessary permissions to write to the LogGroup. The CDK typically handles this for you, but it's worth double-checking, especially if you're using custom IAM roles or policies. You may need to grant your Lambda function permissions to put log events into the specified log group.
Deployment Errors: If you encounter errors during deployment, check the CloudWatch logs for the CDK itself. These logs often provide valuable clues about what went wrong. Errors often give hints, but they require a little detective work to decipher. The errors might indicate permission problems, incorrect resource names, or other issues related to the AWS configuration.
Log Retention Not Working: If your logs are not being retained for the specified duration, double-check the retention setting in your LogGroup definition. Make sure you've selected the correct retention period (e.g., THREE_DAYS, ONE_WEEK) and that it's being applied correctly during deployment.
Missing Logs: If you're not seeing any logs at all, first, verify that your Lambda function is actually executing. You can test this by adding a simple console.log() statement to your function's code. Then, check the logGroupName and make sure it is configured correctly.

By keeping these tips in mind, you can prevent many of the common issues and quickly troubleshoot any problems that arise.

Conclusion: Embrace the Change

So, there you have it, folks! Replacing logRetention with LogGroup is an essential update for any AWS CDK user. It provides enhanced flexibility, granular control, and a more robust logging setup. While it might require a little bit of extra setup initially, the benefits of improved control, advanced features, and future-proofing your infrastructure are well worth the effort.

By following the steps outlined above and keeping the troubleshooting tips in mind, you can seamlessly transition to the LogGroup approach and ensure your Lambda functions' logs are managed effectively. It's not just about compliance, guys; it's about setting up a better long-term strategy for your logs.

So, embrace the change, update your code, and take advantage of the power of LogGroup. Happy coding!