Allow configuring CloudFront cache_behavior precedence

[randomeizer]

Terraform Version

0.6.16

Affected Resource(s)

Please list the resources as a list, for example:

• cloudfront_distribution > cache_behavior

Terraform Configuration Files

# Distro pointing at the specified domain.
resource "aws_cloudfront_distribution" "cloudfront" {
  origin {
    domain_name = "${var.lde_vm_domain_name}"
    origin_id = "lde_vm"
    custom_origin_config {
      http_port = 80
      https_port = 443
      origin_protocol_policy = "match-viewer"
      origin_ssl_protocols = [
        "SSLv3",
        "TLSv1"]
    }
    custom_header = {
      name = "${var.lde_custom_header_name}"
      value = "${var.lde_custom_header_value}"
    }
  }
  aliases = ["${var.public_domain_name}"]
  enabled = true
  comment = "CloudFront Server"
  default_cache_behavior {
    target_origin_id = "lde_vm"
    allowed_methods = [
      "DELETE",
      "GET",
      "HEAD",
      "OPTIONS",
      "PATCH",
      "POST",
      "PUT"]
    cached_methods = [
      "GET",
      "HEAD"]
    compress = true
    smooth_streaming = false
    forwarded_values {
      cookies {
        forward = "all"
      }
      headers = ["Host"]
      query_string = true
    }
    viewer_protocol_policy = "allow-all"
    min_ttl = 0
    default_ttl = 3600
    max_ttl = 31536000
  }

# private digital content cache
  cache_behavior {
    path_pattern = "user/digital_content/download/*"
    target_origin_id = "lde_vm"
    allowed_methods = [
      "GET",
      "HEAD",
      "OPTIONS"]
    cached_methods = [
      "GET",
      "HEAD"]
    compress = true
    smooth_streaming = false
    forwarded_values {
      cookies {
        forward = "none"
      }
      headers = ["Host"]
      query_string = true
    }
    trusted_signers = ["self"]
    viewer_protocol_policy = "allow-all"
    min_ttl = 0
    default_ttl = 3600
    max_ttl = 31536000
  }

  # JS files
  cache_behavior {
    path_pattern = "js/*"
    target_origin_id = "lde_vm"
    allowed_methods = [
      "GET",
      "HEAD",
      "OPTIONS"]
    cached_methods = [
      "GET",
      "HEAD"]
    compress = true
    smooth_streaming = false
    forwarded_values {
      cookies {
        forward = "none"
      }
      headers = ["Host"]
      query_string = true
    }
    viewer_protocol_policy = "allow-all"
    min_ttl = 0
    default_ttl = 3600
    max_ttl = 31536000
  }

  # CSS files
  cache_behavior {
    path_pattern = "css/*"
    target_origin_id = "lde_vm"
    allowed_methods = [
      "GET",
      "HEAD",
      "OPTIONS"]
    cached_methods = [
      "GET",
      "HEAD"]
    compress = true
    smooth_streaming = false
    forwarded_values {
      cookies {
        forward = "none"
      }
      headers = ["Host"]
      query_string = true
    }
    viewer_protocol_policy = "allow-all"
    min_ttl = 0
    default_ttl = 3600
    max_ttl = 31536000
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    iam_certificate_id = "${aws_iam_server_certificate.alias_certificate.id}"
    ssl_support_method = "sni-only"
    minimum_protocol_version = "TLSv1"
  }
  retain_on_delete = false
  price_class = "${var.cloudfront_price_class}"
}```

### Debug Output
N/A

### Panic Output
N/A

### Expected Behavior
We should be able to specify the precedence of multiple cache_behavior definitions. Eg:

```hcl
  cache_behavior {
    precedence: 0
    path_pattern: "js/*"
    ...
  }

  cache_behavior {
    precedence: 1
    path_pattern: "images/*"
  }

Alternately, the order that the cache_behaviour blocks are defined in the config should define the precedence.

Actual Behavior

Cache behaviours are created in random order:

### Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

Nothing special.

References

Not that I'm aware of.

[jen20]

Hi @randomeizer! Thanks for the detailed explanation. The issue here is that the cache behaviours are incorrectly defined as a Set instead of a List, and so there are no ordering guarantees - the code is here. This should be a relatively easy fix luckily - we'll get it sorted out.

[randomeizer]

@jen20 Great! So the precedence order would be defined by the defined order in the .tf?

[jrstarke]

Has there been any progress on this? We happen to use terraform for managing a lot of our AWS infrastructure, and whenever a cloudfront distribution is changed, we have to manually go back to ensure that the behavior order has not surprisingly changed, which doesn't give the team confidence in the tooling.

[jrstarke]

The most recent instantiation of this wackiness, I took changed a distributions iam_certificate_id to an acm_certificate_arn, no changes were performed to the cache behaviors at all. This resulted in reordering my /v1/* behavior above my /v1/stats/* behavior.

[deepybee]

Just hit this issue in 0.8.5, where when you have different bahaviours for longer versions of the same path.

eg desired precendence:

/foo/bar => do something particular for bar
/foo/* => do some default action for everything else

So if /foo/* appears in the order before /foo/bar then bar will not have its custom behaviour applied.

[deepybee]

After some further testing, it appears that if terraform has to update the resource config on an apply, the behaviours can end up out of sequence, even after manually correcting the order of precedence. IF the resource doesn't require any changes then the manual ordering persists over an apply.

[jsvazic]

+1

[nkonopinski]

+1

[nicolasbelanger]

+1

[gdecroux]

+1

[jochavez]

Is there an update on this?

[deepybee]

It's still an issue on 0.8.8 @jochavez. I haven't migrated to 0.9 yet but given the lack of response here and open status of related tickets I'd say it's reasonable to assume there hasn't been a significant change in the status of this issue yet.

[hetile-ssense]

+1

[fmedery]

+1

[TBeijen]

+1
(We're storing aws cli aws cloudfront get-distribution-config result json in repo and manage via aws cli. Far from ideal but luckily cloudfront config doesn't need to change that often)

[vchan2002]

+1 please.... having to go back to the console to change the order after adding another behavior is quite a drag

[BerndWessels]

Is anybody in the terraform community going to address this issue?

It causes serious problems and gives the impression that terraform is not stable or ready for production.

Please fix this, thanks a lot.

@jen20 maybe ?

[ashanir]

Would appreciate if this issue is fixed.
Thanks in advance. :-)

[acejam]

Anyone ever find a fix for this? I'm amazed the linked issue is still open.

[edify42]

Yeah still being griefed by this in 0.9.11

[jen20]

@acejam @edify42 This issue is now over at the provider instead of in the main Terraform repository: hashicorp/terraform-provider-aws#188.

[edify42]

Cheers @jen20.

I noticed that you can manually set the order in the UI and it doesn't affect the state kept in terraform (no changes seen afterwards when you do a terraform plan)

[jen20]

That probably (I haven't looked at any source and am replying on phone) means that the attribute is defined in the Terraform provider as a TypeSet and not a TypeList.

[agouz]

We're using Terraform v0.10.2 and still facing the same issue.

[samnajian]

Any info on how to invalidate cache for objects via terraform as we have in distributions' "Invalidations" ?

[JimiHFord]

Just in case people are still looking for a solution, you'll want to use ordered_cache_behavior for this

[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 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.