Private Subnet management is destructive

[ghost]

We are creating a set of private subnets, and one of our use cases is the ability to add and remove subnets at will. We notice that the creation of subnets seems to have the "count issue", where if for example, another private subnet is added after the first of three, the second and third are deleted and recreated after the (new) second one is created. Needless to say, this would be disruptive to anyone using the second and third private subnets.

Is there a workaround for this, other than modifying the relevant code to use for_each instead of count?

[dpiddockcmp]

Quick answer: no. Terraform does not play well with modifying lists.

Suggestions:

• Only append or delete from the end of the list
• Modify the state file by shifting items in the list before doing plan/apply: terraform state mv resource[n] resource[n+1]

In both of these cases you will see knock on issues with other resources not just the subnet. NAT gateways, route tables, routes, etc etc. Terraform also seems to like to trigger full recreation of dependent resources if an item in a counted resource is unknown.

Best option for your usecase would be a forked/new module that uses for_each.

[achachw]

Hi
Why don't use a map instead of list to define subnets,to avoid this behaviour
We can for example define a public subnet like this :

public-subnets = {
  subnet1 = {
    cidr = 10.0.11.0/24,
    az    = "eu-west-1b"
  },
  subnet2 = {
    cidr = 10.0.11.0/24,
    az    = "eu-west-1c"
  }
}

What do you this about this ?

[barryib]

Hi @antonbabenko,

How can we move forward on this ? Can we work on a PR to add map support ? How do we handle breaking changes ?

Related to #178

[antonbabenko]

@barryib Good question. Let's discuss it during our own meeting on Friday.

[Nickmman]

Hi there, we've run into this same issue and think that using the for_each method instead of the count method would resolve this issue.

Have talks on this improvement stalled?

[github-actions]

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

[github-actions]

This issue was automatically closed because of stale in 10 days

[dusansusic]

Any plans for this?

[bryantbiggs]

there are plans and some preliminary work underway on what a potential v4 *might look like which would look to solve problems such as this - you can track that here if interested https://github.com/clowdhaus/terraform-aws-vpc-v4

[github-actions]

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.