"aws_appautoscaling_target" showing changes to tags in each plan, because of ignore_changes on 'tags_all'

[FLeonR]

Description

Due to a known issue with tags on the appautoscaling_target resource, as described in the Terraform documentation, this module includes a lifecycle rule to ignore changes to tags_all. This rule is defined in the main.tf file:

resource "aws_appautoscaling_target" "this" {
  count = local.create && var.autoscaling_enabled && !local.is_serverless ? 1 : 0

  max_capacity       = var.autoscaling_max_capacity
  min_capacity       = var.autoscaling_min_capacity
  resource_id        = "cluster:${aws_rds_cluster.this[0].cluster_identifier}"
  scalable_dimension = "rds:cluster:ReadReplicaCount"
  service_namespace  = "rds"

  tags = var.tags

  lifecycle {
    ignore_changes = [
      tags_all,
    ]
  }
}

In my project, I use a combination of local tags and default_tags, and I instantiate the terraform-aws-rds-aurora module from within a custom module. Every time I run a plan, Terraform attempts to apply new tags added since the initial resource creation. However, due to the ignore_changes lifecycle rule, these tags are excluded from tags_all, which leads to the following issues:

• Repeated Plan Outputs: Every Terraform plan shows the same tags to be applied, despite those tags not being included in the remote state due to the lifecycle rule.

• Persisting Change Notifications: Even after applying, the plan still shows the same pending changes in every consecutive run.

Workaround Attempts

I've tried tainting and reapplying the resource, which correctly adds the tags and removes the change notification in future plans. However, this is not a viable solution as the tags are updated frequently, and tainting the resource for every change is impractical given the large number of resources using this module.

Proposed Solution

Would it be possible to make the lifecycle rule for ignore_changes on tags_all optional, or provide a way to remove it entirely? This would allow the tags to propagate to the remote state without requiring repeated tainting and redeployment.

Versions

• Module version [Required]: 9.3.1 (originally used, but tried with latest 9.10.0 and still same issue)

• Terraform version: v1.5.7

• Provider version(s): v5.75.0

Reproduction Code [Required]

module "aurora" {
  source  = "terraform-aws-modules/rds-aurora/aws"
  version = "9.3.1"

  name          = var.cluster_name
  database_name = var.database_name
  
 [...]

  tags = merge(var.tags, { "Name" : "Aurora", "rds-db-id": "rds-id-1" })

}

Steps to reproduce the behavior:

The Terraform plan output shows:

  ~ resource "aws_appautoscaling_target" "this" {
         id          = "cluster:rds-app-development"
      ~ tags         = {
            "Cluster"        = "rds-app-development"
            "Environment"    = "development"
            "Name"           = "Aurora"
          + "rds-db-id"      = "rds-id-1"
        }
        # (8 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Expected behavior

The tags should be updated after applying, or add tags to ignore_changes lifecycle.

[bryantbiggs]

I would just taint the autoscaling target and let it be replaced so it gets the ARN and this issue is resolved properly

[FLeonR]

I would just taint the autoscaling target and let it be replaced so it gets the ARN and this issue is resolved properly

As I explained in the "Workaround Attempts" section, I tried following the taint process, even though my resources already had ARN. However, if I change the tags once again after the autoscaling target got replaced, it will fall under the same situation, where the new tag is not being added to tags_all, so the tag addition is shown in every consecutive plan.

[github-actions]

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

[FLeonR]

I was wondering if any update on this topic. Please refer to my last comment that explains why tainting the resource is not a viable option.