skip_destroy support for aws_cloudwatch_log_group

[G-Rath]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

It would be usable to have a way of skipping aws_cloudwatch_log_group resources from being destroyed without actually blocking a destroy/change, to make it easier to represent the tight coupling such resources typically have with the related resources that log to them while still ensuring any captured logs will be kept for compliance reasons.

My use case for this is born from using modules where we're trying to encapsulate supporting resources needed for core functionality. For example, VPC flow logging to CloudWatch requires 1. an aws_flog_log resource, 2. a role & policy, and 3. a aws_cloudwatch_log_group resource.

Currently, I've got the following options:

1. Create the CloudWatch group in the module, without prevent_destroy
   • this means if the module is destroyed for some reason, we lose the logs without warning
2. Create the CloudWatch group in the module, with prevent_destroy
   • this means if the module is destroyed for some reason, we error on the group and have to manually remove the group from the state
3. Create the CloudWatch group outside of the module, and pass its arn in
   • if the group is created in the same root module, then we've still got the same issue in 1. and 2.
   • if the group is created in a different root module, we're now having to manage another module and there is an implicit subtle dependency between the modules

If aws_cloudwatch_log_group supported a skip_destroy attribute, I could include that resource in my module with that attribute set to true and not have to worry - this would also tie in nicely with retention periods, since the groups themselves don't cost money so they're effectively self-destroying.

Another good example (imo) is with provisioning scripts: we typically create a dedicated module to represent our provisioning scripts for EC2 instances which outputs the script in a form that can be passed as user_data - part of these scripts include configuring the CloudWatch Agent to send specific logs; there are a number of these logs and sometimes we make changes such as adding a new log which means it would be very useful for the provisioning script module to be able to safely create the log groups its going to need.

There is a general Terraform feature request for supporting this but it does not look like we'll get it anytime soon, and I think its a good enough fit for this resource (+ it should only require a small amount of code), to make it worth supporting via an attribute while we wait for that feature to land someday.

New or Affected Resource(s)

• aws_cloudwatch_log_group

Potential Terraform Configuration

resource "aws_cloudwatch_log_group" "yada" {
  name = "Yada"

  skip_destroy = true

  tags = {
    Environment = "production"
    Application = "serviceA"
  }
}

References

• This attribute is supported already by aws_ecs_task_definition, aws_lambda_layer_version, and aws_ec2_ebs_volume_attachment (I think there's a few others around too with slightly different names)

[G-Rath]

I'd be happy to take a crack at implementing this too

[github-actions]

This functionality has been released in v4.40.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.