aws_lb_target_group_attachment import should be allowed using terraform import commands

[nnarasim010]

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

Description

aws_lb_target_group_attachment resource cannot be imported using terraform import commands.
This is still true as of AWS Provider version 4.27.0 and should be included as part of normal import.

New or Affected Resource(s)

aws_lb_target_group_attachment
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb_target_group_attachment

[nwalters512]

This would be especially useful with the introduction of the declarative import block: https://www.hashicorp.com/blog/terraform-1-5-brings-config-driven-import-and-checks. Being able to bring a target group attachment under Terraform's control and use terraform plan to ensure that no changes would be made would be highly valuable!

[Shocktrooper]

Is the only way to solve this in the meantime is to delete the current attachment and let terraform take over? This is not ideal as there would be a service interruption.

[davidqc]

Is the only way to solve this in the meantime is to delete the current attachment and let terraform take over? This is not ideal as there would be a service interruption.

I've come across this when renaming load balancer resources.
The code wanted to destroy and recreate aws_lb_target_group_attachment resources which were already in place which felt a little dangerous.
So I removed the old name from the state (leaving the target group association in place in AWS), then allowed terraform to create the attachment which was already in place, and it appeared to seamlessly take over the the existing attachment - but I'm less than confident this is by design.

[Shocktrooper]

I just tested applying over an already attached set of instances. Since the attachment is more of an action it just works even if the current attachment is never deleted. This should be noted in the documentation at least. There is no need for an import with the way it currently acts as long as it does not change

[bcsgh]

Something that also seems to work is manually editing the the .tfstate file.

• Copy an existing aws_lb_target_group_attachment
• update .name, '.insatances[*].attributes.target_group_arn', etc. to mach .tf.
• pick a new .insatances[*].attributes.id, the pattern seems to be ${targetgroup.arn}-${some date/time derived nonce}
• prey you got it right
• terrafrom refresh

I have a suspicion that picking that "date/time derived nonce" might be important, e.g. if terraform is using the creation order to help match real world attachments to tf resources.

If you are using a remote state, this might be best to do in a scratch local project and then, once it works, use terraform state mv to move it between states.

Disclaimer: I've done this exactly once and beyond that have zero idea how safe or reliable it is. For all I know it could bankrupt your company and pierce the corporate veil.

Note: the fact this ever works at all basically proves that an import can be implemented and the only thing preventing it would be something like an "ideological" consideration about the end user not being able to derive the correct id that terraform would use to figure out which attachment is being talked about and not wanting to ask them to "just pick something unique".

[yves-vogl]

I'm thinking out loud…

When looking into the state for an external IP address target the schema looks like this.

{
  "module": "module.lb",
  "mode": "managed",
  "type": "aws_lb_target_group_attachment",
  "name": "example",
  "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
  "instances": [       
    {
      "index_key": "key",
      "schema_version": 0,
      "attributes": {
        "availability_zone": "region-x-az-1",
        "id": "arn:aws:elasticloadbalancing:region-x:1234567890:targetgroup/name/id",
        "port": 443,
        "target_group_arn": "arn:aws:elasticloadbalancing:region-x:1234567890:targetgroup/name/hash",
        "target_id": "1.2.3.4"
      }
    }
  ]
}

So that's the schema:

schema.Resource{
	CreateWithoutTimeout: resourceAttachmentCreate,
	ReadWithoutTimeout:   resourceAttachmentRead,
	DeleteWithoutTimeout: resourceAttachmentDelete,

	Schema: map[string]*schema.Schema{
		names.AttrAvailabilityZone: {
			Type:     schema.TypeString,
			ForceNew: true,
			Optional: true,
		},
		"target_group_arn": {
			Type:     schema.TypeString,
			ForceNew: true,
			Required: true,
		},
		"target_id": {
			Type:     schema.TypeString,
			ForceNew: true,
			Required: true,
		},
		names.AttrPort: {
			Type:     schema.TypeInt,
			ForceNew: true,
			Optional: true,
		},
	},
}

The internal id consists of <target_group_arn>-<target_id> so importing arn:aws:elasticloadbalancing:region-x:1234567890:targetgroup/name/id should work by splitting the id path at the hyphen.

That could probably lead to the following importer resources:

func resourceAwsLbTargetGroupAttachment() *schema.Resource {
    return &schema.Resource{
        CreateContext: resourceAwsLbTargetGroupAttachmentCreate,
        ReadContext:   resourceAwsLbTargetGroupAttachmentRead,
        DeleteContext: resourceAwsLbTargetGroupAttachmentDelete,

        Importer: &schema.ResourceImporter{
            StateContext: resourceAwsLbTargetGroupAttachmentImport,
        },

        Schema: map[string]*schema.Schema{
            "target_group_arn": {
                Type:     schema.TypeString,
                Required: true,
                ForceNew: true,
            },

            "target_id": {
                Type:     schema.TypeString,
                Required: true,
                ForceNew: true,
            },

            "port": {
                Type:     schema.TypeInt,
                Optional: true,
                ForceNew: true,
            },
        },
    }
}

func resourceAwsLbTargetGroupAttachmentImport(
    ctx context.Context,
    d *schema.ResourceData,
    meta interface{},
) ([]*schema.ResourceData, error) {

    parts := strings.Split(d.Id(), "-")
    if len(parts) < 2 {
        return nil, fmt.Errorf(
            "Unexpected import ID format (%q), expected: <target_group_arn>-<target_id>",
            d.Id(),
        )
    }

    targetID := parts[len(parts)-1]

    arn := strings.Join(parts[:len(parts)-1], "-")

    d.Set("target_group_arn", arn)
    d.Set("target_id", targetID)

    d.SetId(fmt.Sprintf("%s-%s", arn, targetID))

    return []*schema.ResourceData{d}, nil
}

But the problem is that this is not distinct as we can have the same target id with different ports or availability zones.

Looking at the API docs there's also to consider if the value for the availability zone needs to be interpolated as the meta argument "all" is allowed.

I've also found some issues which may contain some useful information.

#34605
#7617

[salman-cheema]

I just tested applying over an already attached set of instances. Since the attachment is more of an action it just works even if the current attachment is never deleted. This should be noted in the documentation at least. There is no need for an import with the way it currently acts as long as it does not change

It has saved my hours, thank you!, it works as expected no need to update the statefile manually.