Why is this an issue?
Some AWS services create Log Groups implicitly and don’t let the developer choose the Log Group name. This means that
CloudFormation does not require the developer to declare the Log Group that the resource will write to.
If a Log Group is not declared within CloudFormation, then this Log Group will be automatically created at run time and
it won’t be managed by CloudFormation. The consequences are that the:
-
Log Group will not be removed when the Stack is removed.
-
Log Group attributes (such as retention) won’t be managed "as code" within CloudFormation.
These automatically created Log Groups will remain forever which can have huge impact on costs and security (the data stay forever
while this is unexpected from company or regulatory rules).
A good practice is to declare the target Log Group with CloudFormation, matching the name that the AWS will use so that the Log
Group resource is managed as code.
This rule applies to the following resources:
- AWS::Lambda::Function
- AWS::Serverless::Function
- AWS::ApiGatewayV2::Api
- AWS::CodeBuild::Project
Noncompliant code example
# There is no "Log Group" declared corresponding to "MyLambdaFunction": logs will not be managed by CloudFormation
MyLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Runtime: nodejs12.x
Description: Example of Lambda Function
Compliant solution
Example with Ref
MyLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Runtime: nodejs12.x
Description: Example of Lambda Function
MyFunctionLogGroup:
Type: AWS::Logs::LogGroup
Properties:
LogGroupName: !Join ['/', ['/aws/lambda', !Ref MyLambdaFunction]]
RetentionInDays: 30
Example with Sub
MyLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Runtime: nodejs12.x
Description: Example of Lambda Function
MyFunctionLogGroupSub:
Type: AWS::Logs::LogGroup
Properties:
LogGroupName: !Sub '/aws/lambda/${MyLambdaFunction}’
RetentionInDays: 30
