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.

from terraform-provider-aws.

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 😄

from terraform-provider-aws.

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())
    }
  }

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.

from terraform-provider-aws.

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 :)

from terraform-provider-aws.

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.

from terraform-provider-aws.

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

from terraform-provider-aws.

from terraform-provider-aws.