Stickiness support for source_ip broke valid configurations for NLB

[alex1x]

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

0.13.1
3.10

Affected Resource(s)

• aws_lb_target_group

Terraform Configuration Files

Before this was merged, I used blocks like

  stickiness {
    type    = "lb_cookie"
    enabled = false
  }

because due to a previous bug in order to disable stickiness you had to set lb_cookie as your type, even though it wasn't appropriate for the NLB (was the only available one), because the config otherwise complained that type was not set, even though the only desired effect was to disable stickiness.

These configurations worked fine up to 3.10 where they fail with InvalidConfigurationRequest: Stickiness type 'lb_cookie' is not supported for target groups with the TCP protocol, even though enabled is (still) set to false. I think it shouldn't complain about the stickiness type when enabled is set to false.

Expected Behavior

When stickiness block is configured as enabled = false it doesn't complain about the type of stickiness.

Actual Behavior

Terraform fails with Stickiness type 'lb_cookie' is not supported for target groups with the TCP protocol

Steps to Reproduce

Add this block

  stickiness {
    type    = "lb_cookie"
    enabled = false
  }

to a NLB target group.

References

• Add stickiness support for NLB target_groups #15295

[YakDriver]

Thank you for reporting this problem! I can verify that this is an issue. We apologize for the inconvenience and unforeseen breaking change.

As we work through a way forward, I'll provide some context around the problem. There are two competing priorities here. First, we don't want to break existing configurations (your issue). Second, we want to be consistent with AWS. Prior to 3.10, lb_cookie/TCP was an invalid combination and AWS would give the same error you're seeing. However, the AWS provider was adding a layer of protection by not submitting the enabled = false configuration to AWS. This violates the AWS's provider's general principle of maintaining consistency with AWS.

Workarounds

There are two workarounds for affected TCP, UDP, TCP_UDP, and TLS protocol configurations with type = "lb_cookie" and enabled = false:

1. remove the stickiness block, or
2. change the type to source_ip

Broken config in 3.10:

resource "aws_lb_target_group" "test" {
   protocol = "TCP" # or "UDP", "TCP_UDP", or "TLS"
   # other config

   stickiness {
     type    = "lb_cookie"
     enabled = false
   }
 }

Workaround 1:

resource "aws_lb_target_group" "test" {
   protocol = "TCP" # or "UDP", "TCP_UDP", or "TLS"
   # other config
 }

Workaround 2:

resource "aws_lb_target_group" "test" {
   protocol = "TCP" # or "UDP", "TCP_UDP", or "TLS"
   # other config

   stickiness {
     type    = "source_ip"
     enabled = false
   }
 }

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!