fix: correct CloudWatch Log Group dependency ordering

[LorisFriedel]

Problem

The aws_cloudwatch_log_group.forwarder_log_group resource constructs its name from aws_lambda_function.forwarder.function_name, creating an implicit Terraform dependency that forces the Lambda to be created before its log group. This causes ResourceAlreadyExistsException failures because:

• AWS Lambda auto-creates log groups. When a Lambda function is invoked, AWS automatically creates /aws/lambda/<function_name> if it doesn't exist. Since Terraform creates the Lambda first (due to the wrong dependency direction), any invocation before Terraform reaches the log group resource causes a conflict.
• Pre-existing log groups. When adopting existing Lambda infrastructure into a new Terraform state (e.g., via terraform import or state migration), the log group already exists and Terraform's CreateLogGroup call fails.

Root Cause

# main.tf (before fix)
resource "aws_cloudwatch_log_group" "forwarder_log_group" {
  name = "/aws/lambda/${aws_lambda_function.forwarder.function_name}"
  #                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  #                      Creates: log_group → depends_on → lambda
  #                      Correct direction: lambda → depends_on → log_group
}

The dependency is backwards. The log group should exist before the Lambda, not after.

Fix

Two changes that invert the dependency direction:

1. Break the wrong dependency

# Log group name now uses var.function_name directly
name = "/aws/lambda/${var.function_name}"

The resolved string is identical (var.function_name is what aws_lambda_function.forwarder.function_name was set to), but the Terraform dependency edge is removed.

2. Create the correct dependency

# Lambda now explicitly points to the Terraform-managed log group
logging_config {
  log_format = "Text"
  log_group  = aws_cloudwatch_log_group.forwarder_log_group.name
}

This tells both Terraform and the Lambda runtime to use the Terraform-managed log group. Terraform creates the log group first, then the Lambda pointing at it. The Lambda runtime won't auto-create a log group.

Alternative considered: depends_on

An alternative is to add depends_on = [aws_cloudwatch_log_group.forwarder_log_group] to the Lambda resource (combined with change 1.). This also fixes the Terraform dependency ordering.

I preferred logging_config for two reasons:

1. AWS-level protection. depends_on only fixes the Terraform graph — Lambda can still auto-create the log group if invoked in edge cases (e.g., log group deleted out-of-band, or external triggers firing during a destroy-recreate cycle). logging_config tells the Lambda runtime itself to use the specified log group, preventing auto-creation at the AWS API level.

2. Idiomatic Terraform. The reference to aws_cloudwatch_log_group.forwarder_log_group.name inside logging_config creates an implicit dependency through the resource graph, which is the standard Terraform pattern. Explicit depends_on is recommended only as a last resort since it forces Terraform to defer reading the depended-on resource until apply time.

That said, depends_on is a simpler change with a smaller surface area. If logging_config causes any unforeseen issue during rollout, switching to depends_on is a safe fallback.

Impact on existing deployments

Resource	Effect
Log group	No diff — name resolves to the same string
Lambda	In-place update adding logging_config (not a replacement)
Behavior	log_format = "Text" preserves existing default
Provider	logging_config requires >= 5.32.0; module already requires >= 6.21

Testing

All 54 existing terraform test cases pass.