aws_lb subnet_mapping forces recreation using ForceNew even if only new subnet mapping is added

[alkuzad]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

Terraform v0.12.23
Tested on AWS provider 2.63.0 and 3.25.0

Affected Resource(s)

aws_lb

Terraform Configuration Files

resource "aws_eip" "nlb_public_ip" {
  count = local.is_public_nlb ? length(var.subnet_mappings) : 0
  vpc   = true

  lifecycle {
    # Recovering a deleted elastic IP requires manual intervention,
    # and is not possible if AWS happen to assign it to someone else.
    # Ensure IPs are not inadvertently deleted.
    prevent_destroy = true
  }
}

resource "aws_lb" "nlb_public" {
  internal = false
  name = "somename"
  load_balancer_type               = "network"
  enable_cross_zone_load_balancing = true

  dynamic "subnet_mapping" {
    for_each = range(length(var.subnet_mappings))

    content {
      subnet_id     = var.subnet_mappings[subnet_mapping.key]
      allocation_id = lookup(aws_eip.nlb_public_ip[subnet_mapping.key], "id")
    }
  }
}

and var:

subnet_mappings= [
  "subnet-xxxx",
  "subnet-yyyy",
  "subnet-zzzz"
]

Debug Output

Panic Output

Expected Behavior

New subnet mapping added into existing NLB (as in AWS Console you can add but not remove existing Subnets)

Actual Behavior

New subnet added into NLB and NLB forced to be recreated.

Steps to Reproduce

1. terraform apply
2. Add new subnet mapping
3. Run terraform plan and see that NLB will be recreated

[msahihi]

Same issue here but using subnet although it is already documented in lb#subnets
Scaling out my project from 3 availability zone to 4 AZ got the following

/+ resource "aws_lb" "cf-proxy" {
      ~ arn                              = "XXXXXXX" -> (known after apply)
      ~ arn_suffix                       = "XXXXXXX" -> (known after apply)
      ~ dns_name                         = "XXXXXXX" -> (known after apply)
        enable_cross_zone_load_balancing = false
        enable_deletion_protection       = false
      ~ id                               = "XXXXXXX" -> (known after apply)
      ~ internal                         = false -> (known after apply)
      ~ ip_address_type                  = "ipv4" -> (known after apply)
        load_balancer_type               = "network"
        name                             = "cf-proxy-aws-lod"
      ~ security_groups                  = [] -> (known after apply)
      ~ subnets                          = [
          - "subnet-00298114be3a075ad",
          - "subnet-079bcbe2ddc2660a4",
          - "subnet-0c32554373923c9e5",
        ] -> (known after apply) # forces replacement
      ~ vpc_id                           = "vpc-0828b9d093c4347b0" -> (known after apply)
      ~ zone_id                          = "XXXXXXX" -> (known after apply)

      - access_logs {
          - enabled = false -> null
        }

      - subnet_mapping {
          - subnet_id = "subnet-00298114be3a075ad" -> null
        }
      - subnet_mapping {
          - subnet_id = "subnet-079bcbe2ddc2660a4" -> null
        }
      - subnet_mapping {
          - subnet_id = "subnet-0c32554373923c9e5" -> null
        }
      + subnet_mapping {
          + allocation_id = (known after apply)
          + subnet_id     = (known after apply)
        }
    }

[esolitos]

I just want to add that this happens also for ipv6, probably this is not nothing surprising, but adding this info just in case it is relevant.

  # module.hosting.module.lb.aws_lb.default must be replaced
-/+ resource "aws_lb" "default" {
      ~ arn                              = "xxx" -> (known after apply)
      ~ arn_suffix                       = "xxx" -> (known after apply)
      ~ dns_name                         = "xxx" -> (known after apply)
      ~ id                               = "xxx" -> (known after apply)
        name                             = "xxx"
      ~ security_groups                  = [] -> (known after apply)
      ~ subnets                          = [
          - "subnet-0c3e0291f2123123b",
        ] -> (known after apply)
      ~ vpc_id                           = ""xxx"" -> (known after apply)
      ~ zone_id                          = ""xxx"" -> (known after apply)
        # (6 unchanged attributes hidden)

      ~ access_logs {
            # (1 unchanged attribute hidden)
        }

      - subnet_mapping { # forces replacement
          - ipv6_address = "2a05:1234:1234:1234:1234:1234:1234:1234" -> null
          - subnet_id    = "subnet-0c3e0291f2123123b" -> null
        }
      + subnet_mapping { # forces replacement
          + allocation_id = "eipalloc-01b429123123123fa"
          + ipv6_address  = "2a05:1234:1234:1234:1234:1234:1234:1234"
          + outpost_id    = (known after apply)
          + subnet_id     = "subnet-0c3e0291f2123123b"
        }
    }

[ef-klukacs]

Same issue with provider 4.64.0

At initial LB resource creation subnet_mapping block is used, subnets argument is omitted (as it required by the API) --> terraform apply succeeds.
For subsequent terraform plan/apply cases tf ends up in resource re-creation loop.
Adding subnets argument to resource definition including all subnet ids referenced in subnet_mapping block resolved this issue for me.

This scenario requires a two step execution:

1. no subnets, tf apply
2. subnets added, tf apply

[dkewley]

I see the behavior described by @ef-klukacs in provider 5.25.0, which occurs without adding or deleting subnets to the NLB, so may or may not have the same root cause as the original issue description here.

I confirmed that when I provide subnet_mapping, subnets must not be provided upon first apply.

But then subnets must be provided upon subsequent applies (with same subnet IDs as subnet_mapping), otherwise TF detects a change to subnets (removal of the subnet IDs) that forces replacement of the NLB.

FWIW I'm using this resource via v9.2.0 of https://github.com/terraform-aws-modules/terraform-aws-alb, but I don't think that affects the behavior described here.

[github-actions]

This functionality has been released in v5.31.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[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.