[Bug]: Inconsistent Application of Dynamic Default Tags to Resources

[jmanno]

Terraform Core Version

1.7.3

AWS Provider Version

5.35.0

Affected Resource(s)

All resources with tags_all attribute

Expected Behavior

All resources should have the tags_all attribute computed with dynamic default tags applied, reflecting global tagging configurations.

Actual Behavior

The tags_all attribute is not consistently computed across all resources, indicating a failure to apply dynamic default tags as expected.

This is another example of the inconsistent behavior

Relevant Error/Panic Output Snippet

❯ terraform plan
aws_vpc.example: Refreshing state... [id=vpc-####]
aws_subnet.example: Refreshing state... [id=subnet-####]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated
with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_subnet.example will be updated in-place
  ~ resource "aws_subnet" "example" {
        id                                             = "subnet-####"
      ~ tags                                           = {
          - "ManagedBy" = "Terraform" -> null
            "Name"      = "my-subnet-resource"
        }
      ~ tags_all                                       = {
          - "ManagedBy" = "Terraform" -> null
            # (1 unchanged element hidden)
        }
        # (15 unchanged attributes hidden)
    }

  # aws_vpc.example will be updated in-place
  ~ resource "aws_vpc" "example" {
        id                                   = "vpc-####"
      ~ tags                                 = {
          - "ManagedBy" = "Terraform" -> null
            "Name"      = "my-vpc-resource"
        }
      ~ tags_all                             = {
          - "ManagedBy" = "Terraform" -> null
            # (1 unchanged element hidden)
        }
        # (14 unchanged attributes hidden)
    }
Plan: 0 to add, 2 to change, 0 to destroy.

Terraform Configuration Files

provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
        ManagedBy = "Terraform"

        # To reproduce the bug:
        # 1) apply the plan generated by this file
        # 2) uncomment the following line and examine the new plan
        # CreatedAt = formatdate("YYYY-MM-DD", timestamp())
      }
  }
}

terraform {
  required_version = "1.7.3"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.35.0"
    }
  }

}

resource "aws_vpc" "example" {
  cidr_block = "10.1.0.0/16"
  tags = {
    Name = "my-vpc-resource"
  }
}

resource "aws_subnet" "example" {
  cidr_block = "10.1.1.0/24"
  vpc_id     = aws_vpc.example.id
  tags = {
    Name = "my-subnet-resource"
  }
}

Steps to Reproduce

To reproduce the bug:

    # 1) apply the plan generated by this file
    # 2) uncomment the following line and examine the new plan
    # CreatedAt = formatdate("YYYY-MM-DD", timestamp())

Debug Output

No response

Panic Output

No response

Important Factoids

We examined a json version of a plan and confirm that terraform is not computing the tags_all attribute for some resources. Other resources do have the tags_all attribute.

References

No response

Would you like to implement a fix?

None

[github-actions[bot]]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• 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.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[fcastagninizoom]

I wanted to add a note regarding impact to bring attention to this issue.

We have implemented dynamic global tags to ensure all our infrastructure resources adhere to our company's cloud tagging policy, which mandates certain tags for governance and operational efficiency. This setup has been operational and compliant with our policies for several months, verified through automated checks during our code review process.

Recently, we encountered this issue where the tags_all attribute is not consistently rendered across all resources, leading to a failure in our automated compliance checks. This inconsistency prevents us from successfully deploying our infrastructure due to strict tag enforcement policies on our cloud environment, significantly impacting our deployment workflows.

Some accounts have AWS SCP rules in place to stop changes that are missing the tags required.

This situation has become a critical blocker for us, as we rely on the dynamic global tags functionality to meet compliance requirements. The sudden surfacing of this issue without any changes in our configuration or approach has left us seeking an urgent resolution.

I am hopeful a fix can be prioritized 😄

[jar-b]

Hello - #30801 documents a similar issue, and this comment describes why default_tags behave this way with the provided configuration (computed values, such the result of the timestamp() function, are not supported due to limitations on how the provider is configured).

Assuming the precise apply time is not a requirement given the formatted value only includes the date portion, the plantimestamp function could provide the desired result. This function is available in Terraform 1.5 and later. As the name suggests, its value reflects the timestamp of the plan operation, which means that during apply the value is known and avoids inclusion of a computed (unknown) value in the default_tags block.

I was able to reproduce the issue with the original configuration, and confirm that changing the following resulted in an apply, followed by a plan with no changes.

  default_tags {
    tags = {
      ManagedBy = "Terraform"
      CreatedAt = formatdate("YYYY-MM-DD", plantimestamp())
    }
  }

---

Show/Hide full Terraform configuration

```hcl provider "aws" { default_tags { tags = { ManagedBy = "Terraform" CreatedAt = formatdate("YYYY-MM-DD", plantimestamp()) } } } terraform { required_version = "1.7.3" required_providers { aws = { source = "hashicorp/aws" version = "5.35.0" } } } resource "aws_vpc" "example" { cidr_block = "10.1.0.0/16" tags = { Name = "my-vpc-resource" } } resource "aws_subnet" "example" { cidr_block = "10.1.1.0/24" vpc_id = aws_vpc.example.id tags = { Name = "my-subnet-resource" } } ```

% terraform apply -auto-approve

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
  + create

Terraform will perform the following actions:

  # aws_subnet.example will be created
  + resource "aws_subnet" "example" {
<snip>
      + tags                                           = {
          + "Name" = "my-subnet-resource"
        }
      + tags_all                                       = {
          + "CreatedAt" = "2024-02-15"
          + "ManagedBy" = "Terraform"
          + "Name"      = "my-subnet-resource"
        }
      + vpc_id                                         = (known after apply)
    }

  # aws_vpc.example will be created
  + resource "aws_vpc" "example" {
<snip>
      + tags                                 = {
          + "Name" = "my-vpc-resource"
        }
      + tags_all                             = {
          + "CreatedAt" = "2024-02-15"
          + "ManagedBy" = "Terraform"
          + "Name"      = "my-vpc-resource"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.
aws_vpc.example: Creating...
aws_vpc.example: Creation complete after 1s [id=vpc-00d35960d803dcb4e]
aws_subnet.example: Creating...
aws_subnet.example: Creation complete after 1s [id=subnet-00e8db1d2863519e1]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

% terraform plan
aws_vpc.example: Refreshing state... [id=vpc-00d35960d803dcb4e]
aws_subnet.example: Refreshing state... [id=subnet-00e8db1d2863519e1]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are
needed.

% terraform -v
Terraform v1.7.3
on darwin_arm64
+ provider registry.terraform.io/hashicorp/aws v5.35.0

Please let me know if I misunderstood any part of the original report given the minimal reproduction may not be reflective of the full configuration included in the screenshots. If this adjustment works for your use case, we can go ahead and close this issue out.

[fcastagninizoom]

Thank you for the update, @jar-b!

We reviewed the comment you referenced (link to comment), but it seems there's been a misunderstanding regarding its applicability to our current issue.

The comment suggests, The following configuration will be possible in v5.0.0., given that our environment is running on version v5.35.0, we naturally assumed support for dynamic values was included. However, it appears this assumption may not align with the actual functionality available in our version.

We have been experiencing a similar behavior with tags_all being missing in the plan if we add an empty tag, exactly what is being reported in this other issue, particularly interesting is this comment.

This ticket can be closed as a duplicate, but it will be really nice to hear about the plans to address the tagging issues that @johnsonaj has mentioned.

Thanks again :)

[jar-b]

Hey @fcastagninizoom - thanks for your feedback!

If your configuration and issue varies significantly from this one (computed tags such as a timestamp in the default_tags block), it may be worth opening a separate issue with a minimal configuration so we can better assess how to help. If it turns out to be the same root cause as another issue, we can always link and close it as necessary.

[justinretzolk]

Since it looks like this the original issue here has been addressed, and we haven't heard back, closing.

[github-actions[bot]]

[!WARNING] This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.

Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.

[github-actions[bot]]

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.