aws_network_interface attachment should be handled in aws_instance

[inkblot]

Currently, attachment of a aws_network_interface resource is handled by an object property of the interface itself. This forces the network interface to be created after the aws_instance to which it is attached, and in the case where an instance will have multiple interfaces, it distributes the device indexing information across the several interface resources. The attachment-after-startup also eliminates the possibility of booting an instance into its final network context, not just the interfaces, but also any follow-up initialization such as route53 naming.

Here is a sample of what I would like to be able to do with terraform:

resource "aws_eip" "server" {
  vpc_id = "${var.vpc_id}"
}

resource "aws_network_interface" "server" {
  ...
  public_ips = [ "${aws_eip.server.public_ip}" ]
}

resource "aws_route53_resource_record" "server-private" {
  ...
  records = [ "${aws_network_interface.server.private_ip}" ]
}

resource "aws_instance" "server" {
  depends_on = [ "aws_route53_record_set.server-private" ]
  ...
  network_interfaces {
    0 = "${aws_network_interface.server.id}"
  }
}

In the above sample, the instance is the last resource created. At the point where the instance boots, everything about its network context has already been established and can be guaranteed invariant through use of depends_on. This means that at bootup, the instance 1) has its final eth0, 2) has its final public_ip and private_ip, and 3) that those IPs can be used in terraform prior to creating the instance for example to establish DNS records.

[wilsaj]

+1 for this. Being able to assign elastic IP or network interface on instance creation would make it easier to adjust instances without much disruption (for example, changing instance_type or ami). Without this, DNS records need to be updated if the instance is recreated, and this introduces a delay as the records propagate. Setting a very short TTL on the DNS records sort of mitigates the problem, but isn't a great solution since it introduces a lot of undue DNS traffic.

[rgabo]

We're using cloud-init to boot instances into their final state and keep instance immutable otherwise. Our use case is to bind separate public and private interfaces to the same instance and would love to configure SSH/ProFTPD to bind to the correct interfaces.

This requires the interfaces to be already attached at bootcmd/runcmd time so it would be great if this was possible.

[joelmoss]

👍 definately need this, as it has flummoxed me several times, and requires manual intervention

[P13612]

• 1 I have the same problem for what I want to achieve and opened an issue a couple of thousand issues later aws_instance parameter network_interfaces is missing! #5765. I'm not sure whether this increases the urgency very much though. But sure this is an important issue.

[Shaiou]

Another good reason to have the attachment in the aws_instance declaration is regarding the security group. For instance I'm booting an instance with a security group "sg_prv" and I want to add an interface with sg "sg_pub". When doing this with the "aws_network_interface" method, the new interface finds itself in 2 SGs "sg_prv" and "sg_pub"

[zzzuzik]

+1

[freimer]

This is standard functionality that is already part of the AWS API, so this should not be overly difficult to implement. 👍

[alexintel]

+1

Another factor in creating a network interface before the instance is assignment of eth0. If, for some reason, we want to keep eth0 fixed then creating an ENI and assigning it to aws_instance would be possible. Otherwise, aws_network_interface has to be created with device_index>0

[mdolian]

This is needed to reproduce the CloudFormation for the Cisco Cloud Services Router:

https://aws.amazon.com/marketplace/pp/B00EV8VXG2

[lisfo4ka]

+1

[vitalii-ielakov]

+1

[dmytro-rusakov]

+1

[apparentlymart]

Hi @inkblot! Thanks for opening this and sorry it's sat here unattended for so long.

This request is similar to #2998, so I'm going to close this to consolidate the discussion over there. Furthermore, there's some work to address this going on in #12933 so hopefully it won't be long before the other issue is closed as well.

[inkblot]

The new functionality in 0.9.4 is working beautifully! Thank you!

[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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.