Unable to remove forwarded_values on aws_cloudfront_distribution and instead use cache policy

[billy-reilly]

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

Terraform CLI and Terraform AWS Provider Version

Terraform v0.13.2
+ provider registry.terraform.io/hashicorp/aws v3.28.0

I've also tested with TF v0.12.20

Affected Resource(s)

aws_cloudfront_distribution

Terraform Configuration Files

config 1:

provider "aws" {
  region  = "eu-west-2"
  version = "~> 3.28"
}

resource "aws_s3_bucket" "website_bucket" {
  bucket = "billy-test-bucket"
  acl    = "public-read"
}

resource "aws_cloudfront_distribution" "web_distribution" {
  origin {
    domain_name = aws_s3_bucket.website_bucket.bucket_regional_domain_name
    origin_id   = "s3_origin"
  }

  enabled             = true
  default_root_object = "index.html"

  default_cache_behavior {
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]
    target_origin_id       = "s3_origin"

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

config 2:

provider "aws" {
  region  = "eu-west-2"
  version = "~> 3.28"
}

resource "aws_s3_bucket" "website_bucket" {
  bucket = "billy-test-bucket"
  acl    = "public-read"
}

resource "aws_cloudfront_cache_policy" "default_cache_policy" {
  name    = "default-cache-policy"
  min_ttl = 0

  parameters_in_cache_key_and_forwarded_to_origin {
    cookies_config {
      cookie_behavior = "none"
    }

    headers_config {
      header_behavior = "none"
    }

    query_strings_config {
      query_string_behavior = "none"
    }

    enable_accept_encoding_brotli = true
    enable_accept_encoding_gzip   = true
  }
}

resource "aws_cloudfront_distribution" "web_distribution" {
  origin {
    domain_name = aws_s3_bucket.website_bucket.bucket_regional_domain_name
    origin_id   = "s3_origin"
  }

  enabled             = true
  default_root_object = "index.html"

  default_cache_behavior {
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]
    target_origin_id       = "s3_origin"

    cache_policy_id = aws_cloudfront_cache_policy.default_cache_policy.id
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

Expected Behavior

If you apply the first config and then apply the second, it should remove the forwarded_values from the distribution's default_cache_behavior and apply the new cache_policy_id successfully

Actual Behavior

I can see from the plan step that it does not try to remove the forwarded_values:

      ~ default_cache_behavior {
            allowed_methods        = [
                "GET",
                "HEAD",
            ]
          + cache_policy_id        = "b1b409d5-0104-4175-b4e3-c321e694c749"
            cached_methods         = [
                "GET",
                "HEAD",
            ]
            compress               = false
            default_ttl            = 0
            max_ttl                = 0
            min_ttl                = 0
            smooth_streaming       = false
            target_origin_id       = "s3_origin"
            trusted_signers        = []
            viewer_protocol_policy = "redirect-to-https"

            forwarded_values {
                headers                 = []
                query_string            = false
                query_string_cache_keys = []

                cookies {
                    forward           = "none"
                    whitelisted_names = []
                }
            }
        }

and so it errors with:

Error: error updating CloudFront Distribution (EL8S34HS6LFV0): InvalidArgument: The parameter ForwardedValues cannot be used when a cache policy is associated to the cache behavior.
	status code: 400, request id: b2b4e098-b5fa-4185-85dd-c7bf442ee9bc

Steps to Reproduce

1. terraform apply with config 1 above
2. terraform apply with config 2 above

References

• CF cache policies were introduced last week: CloudFront Cache Policy #17336

[woodhull]

I had this issue as well. Was able to work around it for now by making the change in the AWS console and then applying with terraform to match.

[cgriego]

Looks like the ttl items suffer from a similar issue.

[pen-pal]

Is there any update on it yet?

[dgdevops]

Same issue here, any news?

[billy-reilly]

I might have some time to try working on this next week, but I've not contributed to this repo before and am completely new to go so would really appreciate some guidance

Does anyone know if attributes not being removed from resources is a common issue with the provider? Are there any examples of PRs fixing bugs like this for other resources?

Also hey @bill-rich and @gdavison, just wanted to reach out because I saw you worked on adding the cache policy (#17336) - do you happen to have any ideas on what might need to be changed to resolve this issue?

Thanks 🙂

[bill-rich]

@billy-reilly The reason the forwarded_values are conflicting is because they are set as Computed. That makes it so that when forwarded_values is removed in the 2nd config, the existing values are still used. I don't remember right off why Computed was needed in that case.

One way to work around this for now, should be to set forwarded_values to an empty block. That way it will be set in the config to be empty rather than being left out and filled in with the values from the state.

[billy-reilly]

@bill-rich cheers do you mean something like this?

forwarded_values {}

I'm getting a validation error:

Error: Missing required argument

  on main.tf line 50, in resource "aws_cloudfront_distribution" "web_distribution":
  50:     forwarded_values {}

The argument "query_string" is required, but no definition was found.

[bill-rich]

That was the thought, but I forgot there were Required values in forwarded_values. I'll take a closer look at this in a day or so to give you a better idea of what I think the best way to handle this would be.

[billy-reilly]

@bill-rich amazing thank you!

[bill-rich]

@billy-reilly I took a look, and the simplest solution seems to be to just make forwarded_values not Computed. I did some testing with that change and everything looks good, so I got a PR open to make the change.

[billy-reilly]

Ah sweet! Thanks @bill-rich 🙌

[billy-reilly]

@bill-rich do you know if there's any chance that #18042 might be included in v3.33?

[ghost]

This has been released in version 3.34.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 for triage. Thanks!

[esteban1983cl]

Hi everyone this issue was re-introduced in 3.35.0

Error: Missing required argument
  on cencommerce-postventa-customer.tf line 172, in resource "aws_cloudfront_distribution" "customer":
 172:     forwarded_values {}
The argument "query_string" is required, but no definition was found.

[billy-reilly]

hey @esteban1983cl instead of having an empty forwarded_values block try removing forwarded_values altogether 🙂

Above we tried having an empty forwarded_values block just to see if that would work around the original issue but it's not valid. The fix that was released allows you to remove forwarded_values from your config

[harmoniqpunk]

This problem is stil persistent in 3.36. Doesn't work neither removing the block, nor passing an empty block.

[sebge2]

I have the same issue with 3.36.0:

Like suggested before, I tried:

• an empty forwarded_values block
• do it myself on the UI and then apply

[AnzeKovac]

I can confirm that issue returned with 3.36.0.

[billy-reilly]

I've just tested with 3.36.0 using the config I shared above and it worked fine

$ terraform --version
Terraform v0.13.2
+ provider registry.terraform.io/hashicorp/aws v3.36.0

Your version of Terraform is out of date! The latest version
is 0.15.0. You can update by downloading from https://www.terraform.io/downloads.html

$ terraform apply
[...]
      ~ default_cache_behavior {
            allowed_methods        = [
                "GET",
                "HEAD",
            ]
          + cache_policy_id        = (known after apply)
            cached_methods         = [
                "GET",
                "HEAD",
            ]
            compress               = false
            default_ttl            = 0
            max_ttl                = 0
            min_ttl                = 0
            smooth_streaming       = false
            target_origin_id       = "s3_origin"
            trusted_signers        = []
            viewer_protocol_policy = "redirect-to-https"

          - forwarded_values {
              - headers                 = [] -> null
              - query_string            = false -> null
              - query_string_cache_keys = [] -> null

              - cookies {
                  - forward           = "none" -> null
                  - whitelisted_names = [] -> null
                }
            }
        }
[...]

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

@georgepoenaru @sebge2 @AnzeKovac maybe one of you could create a new issue and share your config?

[sebge2]

Done #19041

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!