aws_eip_association data source

[alexrudd]

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 "me too" comments, 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

Currently there's no way to find information about an existing EIP association. Whether these be ones created manually outside of terraform, or ones created implicitly during provisioning of other resources.

The use case I have specifically for this is to get the private IP addresses of an NLB created using subnet mappings. It is very useful to be able to find out the private IP addresses used by the load balancing nodes as these need to be whitelisted for health checking purposes. Looking up the known EIPs association would be one way to determine an NLB's private IP addresses.

New or Affected Resource(s)

• aws_eip_association (data source)

Potential Terraform Configuration

resource "aws_lb" "example" {
  name               = "example-lb-tf"
  load_balancer_type = "network"

  subnet_mapping {
    subnet_id     = "${aws_subnet.example2.id}"
    allocation_id = "${aws_eip.example1.id}"
  }
  subnet_mapping {
    subnet_id     = "${aws_subnet.example2.id}"
    allocation_id = "${aws_eip.example2.id}"
  }
  subnet_mapping {
    subnet_id     = "${aws_subnet.example2.id}"
    allocation_id = "${aws_eip.example3.id}"
  }
}

data "aws_eip_association" "nlb_ip1" {
  allocation_id = "${aws_eip.example1.id}"
  depends_on    = ["aws_lb.example"]
}
data "aws_eip_association" "nlb_ip2" {
  allocation_id = "${aws_eip.example2.id}"
  depends_on    = ["aws_lb.example"]
}
data "aws_eip_association" "nlb_ip3" {
  allocation_id = "${aws_eip.example3.id}"
  depends_on    = ["aws_lb.example"]
}

resource "aws_security_group_rule" "allow_nlb_healthcheck" {
  type        = "ingress"
  from_port   = 8080
  to_port     = 8080
  protocol    = "tcp"
  cidr_blocks = [
    "${data.aws_eip_association.nlb_ip1.private_ip}"
    "${data.aws_eip_association.nlb_ip2.private_ip}"
    "${data.aws_eip_association.nlb_ip3.private_ip}"
  ]
  
  security_group_id = "sg-123456"
}

References

[kl4w]

@alexrudd can this be solved by adding extra attributes to the aws_eip data source: see attached PR?

[lholman]

I have worked around this by using the aws_network_interface data source to get the private ip by description or tag as follows:

By description. Description is auto-populated during NLB creation and includes the NLB name and ID, e.g. ELB net/ecs-0123-load-balancer/c1da50b4bb396db4

data "aws_network_interface" "network-load-balancer-interface" {
  filter {
    name   = "description"
    values = ["*ecs-${var.cluster-number}-load-balancer*"]
  }
}

OR by tag

data "aws_network_interface" "network-load-balancer-interface" {
  filter {
    name   = "tag:YourTagKeyName"
    values = ["YourTagKeyValue"]
  }
}

When capturing as an output...

output "network-load-balancer-private-ip" {
  value = "${data.aws_network_interface.network-load-balancer-interface.private_ips}"
}

It is then yielded with a plan/apply like so

network-load-balancer-private-ip = [
    10.21.44.110
]

[bflad]

Support for the following attributes has been merged into to the aws_eip data source and will release with version 1.46.0 of the AWS provider, likely later tonight or tomorrow:

• association_id
• domain
• instance_id
• network_interface_id
• network_interface_owner_id
• private_ip
• public_ipv4_pool

If there is a specific use case not solved by providing these new attributes in that data source, please feel free to open a new feature request issue. Thanks.

[bflad]

The above has been released in version 1.46.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[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!