Terraform-provider-aws: Differences between aws_waf_web_acl and aws_wafregional_web_acl

[nbrys]

Just for consistency reasons, make aws_waf_web_acl and aws_wafregional_web_acl consistent with each other.

Using rules vs rule makes thinks more complex:
https://www.terraform.io/docs/providers/aws/r/waf_web_acl.html#rules
vs
https://www.terraform.io/docs/providers/aws/r/wafregional_web_acl.html#rule

For both resources, it is possible to attach multiple rules. I suggest changing the parameter from wafregional_web_acl to rules

[chroju]

There are other differences between AWS WAF and AWS WAFRegional. In addition to rule(s) in aws_waf(regional)_web_acl,

• byte_match_tuple(s) in aws_waf(regional)_byte_match_set
• ip_set_descriptor(s) in aws_waf(regional)_ipset
• predicate(s) in aws_waf(regional)_rate_based_rule
• predicate(s) in aws_waf(regional)_rule
• sql_injection_match_tuple(s) in aws_waf(regional)_sql_injection_match_set
• xss_match_tuple(s) in aws_waf(regional)_xss_match_set

I have made PR about aws_waf(regional)_byte_match_set at #5043 .

[chroju]

I have created PRs to fix all differences above.

[craiglink]

it would be great if the resource type was actually the same, i.e. just aws_waf_*
and the determination on whether or not the resources was regional or cloudfront based was done by an attribute - such as "region" which would be set to a valid AWS region or "cloudfront"

[bflad]

Hi folks 👋 Thanks for your interest here. Its certainly an inconvenience the initial implementation of these WAF vs WAF Regional resources contained these naming inconsistencies for configurations. 😖We will be sure to look for these more closely in future implementations.

We previously shepherded through https://github.com/terraform-providers/terraform-provider-aws/pull/5043 which started the process of making the aws_waf_byte_match_set and aws_wafregional_byte_match_set resources consistent. This type of change highlighted the amount of effort involved for not only the code maintainers but also the operator burden for converting older configurations and potential bugs introduced by implementing changes like these. Instead of introducing more burden for the code maintainers and operators with minor benefit in this situation, we will prefer to keep things as they currently exist rather than promise that this may potentially be fixed in the future without a deadline as our focus is on other more impactful features and bug fixes across the rest of the provider.

Relating to the comment above about potentially merging the resources, we feel there are currently decent reasons to keep these implementations separate as it allows us the additional flexibility to implement Regional vs Global features without complicating the schemas and resource logic with conditionals, among other potential complications with having differing attribute outputs.

Apologies again for any frustration here and we will take extra precautions to prevent this situation in the future.

[hashibot[bot]]

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!