Attach existing EBS volumes to launch configuration in Terraform

I have 3 existing EBS volumes that I am trying to attach to instances created with Autoscaling groups. Below is Terraform code on how the EBS volumes are defined:

EBS Volumes

resource "aws_ebs_volume" "volumes" {
  count             = "${(var.enable ? 1 : 0) * var.number_of_zones}"
  availability_zone = "${element(var.azs, count.index)}"
  size              = "${var.volume_size}"
  type              = "${var.volume_type}"

  lifecycle {
    ignore_changes = [
      "tags",
    ]
  }

  tags {
    Name = "${var.cluster_name}-${count.index + 1}"
  }
}

My plan is to first use the Terraform import utility so the volumes can be managed my Terraform. Without doing this import, Terraform assumes I am trying to create new EBS volumes which I do not want.

Additionally, I discovered this aws_volume_attachment resource to attach these volumes to instances. I'm struggling to determine what value to put as the instance_id in this resource:

Volume Attachment

resource "aws_volume_attachment" "volume_attachment" {
  count = length("${aws_ebs_volume.volumes.id}")
  device_name = "/dev/sdf"
  volume_id   = aws_ebs_volume.volumes.*.id
  instance_id = "instance_id_from_autoscaling_group"
}

Additionally, the launch configuration block has an ebs_volume_device block, do I need anything else included in this block? Any advice on this matter would be helpful, as I am having some trouble.

ebs_block_device {
device_name = "/dev/sdf"
no_device   = true

}

I'm struggling to determine what value to put as the instance_id in this resource

If you create ASG using TF, you don't have access to the instance IDs. The reason is that ASG is treated as one entity, rather then individual instances.

The only way to get the instance ids from ASG created would be through external data resource or lambda function source.

But even if you could theoretically do it, instances in ASG should be treated as fully disposable, interchangeable and identical. You should not need to customize them, as they can be terminated and replaced at any time by AWS's AZ rebalancing, instance failures or scaling activities.