Terraform: aws_instance associate_public_ip_address

[mengesb]

Related to #5764 I'd like to re-raise the issue of associate_public_ip_address in the aws_instance resource.

If the subnet being used has a map_public_ip = true setting, it will always map a public IP. I rather this be interpreted as, "If not specified, use map_public_ip setting for the subnet". It seems this is not the case, and that the subnet settings can override the aws_instance settings.

Is this an API limitation? Even if I create a subnet with public IP mapping, there are circumstances where I want the VMs created to not have public IPs. I know that if I have a subnet that DOES NOT map public IPs, and I set associate_public_ip_address = true on the aws_instance resource, I get a public IP. When I manually create an instance via the AWS console, I get the option to disable the 'auto-assign public IP', accept the subnet default, or enable. Seems pretty clear-cut here that if I specify false for associate_public_ip_address I should NOT get a public IP no matter what the subnet settings are.

Terraform Version

0.7.0

Affected Resource(s)

• aws_instance
  

  Terraform Configuration Files

resource "aws_instance" "instance" {
  ami = ..
  ebs_optimized = ..
  instance_type = ..
  associate_public_ip_address = false
  subnet_id = ..
 ...
}

Debug Output

N/A

Panic Output

N/A

Expected Behavior

if associate_public_ip_address is set to false, I get an instance without a public IP. If `associate_public_ip_address is set to true, I get an instance with a public IP. This doesn't matter whether or not the subnet is set to automatically map public IPs or not.

Actual Behavior

if associate_public_ip_address is set to false, I get an instance with a public IP if the subnet is configured to map_public_ip = true (done in terraform or not done in terraform).
if associate_public_ip_address is set to false, I get an instance without a public IP if the subnet is configured to map_public_ip = false (done in terraform or not done in terraform).

Steps to Reproduce

---

1. Create terraform plan with aws instance resource. set associate_public_ip_address to false
2. Use a subnet id that maps public IPs to instances (map_public_ip = true)
3. terraform apply
4. VM has public IP associated

---

1. Create terraform plan with aws instance resource. set associate_public_ip_address to true
2. Use a subnet id that maps public IPs to instances (map_public_ip = false)
3. terraform apply
4. VM has public IP associated

---

1. Create terraform plan with aws instance resource. set associate_public_ip_address to false
2. Use a subnet id that maps public IPs to instances (map_public_ip = false)
3. terraform apply
4. VM does not have a public IP associated

---

1. Create terraform plan with aws instance resource. set associate_public_ip_address to true
2. Use a subnet id that maps public IPs to instances (map_public_ip = true)
3. terraform apply
4. VM has public IP associated

---

1. Create terraform plan with aws instance resource. do not specify associate_public_ip_address
2. Use a subnet id that maps public IPs to instances (map_public_ip = true)
3. terraform apply
4. VM has public IP associated

---

1. Create terraform plan with aws instance resource. do not specify associate_public_ip_address
2. Use a subnet id that maps public IPs to instances (map_public_ip = false)
3. terraform apply
4. VM does not have a public IP associated

---

Important Factoids

N/A

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• #5764

[dustyburwell]

I've started looking into a patch for this. The request is, in effect, a tri-state attribute:

| value | effect |
| --- | --- |
| true | associate public IP |
| false | do not associate public IP |
| not specified | use the subnet default |

The resource in question here is currently compressing these possibilities into a Boolean value.

| value | effect |
| --- | --- |
| true | associate public IP |
| false | use the subnet default |
| not specified (behaves as default false) | use the subnet default |

Are there any good examples in existing providers of such tri-state behavior? Looking at the ResoueceData type, this code is using Get to get the value of the attribute, defaulting to false. There is an alternative mechanism here, GetOk which returns the pair of the value and whether or not the value exists, i.e. is there a value provided for the attribute.

Digging into GetOk, it appears to check if the attribute has been set to the "zero" value, false in the case of Boolean, and returns false for the "exists" portion of the result pair. Thus, even though an interface exists to potentially check for existence of a Boolean attribute, the implementation removes that as a possibility.

I see a couple of paths forward here:

1. Remove the "zero check" in GetOk. This has many potential side effects that I would be unfamiliar with. Is there any institutional knowledge here as to why this check exists? Presumably, even an integer value of 0 could be considered to "exist" when set under certain circumstances.
2. Add a method to ResourcdData for explicitly checking if an attribute has been set.
3. Define some sort of tri-state value type.

Please advise on an idiomatic approach.

Regardless of approach, it's important to note that fixing this issue will introduce a backward incompatabity. Anyone currently setting associate_public_ip_address to false in a map_public_ip=true subnet will suddenly see their instances being rebuilt.

[mengesb]

I think the root of the problem is that in the situation of a Boolean false we adopt the subnet default - I'd more aptly believe that if something is being provided, and in fact that value is false, that it should remain false - not overridden by an acquired value via get

[tamsky]

This affects me as well.
I looked at this config element and expected false to do something vs a subnet default of true.

Given that the current stanza:
associate_public_ip_address = false
is a glorified noop, it should be easy to include in a
CHANGELOG : BACKWARDS INCOMPATIBILITIES / NOTES section.

[tamsky]

After reading #10568 and dealing with this a bit more, I can't imagine fixing this will affect anyone.

If anyone were to be affected, they are either relying on it to always recreate their instances on apply because instance state always forces new resources
associate_public_ip_address: "true" => "false" (forces new resource)
which is a pretty pathological use case to cater to,

or they are avoiding the churn using ignore_changes[].

[hashibot[bot]]

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.