https://serverless-stack.com/ logo
Join Slack
Powered by
I see that SST is deploying some functions named `...
# sst
a
I see that SST is deploying some functions named 
…LogRetentionaae0aa3c5b4d-9XyoBY3lJCKM
… Why is that? Just saw this on my Console, I have a bunch of lambdas with.
log retention
name.
t
I think this is actually coming from CDK directly, I don't recall exactly what it's used for
a
Hum.
f
Yeah, so when you create a Lambda function, the log group for the function gets created by AWS Lambda on the function’s first invocation.
So when you first deploy the function, at deploy time, the log group doesn’t exist yet. So if you set the log retention for a function, CDK needs to create a custom resource that would go create the log group and sets the retention.
LogRetentionaae0aa3c5b4d-9XyoBY3lJCKM
is likely the function used by the custom resource.
a
Mmm.
But I think on SLS I also had log retention too.
And I didn’t see this procedure, could be?
I mean, thinking if CDK/SST can delete this lambda after all it’s deployed?
Just to keep a clean environment?
f
Yeah, after it’s deployed, I think you can clear out the log retention setting. And the custom resource will be removed. You can give it a try.
a
You mean setting defined here?
Copy code
app.setDefaultFunctionProps(stack => {
    return {
      runtime: 'nodejs12.x',
      logRetention: RetentionDays.TWO_WEEKS,
      tracing: Tracing.DISABLED,
    };
  });
f
Yup. The 
logRetention
field
a
Wondering how SLS solves this? I’m using same config as used in SLS.
f
Yeah, SLS always creates the LogGroup along with the functions. In your CloudFormation, you’d see a log group for each function. Where as with SST, the log groups are not in your CloudFormation, but rather created on the fly.
a
I see.
3 Views
Open in Slack
PreviousNext
Powered by