aws_lb_target_group & aws_lb ValidationError : not a valid ARN

[ghost]

This issue was originally opened by @micemuni as hashicorp/terraform#18060. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Hello, I am facing the same issue, not a valid target group ARN & not a valid load balancer ARN, I have verified the ARNs are correct from the region. Please let me know how to fix. ?

Error: Error refreshing state: 2 error(s) occurred:

module.ais.aws_lb_target_group.ais_nlb: 1 error(s) occurred:

module.ais.aws_lb_target_group.ais_nlb: aws_lb_target_group.ais_nlb: Error retrieving Target Group: ValidationError: 'arn:aws:elasticloadbalancing:us-east-1:xxxxxxxxxxxxx:targetgroup/xxxxxx-us1-alb-target/ebde06216a600581' is not a valid target group ARN status code: 400, request id: ecfa3f74-5902-11e8-bb87-494cd5f68135

module.ais.aws_lb.ais_nlb: 1 error(s) occurred:

module.ais.aws_lb.ais_nlb: aws_lb.ais_nlb: Error retrieving ALB: ValidationError: 'arn:aws:elasticloadbalancing:us-east-1:xxxxxxxxxxxxxxxxx:loadbalancer/net/xxxxxxx-us1-nlb/f65622b3c4d1bc7c' is not a valid load balancer ARN status code: 400, request id: ed343b93-5902-11e8-adbe-25bc1659d76f

[micemuni]

Hi There, Any update on this.? Why this error is coming.?

[bflad]

@micemuni can you please provide additional information about your situation?

• Are these new resources? Were they just imported? Did this problem just start with existing resources?
• Can you provide the associated Terraform configuration?

The errors you are seeing are coming from the AWS API:

ValidationError: 'arn:aws:elasticloadbalancing:us-east-1:xxxxxxxxxxxxx:targetgroup/xxxxxx-us1-alb-target/ebde06216a600581' is not a valid target group ARN

ValidationError: 'arn:aws:elasticloadbalancing:us-east-1:xxxxxxxxxxxxxxxxx:loadbalancer/net/xxxxxxx-us1-nlb/f65622b3c4d1bc7c' is not a valid load balancer ARN

It likely points to an issue with your Terraform configuration or how you are invoking Terraform to select the wrong AWS region. Double check your provider configuration is set to region = "us-east-1", that the AWS_DEFAULT_REGION environment variable is set to us-east-1, or if you have an AWS configuration file with a configuration profile that the profile set to region=us-east-1.

[mtnygard]

@bflad We are experiencing the same error. Have verified the provider and AWS config files are both set to us-east-1.

Has this problem been seen with other regions?

[bflad]

Has this problem been seen with other regions?

Not that I'm aware of.

Can you please provide additional details about the situation in which this happens? Are these new or existing resources? Are the ARNs hardcoded or coming from another resource/datasource?

[mtnygard]

I wish I could paste in the details, but the errors were from a student in a workshop of mine. We moved him to a different region and were able to proceed. (That may be pure luck & superstition!)

The resources were all new, declared in the .tf files. The ARNs were being pulled from other resources being created in the same plan.

[qnordic]

I'm seeing the same issue here. Unfortunately I do not have the luxury of changing regions as the configs are based around other accounts/resources within the us-east-1 region.

To get around the problem noted above, I migrated to manually creating my load balancers and targets then copying the ARNs from the AWS console. I now see the following error. Can we please get an update on this ASAP, it is blocking work.

* aws_lb_target_group_attachment.https: Error registering targets with target group: ValidationError: 'arn:aws:elasticloadbalancing:us-east-1:xxxxxxxxxxxx:targetgroup/github-enterprise-https/xxxxxxxxxxxxxxxx' must be in ARN format

The code block which defines the resource is here:

resource "aws_lb_target_group_attachment" "https" {
  target_group_arn = "${lookup(var.lb_target_groups, "https.arn")}"
  target_id        = "${aws_instance.ghe-server.id}"
  port             = "${lookup(var.lb_target_groups, "https.port")}"
}

[thedarkwriter]

Hi @bflad (Nice to see you!)

I am also experiencing the same issue. This is in the eu-central-1 region though, not us-east-1. I am standing up stacks with multiple ALBs and an ELB. This error is from a stack that I stood up yesterday. I verified the ARNs are correct in the tfstate file, but I get the same issue as described by prior posters:

aws_lb_target_group.classroom_alb_tg_discovery: aws_lb_target_group.classroom_alb_tg_discovery: Error retrieving Target Group: ValidationError: 'arn:aws:elasticloadbalancing:eu-central-1:AWSACCOUNT:targetgroup/<omitted>DISCOVERY/9a85528048bbed0f' is not a valid target group ARN\n" status code: 400, request id: 3c788ba1-a6e3-11e8-af30-7b9ac7070e31\n' aws_lb.classroom_alb_discovery: aws_lb.classroom_alb_discovery: Error retrieving ALB: ValidationError: 'arn:aws:elasticloadbalancing:eu-central-1:AWSACCOUNT:loadbalancer/app/<omitted>-DISCOVERY/13d73ed7c7b4f985' is not a valid load balancer ARN\n" status code: 400, request id: 3cff95df-a6e3-11e8-b41c-e1371c5b2c6f\n' aws_lb.classroom_alb_master: aws_lb.classroom_alb_master: Error retrieving ALB: ValidationError: 'arn:aws:elasticloadbalancing:eu-central-1:AWSACCOUNT:loadbalancer/app/<omitted>-MASTER/3313fc34b1f6df21' is not a valid load balancer ARN\n" status code: 400, request id: 3d661fd6-a6e3-11e8-bff4-3170ca5ab773\n' aws_lb.classroom_alb_welcome: aws_lb.classroom_alb_welcome: Error retrieving ALB: ValidationError: 'arn:aws:elasticloadbalancing:eu-central-1:AWSACCOUNT:loadbalancer/app/<omitted>-WELCOME/e0f2b4d44c696613' is not a valid load balancer ARN\n" status code: 400, request id: 3d051407-a6e3-11e8-8bb6-3b639bc542e2\n' aws_lb.classroom_alb_gitlab: aws_lb.classroom_alb_gitlab: Error retrieving ALB: ValidationError: 'arn:aws:elasticloadbalancing:eu-central-1:AWSACCOUNT:loadbalancer/app/<omitted>-GITLAB/6edaffefe6394347' is not a valid load balancer ARN\n" status code: 400, request id: 3d5ef3ee-a6e3-11e8-8bb6-3b639bc542e2\n' aws_lb_target_group.classroom_alb_tg_master_8170: aws_lb_target_group.classroom_alb_tg_master_8170: Error retrieving Target Group: ValidationError: 'arn:aws:elasticloadbalancing:eu-central-1:AWSACCOUNT:targetgroup/<omitted>M-1870/eaac9a97957d5bd9' is not a valid target group ARN\n" status code: 400, request id: 3c761a51-a6e3-11e8-bff4-3170ca5ab773\n' aws_lb_target_group.classroom_alb_tg_welcome: aws_lb_target_group.classroom_alb_tg_welcome: Error retrieving Target Group: ValidationError: 'arn:aws:elasticloadbalancing:eu-central-1:AWSACCOUNT:targetgroup/<omitted>WELCOME/489e264f4faaf084' is not a valid target group ARN\n" status code: 400, request id: 3c777a11-a6e3-11e8-b73a-313bc5ad8ac9\n' aws_lb_target_group.classroom_alb_tg_gitlab: aws_lb_target_group.classroom_alb_tg_gitlab: Error retrieving Target Group: ValidationError: 'arn:aws:elasticloadbalancing:eu-central-1:AWSACCOUNT:targetgroup/<omitted>GITLAB/8e3d5f2a088c384d' is not a valid target group ARN\n" status code: 400, request id: 3c844b24-a6e3-11e8-8bb6-3b639bc542e2\n' aws_lb_target_group.classroom_alb_tg_master: aws_lb_target_group.classroom_alb_tg_master: Error retrieving Target Group: ValidationError: 'arn:aws:elasticloadbalancing:eu-central-1:AWSACCOUNT:targetgroup/<omitted>MASTER/be485603d385931b' is not a valid target group ARN\n"

The interesting thing is this error is happening on a docker container running Terraform on Linux yet I've created and destroyed tons of stacks in the last few weeks with the same process.

When I execute the destroy from my Mac, it worked. Both binaries are at 0.11.7

[skyzyx]

I know that AWS has lengthened the ARN IDs for a variety of resource types, changing their pattern. Could something like this be the culprit?

[pixelfields]

Probably the same issue in the eu-west-1 region.

* aws_lb.vault_nlb: aws_lb.vault_nlb: Error retrieving ALB: ValidationError: 'arn:aws:elasticloadbalancing:eu-west-1:<ommited>:loadbalancer/net/vault-elb-prod-1-nlb/<ommited>' is not a valid load balancer ARN
    status code: 400, request id: <ommited>
* aws_lb_target_group.vault_nlb: 1 error(s) occurred:

* aws_lb_target_group.vault_nlb: aws_lb_target_group.vault_nlb: Error retrieving Target Group: ValidationError: 'arn:aws:elasticloadbalancing:eu-west-1:<ommited>:targetgroup/vault-prod-1-nlb/<ommited>' is not a valid target group ARN
    status code: 400, request id: <ommited>

[dtelaroli]

For me the problem was the AWS credential, because I had used two profiles. I had changed the provider to correct profile and worked fine.

[default]
aws_access_key_id = <secret>
aws_secret_access_key = <secret>
[my_profile]
aws_access_key_id = <secret>
aws_secret_access_key = <secret>

provider "aws" {
  region  = "${var.region}"
  profile = "my_profile"
}

[gavD]

I had this problem with code like the above:

  target_group_arn = "${lookup(var.lb_target_groups, "https.arn")}"
  target_id        = "${aws_instance.ghe-server.id}"

I switched target_id to use an arn instead and it worked

  target_group_arn = "${lookup(var.lb_target_groups, "https.arn")}"
  target_id        = "${aws_instance.ghe-server.arn}" // here

so, for a lambda, target_id should be the arn of the lambda, not the id

[ahaynssen]

Just chiming in... This happened to me when i was using vars in my provider definition. I've noticed lots of inconsistencies if my provider has things like region = var.region in this case I hardcoded the region, same error. I was using assume_role in the provider and the role_arn was in a module that had an account_id var in the arn. When I replaced the assume_role arn with a hardcoded account number everything worked as expected.

[GNSunny]

I followed @ahaynssen @gavD @dtelaroli all three approaches but still, I receive the same errors again and again.

Error: Error retrieving Target Group: ValidationError: 'arn:aws:elasticloadbalancing:eu-west-1:01234567890:targetgroup/dev1-web-to-http/5e7a9da3057bc30c' is not a valid target group ARN
        status code: 400, request id: 62d7fc52-0636-4c79-a43e-ab2444e8a29d

/// etc
[2020/09/15 12:37:58] Plan complete

[ppapishe]

I am facing the same issue as well. I checked the ARNs in both the remote state and the console and they seems to be matching. any workaround is appreciated.

[mviklicky]

I was facing exactly the same issue.. And we were able to fix it.

What was the root cause in my case? Bad config in ~/.aws/credentials or we can also say in providers.tf tldr; aws provider was working with wrong AWS account

In my case, I had the correct state, but I was looking for the real infrastructure in the wrong AWS account (via aws provider). I am using role assume in the s3 backend and data.terraform_remote_state. But I was missing that in aws provider. (most probably some engineer before me had different configuration in ~/.aws/credentials, and aws provider is using this config.)

Summary: If you are assuming roles or something similar in providers.tf, be careful and ensure that your aws provider, s3 backend, data.terraform_remote_state, etc. are working with the desired (most probably the same one) AWS account.

[jeffreymlewis]

I ran into this today. I was trying to use the aws_lb data source to gather metadata regarding a Network Load Balancer in a different aws account. My goal was to gather metadata (dns_name and zone_id) about the NLB, so I could create a Route53 alias for the load balancer in a different account.

Perhaps Amazon doesn't allow lookup of LBs metadata unless you're auth'ed to the account in which the LB resides?

[ashanti88]

I had the same issue, I've been using AWS SSO to manage my profiles, but after reading this blog I figured that it should be related to my region. So I added this flag "--region us-east-1"
" aws elbv2 describe-target-health \n --target-group-arn YOUR_ARN --region us-east-1" and it helped.

[adrimus]

Hi I am new to Terraform, I don't understand what these errors mean. These are new resources I am creating. I have been following Terraform getting started course on Pluralsight. The only thing I've done different is that I destroyed everything to begin with and added extra resources. In the demo the tutor has some resources running already and is just updating. Not sure if that makes a difference.

╷
│ Error: retrieving ALB (arn:aws:elasticloadbalancing:us-east-1:927589092144:loadbalancer/app/globo-web-alb/e138ebc8e894ac7b): ValidationError: 'arn:aws:elasticloadbalancing:us-east-1:927589092144:loadbalancer/app/globo-web-alb/e138ebc8e894ac7b' is not a valid load balancer ARN
│       status code: 400, request id: 24cb14ac-72cf-476a-b60b-df8d1c603ba7
│
│   with aws_lb.nginx,
│   on loadbalancer.tf line 5, in resource "aws_lb" "nginx":
│    5: resource "aws_lb" "nginx" {
│
╵
╷
│ Error: reading ELBv2 Target Group (arn:aws:elasticloadbalancing:us-east-1:927589092144:targetgroup/nginx-alb-tg/b133de1b7c64a11f): ValidationError: 'arn:aws:elasticloadbalancing:us-east-1:927589092144:targetgroup/nginx-alb-tg/b133de1b7c64a11f' is not a valid target group ARN
│       status code: 400, request id: 377e4256-ab21-4770-a3c1-589b4546ff25
│
│   with aws_lb_target_group.nginx,
│   on loadbalancer.tf line 23, in resource "aws_lb_target_group" "nginx":
│   23: resource "aws_lb_target_group" "nginx" {
│
╵

Here is the tf for load balancer:

## aws_elb_service_account
data "aws_elb_service_account" "root" {}

## aws_lb
resource "aws_lb" "nginx" {
  name               = "globo-web-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = [aws_subnet.subnet1.id, aws_subnet.subnet2.id]

  enable_deletion_protection = false

  access_logs {
    bucket  = aws_s3_bucket.web_bucket.bucket
    prefix  = "alb-logs"
    enabled = true
  }

  tags = local.common_tags
}

resource "aws_lb_target_group" "nginx" {
  name     = "nginx-alb-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.vpc.id

  tags = local.common_tags
}

resource "aws_lb_listener" "nginx" {
  load_balancer_arn = aws_lb.nginx.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.nginx.arn
  }

  tags = local.common_tags
}

resource "aws_lb_target_group_attachment" "nginx1" {
  target_group_arn = aws_lb_target_group.nginx.arn
  target_id        = aws_instance.nginx1.id
  port             = 80
}

resource "aws_lb_target_group_attachment" "nginx2" {
  target_group_arn = aws_lb_target_group.nginx.arn
  target_id        = aws_instance.nginx2.id
  port             = 80
}

[leslie-alldridge]

Ran into the same issue, I swapped aws_lb_listener_rule to aws_alb_listener_rule so it destroyed and re-created my resources (Previously, did a terraform state rm & terraform import for once listener and it failed. Perhaps I needed to nuke both? idk.).

Also changed the output from id to arn as mentioned here https://github.com/hashicorp/terraform-provider-aws/issues/4552#issuecomment-594005624

Works great now.

Edit: Changed the names back to aws_lb_listener_rule (it can be used interchangeably with aws_alb_listener_rule) and terraform created 2 and destroyed 2 resources without error. So it looks like my state might've been a bit weird and recreating new resources was the fix.

Edit2: After doing a code deploy I'm now stuck with the original problem :( terraform state has saved stickiness information and running a plan apply will return an error 😭

[joey1089]

I got the same issue for a existing working code, I did change some code after looking at different solutions mentioned here but nothing worked for me. last thing came up to mind is delete all temp files created by terraform. as this is my personal project, I can try this out by just keeping all my files and delete all run time related terraform files like terraform.tfstate etc. restarted my editors and ran terraform init again then terraform plan. it worked out for me, no issues. hope this helps someone out.

[sethWines]

I had this issue as well. A co-worker helped me realize it was because I switched to a different AWS account while my terraform.tfstate was referencing resources that didn't get destroyed from another account. I re-ran terraform destroy in the first account and then re-ran terraform apply in the second account and the issue was resolved.

Basically I forgot to destroy the tracked resources before changing accounts. We are in the testing phase so we aren't worried about separate repos or branches for multiple accounts so hopefully this helps someone.

[grandmaestr]

Ran into the a similar issue. In my case, I had applied the config using:

terraform apply -var-file=../vars/shared_terraform.tfvars

then tried to refresh using:

terraform refresh

which resulted in the status 400 error because I hadn't specified the path to the terraform.tfvars file. The correct command would be:

terraform refresh -var-file=../vars/shared_terraform.tfvars

Lesson learnt - if you specify a path to your tfvars file when you plan or apply your config, you'll need to include it in subsequent operations. I guess this is rookie mistake (should have read the docs more closely) but I rarely use the -var-file option so I had to learn the hard way :).

[b1singh]

After delete the tfsatte file the same issue is resolved.