Make log groups for Lambda/CodeBuild accessible and/or manipulable

[rix0rrr]

Those Log Groups are implicitly created by the services upon first execution, which makes it impossible to attach things like MetricFilters to them.

We need a Custom Resource that will make the LG if it doesn't exist yet, do nothing if it already exists.

The same LG can be used to set the retention policy on the LG.

[rix0rrr]

Would be better if we can do this in CloudFormation, but we currently cannot. There are two issues if we were to create a LogGroup object as part of the deployment, as in this example:

class LoggedFunction extends lambda.Function {
  constructor(scope: cdk.Construct, id: string, props: lambda.FunctionProps) {
    super(scope, id, props);

    const log = new logs.LogGroup(this, `${id}-LogGroup`, {
      retentionDays: 30,
      logGroupName: `/aws/lambda/${this.functionName}`,
    });
    const logResource = log.node.findChild('Resource') as logs.CfnLogGroup;
    logResource.options.deletionPolicy = cdk.DeletionPolicy.Delete;
  }
}

1. There is a race condition, if your Lambda happens to get invoked while CloudFormation is still deploying, the creation of the LogGroup will fail and your CFN deployment will roll back.
2. If you do this on a hard-named Lambda functions (i.e., not with an autogenerated name), then the Log Group can't be created and your CFN deployment will also fail

[eladb]

Do you guys think #2067 will practically resolve this?

[SleeperSmith]

@rix0rrr Actually, this is possible by using some "depends on" statement straight in cloudformation.

1. Lambda role with no permission.
2. Lambda function that ref resource 1
3. CloudWatch log group that ref resource 2
4. Lambda Role permission policy that grant Lambda function permission to write to 3. This depends on 2 and 3.

This way, CFN creates role, lambda, log, policy in that order and doesn't race. Yeah you'll lose log if the invocation happens before the policy is created. Pick your poison for the time being I guess.

I feel the problem is Lambda should accept the name of log group instead of hard defaulting to a magical name. Urghh....

[mgjam]

@eladb when using #2067 on my existing lambda resource, it tried to create entirely new lambda function, not sure whether this is intended behavior. Looks like the issue can be solved by #2240 (comment). I will stick with creating log group relying on auto-generated log group name and configuring it - https://forums.aws.amazon.com/thread.jspa?threadID=260775