Cloudfront multi-tenant distribution: schema-level defaults on `origins` Set-element sub-attributes causes flip-flopping plans

[dsp0x4]

Terraform and AWS Provider Version

Terraform v1.15.1
on darwin_amd64
+ provider registry.terraform.io/hashicorp/aws v6.43.0

Affected Resource(s) or Data Source(s)

• aws_cloudfront_multitenant_distribution

Expected Behavior

The user explicitly set values for one of these origin attributes:

• connection_attempts
• connection_timeout
• custom_origin_config.origin_keepalive_timeout
• custom_origin_config.origin_read_timeout

and the provider preserves that value across applies, without generating a diff on each plan.

Actual Behavior

The user explicitly set values for one of these origin attributes:

• connection_attempts
• connection_timeout
• custom_origin_config.origin_keepalive_timeout
• custom_origin_config.origin_read_timeout

and running a plan after each apply shows a "flip-flopping" configuration between the schema-level default value and the user-set value.

Relevant Error/Panic Output

n/a

Sample Terraform Configuration

Click to expand configuration

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

data "aws_cloudfront_cache_policy" "caching_optimized" {
  name = "Managed-CachingOptimized"
}

resource "aws_cloudfront_multitenant_distribution" "example" {
  comment = "example multi-tenant distribution"
  enabled = false

  origin {
    domain_name = "example.com"
    id          = "example-origin"

    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "https-only"
      origin_ssl_protocols   = ["TLSv1.2"]
      origin_read_timeout    = 120   # any non-default value (30)
    }
  }

  default_cache_behavior {
    target_origin_id       = "example-origin"
    viewer_protocol_policy = "redirect-to-https"
    cache_policy_id        = data.aws_cloudfront_cache_policy.caching_optimized.id

    allowed_methods {
      items          = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
      cached_methods = ["GET", "HEAD"]
    }
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  tenant_config {}

  viewer_certificate {
    cloudfront_default_certificate = true
  }

  tags = {
    Name = "example"
  }
}

Steps to Reproduce

1. Apply the configuration with any non-default value for one of the origin attributes that has schema-level defaults
2. Run a new plan/apply
3. Observe the perpetual plan diff after every apply

Debug Logging

n/a

GenAI / LLM Assisted Development

n/a

Important Facts and References

This is likely related to:

• Value of optional attributes with defaults is mishandled when multiple exist in the same block terraform-plugin-framework#1256
• Multiple computed BoolAttributes with defaults in SetNestedAttribute cause flip-flopping plan on every apply terraform-plugin-framework#867
• Default values within sets cause crashes and/or incorrect behaviour terraform-plugin-framework#783

and the bug was introduced for this resource when origin blocks were (rightfully) converted from List to Set.

Would you like to implement a fix?

Yes

[github-actions]

Community Guidelines

This comment is added to every new Issue to provide quick reference to how the Terraform AWS Provider is maintained. Please review the information below, and thank you for contributing to the community that keeps the provider thriving! 🚀

Voting for Prioritization

• Please vote on this Issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize it.
• Please see our prioritization guide for additional information on how the maintainers handle prioritization.
• Please do not leave +1 or other comments that do not add relevant new information or questions; they generate extra noise for others following the Issue 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.
• For new resources and data sources, use skaff to generate scaffolding with comments detailing common expectations.

[dsp0x4]

Proposed fix

If the AWS API sets a default value on the server side, no default should be set on the provider side. Instead, the argument should only be marked as Optional and Computed.

Drop Default(...) from all the attributes listed above. Keep them as Optional + Computed.

Since CloudFront requires these fields to be present in the UpdateDistribution request body though, even when the user did not set a custom value, we would need to apply defaults at the wire level, with a helper function similar to the existing fixOriginConfigs / fixCacheBehaviors.

I would like to have a feedback from one of the maintainers before implementing the fix, because it's a sort of workaround for the underlying terraform-plugin-framework bug.

Thanks in advance!

[dosubot]

Hey @dsp0x4 👋 Thank you for taking the time to raise this!

This is a confirmed bug pattern in the aws_cloudfront_multitenant_distribution resource. The root cause is the combination of schema-level defaults applied via int32default.StaticInt32() on attributes nested within a SetNestedBlock [1]. Since origin is a set, Terraform matches planned vs. actual elements by comparing the entire object — any mismatch in a single field (due to how defaults interact with the read-back values) causes the set element to become unrecognizable, producing the perpetual diff.

The specific defaults causing this are defined in the resource schema [2]:

• connection_attempts → default 3
• connection_timeout → default 10
• custom_origin_config.origin_keepalive_timeout → default 5
• custom_origin_config.origin_read_timeout → default 30

This follows a pattern seen in several related issues on this resource:

• aws_cloudfront_multitenant_distribution produces inconsistent result after apply with empty origin_path #47649 — a similar set element correlation failure caused by origin_path canonicalization differences between plan and read-back
• Cloudfront muti tenant distriubtion enforcing response_completion_timeout for origins #46306 — response_completion_timeout defaults causing perpetual diffs (fixed in v6.41.0)
• Cloudfront multi-tenant distribution: response_completion_timeout for origins cannot be cleared once set #47732 — follow-up issue where response_completion_timeout cannot be cleared after being set

Per the provider's data handling guidelines, if AWS sets a default on the server side, no default should be set on the provider side — the attribute should instead be marked Optional + Computed without a static default. The fix would involve removing the int32default.StaticInt32() defaults from these attributes within the set element and relying on the API-returned values (via Computed: true) to be authoritative.

Since you've indicated you'd like to implement a fix, that approach — removing the schema-level defaults and keeping the attributes as Optional + Computed — aligns with how similar issues have been resolved across the provider.

Written by @dosu, approved by justinretzolk

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.