Dangling subnet_mapping attributes while changing NLB config from subnet to subnet_mapping

[kartik-03]

Description

We are integrating an Elastic IP (EIP) with our NLB using this module. During our implementation, we encountered an issue where the module does not support using both the subnet and subnet_mapping attributes simultaneously, as noted in issue #340. To work around this limitation, we have removed the subnet attribute from our configuration and exclusively used subnet_mapping. However, this adjustment left us with dangling subnet_mapping constructs that lacked subnet_ids, preventing us from successfully applying changes.

Versions

• Module versions:

• Terraform version: Terraform v1.6.4

• Provider version(s): v9.8.0

Code

module "aws_nlb" {
  source   = "terraform-aws-modules/alb/aws"
  version  = "9.8"
  for_each = var.nlb_loadbalancer_config

  load_balancer_type = "network"
  name               = each.value.lb_name
  vpc_id             = var.vpc_id
  - subnet          = var.public_subnet
  + subnet_mapping     = [
    for idx, eip in aws_eip.static : {
      allocation_id = eip.id
      subnet_id     = var.public_subnets[idx]
    }
  ]
  ....
  }
  
  #Crete EIP for NLB
  resource "aws_eip" "static" {
    count  = length(var.public_subnets)
    domain = "vpc"
  }

Expected behavior

Expected behavior is to get existing subnet_mapping replaced with new subnet_mapping where EIPs are attached with subnets.

Actual behavior

We are getting dangling subnet_mapping where no subnet_ids are available. Here is the plan

module.aws_nlb["nlb-demo"].aws_lb.this[0] will be updated in-place
  ~ resource "aws_lb" "this" {
        id                               = "arn:aws:elasticloadbalancing:<region>:<account-id>:loadbalancer/net/<name>/<hash>"
        name                             = "demo"
      ~ subnets                          = [
          - "subnet-1xxxxxxxxxxxxxxxxxx",
          - "subnet-2xxxxxxxxxxxxxxxxxx",
          - "subnet-3xxxxxxxxxxxxxxxxxx",
        ] -> (known after apply)
        tags                             = {
            "Environment"           = "dev"
            "ManagedBy"             = "Terraform"
            "component_name"        = "lb"
            "terraform-aws-modules" = "alb"
        }
        # (13 unchanged attributes hidden)

      - subnet_mapping {
          - subnet_id = "subnet-1xxxxxxxxxxxxxxxxxx" -> null
        }
      - subnet_mapping {
          - subnet_id = "subnet-2xxxxxxxxxxxxxxxxxx" -> null
        }
      - subnet_mapping {
          - subnet_id = "subnet-3xxxxxxxxxxxxxxxxxx" -> null
        }
      + subnet_mapping {
          + allocation_id = "eipalloc-1yyyyyyyyyyyyyyyy"
          + outpost_id    = (known after apply)
          + subnet_id     = "subnet-1xxxxxxxxxxxxxxxxxx"
        }
      + subnet_mapping {
          + allocation_id = "eipalloc-2yyyyyyyyyyyyyyyy"
          + outpost_id    = (known after apply)
          + subnet_id     = "subnet-2xxxxxxxxxxxxxxxxxx"
        }
      + subnet_mapping {
          + allocation_id = "eipalloc-3yyyyyyyyyyyyyyyy"
          + outpost_id    = (known after apply)
          + subnet_id     = "subnet-3xxxxxxxxxxxxxxxxxx"
        }
      + subnet_mapping {
          + outpost_id = (known after apply)
        }
      + subnet_mapping {
          + outpost_id = (known after apply)
        }
      + subnet_mapping {
          + outpost_id = (known after apply)
        }

        # (2 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

This behavior is restricting us to apply changes as terraform is throwing following error:

Error: setting ELBv2 Load Balancer (arn:aws:elasticloadbalancing:<region>:<account-id>:loadbalancer/net/<name>/<hash>) subnets: ValidationError: You must specify a subnet ID for each subnet mapping.

To resolve the issue and ensure the code functions correctly, we needed to recreate the load balancer, which effectively removed the dangling subnet_mapping entries from the terraform state.

We are seeking to understand why these dangling subnet_mapping entries appeared initially and why they were not cleared upon removing the subnet attribute.

[bryantbiggs]

this is going to be a question for the AWS provider

[github-actions[bot]]

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[bot]]

This issue was automatically closed because of stale in 10 days

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