[philsnow]

There's another similar issue with how EC2 security group rules are encoded: you can encode them either as ingress/egress stanzas on an "aws_security_group" resource, or you can attach rules to a security group resource with separate "aws_security_group_rule". You can't mix the two approaches on a single security group resource.

We adopted the ingress/egress stanza on security group resource approach.

If we ever wanted to change to the other approach (as described in the article), I don't think I would do state surgery by hand or even use "terraform state mv". I would:

    1. change terraforming to generate .tf files and tfstates the way I want
    2. remove the security groups from my config and my state
    3. use terraforming to regenerate the .tf files and tfstate

[mitchellh]

Hey there. Disclaimer: one of the creators of Terraform

I wanted to apologize that this is super confusing. All the scenarios where this exists (there are many) are historical. We originally went with the "nested" approach and now prefer the "split" approach for good reasons shown to us by users. But we kept both for backwards compatibility reasons. We have no good mechanism to enforce a migration at the moment. There are a couple ways we can resolve this technically in the future. For now, we should probably make sure the docs are annotated in all situations of the limitations of nested vs. standalone. I'll mention this to the team!

[Florin_Andrei]

Yeah, this is a universal theme with Terraform resources.

If you can choose between a "con todo" description that lumps together resources and subresources, versus describing every single little thing separately and then attaching them together, always use attachments.