Feature: Support for `RetentionInDays` and `Retain` in `LoggingConfig` for `AWS::Serverless::Function`

[aler95]

Description:

Currently, when defining a AWS::Serverless::Function, there is no native way to configure the retention period of the associated CloudWatch Log Group. The only available workaround is to manually create a corresponding AWS::Logs::LogGroup resource with a matching name and desired retention period. This adds complexity and creates potential deployment issues (e.g., log group already existing or being created out of order).

It would be beneficial to support log group retention directly in the LoggingConfig property of the AWS::Serverless::Function resource.

---

Proposed Solution:

Extend the LoggingConfig property to support the following fields:

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    LoggingConfig:
      RetentionInDays: 7        # Optional: number of days to retain logs (default: none/infinite)
      Retain: true              # Optional: preserve log group on resource deletion (default: false)

[sanyamk23]

Hi! Thanks for raising this. Having native support for log group retention and retention policies in LoggingConfig would make things simpler and less error-prone.

Proposed approach:
I’d suggest extending the LoggingConfig property for AWS::Serverless::Function to support both RetentionInDays and Retain. This way, users could directly set how long logs are kept and whether the log group should be preserved on function deletion, all within the function’s resource definition. For example:

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    LoggingConfig:
      RetentionInDays: 7      # Optional: number of days to retain logs
      Retain: true            # Optional: retain log group on deletion

If these properties are set, the construct would configure the log group accordingly; if not, it would fall back to the default (infinite retention, no retain policy). This would avoid the need for manual AWS::Logs::LogGroup resources and reduce deployment headaches.

If no one else is working on this, I’d be happy to start working on a PR. Does this approach make sense, or is there anything else I should consider? Let me know if you’d like me to move forward or if there’s more context to keep in mind. Thanks!

[seshubaws]

Hi @sanyamk23 thank you for looking into this! I think your design sounds good, we can just pass both new properties to through to the LogGroup resource to be set on create. Feel free to put up a PR for this!

[aler95]

Is there any news on this?

[vicheey]

Hi @aler95, thank you for this feature request.

We've investigated adding RetentionInDays support to LoggingConfig on AWS::Serverless::Function. Here's where we are:

Proposed approach

When RetentionInDays is specified in LoggingConfig, SAM Transform would generate an explicit AWS::Logs::LogGroup resource with the retention policy set, and pass the remaining LoggingConfig properties (LogFormat, LogGroup, ApplicationLogLevel, SystemLogLevel) to this new log group resource.

# What you'd write:
MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    LoggingConfig:
      LogFormat: JSON
      LogGroup: /aws/lambda/my-function

# What SAM generates:
# 1. AWS::Lambda::Function resource with LoggingConfig

# What you'd write:
MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    LoggingConfig:
      LogFormat: JSON
      LogGroup: /aws/lambda/my-function
      RetentionInDays: 30

# What SAM generates:
# 1. AWS::Logs::LogGroup (LogGroupName + RetentionInDays)
# 2. AWS::Lambda::Function with reference to the created log group.

This is equivalent to what you can already do today by manually adding an AWS::Logs::LogGroup resource alongside your function — SAM would just automate it.

Known limitation

If these properties are set, the construct would configure the log group accordingly;

This is not possible without creating an explicit AWS::Logs::LogGroup resource in the template. Currently the LoggingConfig property is passed directly to the LoggingConfig property of an AWS::Lambda::Function resource which only accepts LogFormat, LogGroup, ApplicationLogLevel, SystemLogLevel.

This approach works well for new functions. For existing functions, the Lambda service auto-creates the log group at runtime — and CloudFormation does not own it. When SAM generates an AWS::Logs::LogGroup resource with the same name, CloudFormation will fail with ResourceAlreadyExistsException because the log group already exists outside the stack.

We'd like to get community input on whether this trade-off is acceptable before proceeding with the implementation.

Regarding Retain (the other property you mentioned) — could you clarify the use case? If you mean DeletionPolicy: Retain on the generated log group to preserve logs when the stack is deleted, that's straightforward to add.

[vicheey]

Please upvote this issue to help us prioritize this feature support.

[snibbo]

It would even better to have this as a global setting in since most of the logs are retained for the same period.