Network Load Balancer stickiness not configurable with Terraform (but supported by AWS)

[anderscarling]

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 Version

Terraform v0.12.24
provider.aws v2.53.0

Affected Resource(s)

• aws_lb_target_group

Terraform Configuration Files

resource "aws_lb" "lb" {
  name = "lb"
  load_balancer_type = "network"
}

resource "aws_lb_listener" "lb-listener" {
  load_balancer_arn = aws_lb.lb.arn
  protocol = "UDP"
  port     = 1234

  default_action {
    target_group_arn = aws_lb_target_group.lb-target.arn
    type             = "forward"
  }
}

resource "aws_lb_target_group" "lb-target" {
  protocol = "UDP"
  port     = 1234
  stickiness {
    enabled = true
    type = "source_ip"
  }
}

Expected Behavior

Terraform should be able to configure network load balancer with stickiness enabled, as described in AWS documentation:

• https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#sticky-sessions
• https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_TargetGroupAttribute.html

Actual Behavior

Terraform claims stickiness is only supported for Application Load Balancers, and only using type = "lb_cookie". This is the documented behavior of the terraform aws provider, but is not true as the feature is supported by AWS.

References

These issues are related, as the fix will probably fix them to, but they do not describe the same issue:

• Error: Network Load Balancers do not support Stickiness #9093
• aws_lb_target_group with aws_lb (unable to disable stickiness not supported in NLB) #10494

[anderscarling]

I had a look at the code and just adding support for the options is probably quite straightforward, but it seems like there is currently some special cases around TCP load balancers with stickiness enabled. Basically, the stickiness configuration block is ignored for TCP load balancers.

Those special cases will probably need to be handled really carefully not to break existing configurations, so I don't really feel confident going ahead and trying to implement this. At least not without some guidance about how the maintainers would like them handled.

[joshnuna]

@anderscarling hey since you mention this is pretty straightforward, why don't you go ahead and implement this and make a pr, then let the maintainers review the PR with the guidance they might provide about handling those edge cases?

[anderscarling]

@joshnuna No promises, but I'll try to find time to do that. :)

[brianabston001]

Any news on this.. I am trying to deploy new NLBs and this is stopping me

[anderscarling]

Sorry, I've not been able to find any time yet - and honestly I think it will be a while before I do.

The workaround we're using is basically setting up the target group manually using the awscli (that allows us to keep a record of the command using to set it up as a comment in the terraform config) - and referencing it using a data "aws_lb_target_group" to connect it to instances (using resource "aws_lb_target_group_attachment") and load balancers listeners (using resource "aws_lb_listener") .

As the target group only relies on the VPC being available and you can connected the instances and listeners to it using terraform, it's not too bad. Setting it all up using terraform would obviously be better though.

To create the target group and configure stickiness, we use something like this (this exact script has not been tested though, so use caution):

TARGET_GROUP_NAME="my-target-group"
aws elbv2 create-target-group \
  --name "$TARGET_GROUP_NAME" \
  --protocol UDP \
  --port 1234 \
  --vpc-id vpc-NNNNNN \
  --health-check-protocol HTTP \
  --health-check-port 80 \
  --health-check-enabled \
  --health-check-interval-seconds 10 \
  --health-check-timeout-seconds 6 \
  --health-check-path "/probe" \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 2 \
  --matcher '{"HttpCode": "200-399"}' \
  --target-type instance
aws elbv2 modify-target-group-attributes \
  --target-group-arn "$(aws elbv2 describe-target-groups | jq -r ".TargetGroups[] | select(.TargetGroupName == \"$TARGET_GROUP_NAME\").TargetGroupArn")" \
  --attributes '[{"Key": "stickiness.enabled", "Value": "true"}, {"Key": "stickiness.type", "Value": "source_ip"}]'

[DonBower]

When I define an "aws_lb_target_group" resource with "TLS" protocol, and do not define a "stickiness" block, I can attach it to a Network Load Balancer.
if I add the stickiness block, and run a plan I get:

     ~ stickiness {
          ~ cookie_duration = 0 -> 86400
            enabled         = false
          ~ type            = "source_ip" -> "lb_cookie"
        }

If I define it thus:

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

I get error that cookie_duration cannot be 0 and type is not in the set [lb_cookie].
Neither can I supply the value "null" to duration or type.

We must be able to create a TLS target_group, and set the values appropriately.

Clearly TF is more restrictive than AWS in this case.

[kty1965]

Does anyone solve this problem?
I have same problem.

Error: Error modifying Target Group Attributes: InvalidConfigurationRequest: The provided target group attribute is not supported
	status code: 400, request id: d8bae57f-1420-4430-beb7-22a32015c4df

[YakDriver]

I'm closing this as this was fixed in #15295, v.3.10.0. If you continue to have related issues, please let us know with a new issue.

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!