VPC Expansion via secondary_cidr_blocks is incorrectly destructive to original cidr subnets and route tables

[tnine]

Steps to reproduce

Deploy a simple VPC with the following config.

ders = {
    aws = "aws.uw2"
  }

  source = "terraform-aws-modules/vpc/aws"

  name = "auto-vpc-uw2"
  cidr = "10.0.0.0/16"

  azs             = ["us-west-2a", "us-west-2b", "us-west-2c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway      = true # needed for SQS communication in mail lambda I think
  enable_dns_hostnames    = true
  map_public_ip_on_launch = true # needed for VPCEs

  private_subnet_tags = {
    type = "private"
  }

  public_subnet_tags = {
    type = "public"
  }
}

Plan and apply this configuration to AWS. Once state is persisted and this exists on AWS, modify to this example

module "vpc_uw2" {
  providers = {
    aws = "aws.uw2"
  }

  source = "terraform-aws-modules/vpc/aws"

  name = "auto-vpc-uw2"
  cidr = "10.0.0.0/16"

  secondary_cidr_blocks = [
    "10.1.0.0/16",
    "10.2.0.0/16"
  ]

  azs             = ["us-west-2a", "us-west-2b", "us-west-2c"]
  private_subnets = [
    "10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24",
    "10.1.1.0/24", "10.1.2.0/24", "10.1.3.0/24",
    "10.2.1.0/24", "10.2.2.0/24", "10.2.3.0/24"
    ]
  public_subnets  = [
    "10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24",
    "10.1.101.0/24", "10.1.102.0/24", "10.1.103.0/24",
    "10.2.101.0/24", "10.2.102.0/24", "10.2.103.0/24"
    ]

  enable_nat_gateway      = true # needed for SQS communication in mail lambda I think
  enable_dns_hostnames    = true
  map_public_ip_on_launch = true # needed for VPCEs

  private_subnet_tags = {
    type = "private"
  }

  public_subnet_tags = {
    type = "public"
  }
}

What is expected

The new CIDR ranges of 10.1.0.0/16 and 10.2.0.0/16 are allocated as new resources. Existing 10.0.0/16 ranges are not modified

What happens

The original CIDR of 10.0.0.0/16 and all subnets in AZs, as well as routing tables are destroyed and re-created. This destroys all running services within the VPC, due to the subnet changes. This causes lambdas that run within a VPC to fail to execute.

Acceptance Criteria

The above use case causes a non destructive expansion of the VPC. As the current module is implemented, it makes expansion impossible, since this is a destructive operation to the original CIDR. Note that when expanding via the AWS console, this behavior is not occurring.

[mlucero-wine]

Did you ever find a work-around for this issue? Just curious, I hit something similar to this and I'm considering just hard-coding the subnets (and route tables). In my research, this is just the nature of how count is handled: hashicorp/terraform#18767 As much as I hate copy/paste duplicative code, I'd prefer that over potential downtime.

[nikolaik]

Does using for_each help https://www.terraform.io/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings ?

[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

[bryantbiggs]

hi all, this should be addressed in the next version which is under development here 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.