Open sivanovhm opened 2 years ago
Hey @sivanovhm 👋 Thank you for taking the time to raise this. I'm mostly acting in triaging this issue, but I noticed one callout in the aws_cloudfront_distribution
documentation:
CloudFront distributions take about 15 minutes to reach a deployed state after creation or modification.
This note was more talking about deletion after creation/modification, but I'm wondering if you may be hitting some eventual consistency issues here. If you wait 15 minutes or so after running an apply, does the same issue persist?
Hey @justinretzolk, I confirm that even after 15 minutes (waited 60 minutes, just in case), origin shield still shows as enabled on the distribution.
Please note that this is only when a dynamic
block is used.
If used with "normally", and enabled = false
there is not problem with disabling origin shield for the distribution.
The main goal of this issue is to stop the repeated in-place updates that terraform
shows on plan.
I believe that these are most likely 2 separate problems, which a caused by the same thing.
For our case Terraform always resolve default_ttl
and max_ttl
need to update
# aws_cloudfront_distribution.image-handler-cdn will be updated in-place
~ resource "aws_cloudfront_distribution" "image-handler-cdn" {
id = "E3TE5L31UZX1IO"
tags = {}
# (18 unchanged attributes hidden)
~ ordered_cache_behavior {
~ default_ttl = 0 -> 86400
~ max_ttl = 0 -> 31536000
# (11 unchanged attributes hidden)
# (1 unchanged block hidden)
}
# (4 unchanged blocks hidden)
}
I had @tom10271 same issue.
In my case it was my ordered_cache_behavior wich was misconfigured:
If using Managed-CachingDisabled, just set _defaultttl and _maxttl to 0.
My finding is if you are using cache policy, you don't need to specific the ttls at all, just delete them
Any update on that?
My finding is if you are using cache policy, you don't need to specific the ttls at all, just delete them
Unless you prefer to control it... The default TTL for Managed-CachingOptimized is 1 day, which might be too short in some cases.
My finding is if you are using cache policy, you don't need to specific the ttls at all, just delete them
Unless you prefer to control it... The default TTL for Managed-CachingOptimized is 1 day, which might be too short in some cases.
No genius, the point is if you want to set the TTL, you should set it in Cache policy but not in CloudFront Distribution.
No genius, the point is if you want to set the TTL, you should set it in Cache policy but not in CloudFront Distribution.
Why would I create and maintain my own policy if I can just override default values of the AWS managed one? Less resources to maintain, less references to pass between modules, less complexity is definitely worth it.
No genius, the point is if you want to set the TTL, you should set it in Cache policy but not in CloudFront Distribution.
Why would I create and maintain my own policy if I can just override default values of the AWS managed one? Less resources to maintain, less references to pass between modules, less complexity is definitely worth it.
The reason is extremely simple, because there is not input field to set TTL at all if you are editing Cache policy for CloudFront Distribution behaviour. This is how AWS works. You would say Terraform allows so which is wrong but AWS simply does not allow user to set TTL in Distribution level but declare the TTL in Cache Policy only. And yes if you are not happy with the default TTL which is 86400 only, you have to create your own Cache policy.
Community Note
Terraform CLI and Terraform AWS Provider Version
Affected Resource(s)
Terraform Configuration Files
Full aws_cloudfront_distribution configuration
Expected Behavior
performing a
terraform plan
after origin_shield is already added via terraform should not mark aws_cloudfront_distribution for in-place-update. Vice-versa for setting it to false.Actual Behavior
Doing a
terraform plan
after origin_shield is already added via terraform shows aws_cloudfront_distribution to be updated in-place. Vice-versa if it is set to false it still shows it is going to set it to false.Moreover, when we tried to workaround this issue with a dynamic block:
We observed the following:
var.enable_cloudfront_origin_shield = false
,terraform
marks that it is removingorigin_shield
but in fact nothing happens and origin_shield still stays applied (when checked in AWS Console).Steps to Reproduce
to your
aws_cloudfront_distribution
resource for your ALB origin whereenable_cloudfront_origin_shield
is a boolean variable.terraform plan
terraform apply
terraform plan
References