Terraform-provider-aws: health_check.matcher not supported for TCP protocol

[hashibot[bot]]

_This issue was originally opened by @SrikanthSoma as hashicorp/terraform#21004. It was migrated here as a result of the provider split. The original body of the issue is below._

---

Issue:

health_check.matcher is not supported for target_groups with TCP protocol

I'm creating NLB with terraform

#Creating target group for search api
resource "aws_alb_target_group" "search_api_target_group" {
  name        = "${var.app_name}-${var.environment}"
  port        = "80"
  vpc_id      = "${data.aws_vpc.vpc_id.id}"
  target_type = "ip"
  protocol    = "TCP"
  stickiness  = []

  health_check {
    port                = "traffic-port"
    protocol            = "TCP"
    healthy_threshold   = 5
    unhealthy_threshold = 5
    timeout             = "${var.health_check_timeout}"
    interval            = "${var.health_check_interval}"
  }

  tags = "${var.search_api_tags}"
}

Terraform don't have a option to set false for health_check matcher for NLB

terraform plan

• aws_alb_target_group.search_api_target_group: arn:aws:elasticloadbalancing:us-west-2:1234567890:targetgroup/search-api-qa/xxxxxxx: health_check.matcher is not supported for target_groups with TCP protocol

I'm on terraform version Terraform v0.11.13

Please have a option to set matcher to disable for TCP protocol

[kitchen]

getting same problem here:

resource "aws_lb_target_group" "rabbit_amqp" {
  name        = "rabbit-amqp"
  target_type = "instance"
  port        = "5672"
  protocol    = "TCP"
  vpc_id      = "${data.terraform_remote_state.s3.vpc_id}"

  health_check {
    protocol = "TCP"
  }
}

plan output:

* aws_lb_target_group.rabbit_amqp: arn:aws:elasticloadbalancing:us-east-1:REDACTED:targetgroup/rabbit-amqp/REDACTED: health_check.matcher is not supported for target_groups with TCP protocol

[kitchen]

ohhhh I think it may be because the protocol type was previously set to HTTP (apparently it defaults to that even on TCP target groups) and that is now getting in the way. I think I'm going to have to nuke the target group and recreate it with TCP from the getgo. NBD. I'll report back.

[kitchen]

can confirm, nuking and recreating with explicit TCP from the start was successful.

Because the target group was in use I couldn't just comment it out so there were some ... acrobatics and a couple of "just run it again" that I could have done cleaner, but that is unrelated.

I think there's still a bug here, for sure, and I might get bored and look at it later, but at least it seems like it can be worked around, at least in my situation.

@SrikanthSoma, does this sound familiar? you might try what I did in the mean time. If I'm not clear enough, I'd be happy to elaborate on what I did, let me know :)

[SrikanthSoma]

@kitchen Thanks for responding yes after the deleting existing TG from AWS Console and recreating TG using terraform worked fine by default it is taking HTTP

[kcd83]

Using a targeted destroy is more likely to find all the dependant resources rather than trying to delete it via the AWS UI or CLI. Not sure if I needed to have exactly the right depends_on (works on my machine...)

 terraform state list | grep aws_lb_target_group
 terraform destroy -target module.pilot1.aws_lb_target_group.target_es

[bhalothia]

I have had the same issue and I could work around it by first creating TG and then the health-checks.

[Raveendran]

@bhalothia, could you kindly help with the TF code snippet on how you create TG and healthcheck separately and linked them finally please

[Raveendran]

Is there a proper solution for this matchers issue? please help

[djdjalas]

I had the same issue and fixed it by deleting the listener then target groups and then plan apply. This is a bug and happens when you have an HTTP health check for a target group and then when you change to TCP you get that error

[marekaf]

can confirm that this is still a problem today :(

[limratechnologies]

As of today, I'm facing this same issue.

[jamescjchan]

Same here. I haven't brought anything up yet so nothing I can delete from according to the solution above. :/

[boxrick]

I am seeing this exact same issue, even with a number of workarounds to force resource re-creation. ( Such as a dynamic name ). It seems to evaluate before it does the resource re-creation and just gives this error.

A manual targeted destroy fixes it, but this isn't ideal.

[maiconbaumx]

Same behaviour. =/