azurerm_lb unable to set zone-redundant resource

[vpegg-zz]

Hello,

There is an issue when creating/updating azurerm_lb resource with azurerm provider v2.63.0.
https://azure.microsoft.com/en-gb/updates/zone-behavior-change/
This relates to PR #11627

Azurerm provider version: v2.63.0
TF version: 0.13.2

### Loadbalancer configuration
resource "azurerm_lb" "indexer" {
  name                = "${var.environment}indexer-lb"
  location            = var.location
  resource_group_name = azurerm_resource_group.rg.name
  sku                 = "Standard"
  
  frontend_ip_configuration {
    name                          = "LoadBalancerFrontEnd"
    private_ip_address_allocation = "Static"
    subnet_id                     = data.azurerm_subnet.indexer.id
    private_ip_address_version    = "IPv4"
    private_ip_address            = var.indexer_lb_private_ip
  }
  lifecycle {
    ignore_changes = [
      tags
    ]
  }
}

The plan output (redacting most of the plan) when altering a different resource (i.e. the loadbalancer was already created and I had changed a different resource entirely):

# azurerm_lb.indexer must be replaced
-/+ resource "azurerm_lb" "indexer" {
      ~ id                   = "*****" -> (known after apply)
        location             = "northeurope"
        name                 = "prdindexer-lb"
      ~ private_ip_address   = ****-> (known after apply)
      ~ private_ip_addresses = [
          - ****,
        ] -> (known after apply)
        resource_group_name  = "****"
        sku                  = "Standard"

~ frontend_ip_configuration {
          ~ id                            = "****" -> (known after apply)
          ~ inbound_nat_rules             = [] -> (known after apply)
          ~ load_balancer_rules           = [
              - "*****",
            ] -> (known after apply)
            name                          = "LoadBalancerFrontEnd"
          ~ outbound_rules                = [] -> (known after apply)
            private_ip_address            = "****"
          ~ private_ip_address_allocation = "Static" -> "static"
            private_ip_address_version    = "IPv4"
          + public_ip_address_id          = (known after apply)
          + public_ip_prefix_id           = (known after apply)
            subnet_id                     = "*****"
          - zones                         = [
              - "1",
              - "2",
              - "3",
            ] -> null # forces replacement
        }
    }

When adding frontend_ip_configuration[0].zones - the lb resource does not get recreated (as per tf plan).

On previous versions of the provider - our pipelines ran and lb were not being recreated. This I believe is because, as per docs, when Zones is not specified (like in my configuration), the loadbalancer would be zone redundant. However, now it is following the new zone behaviour change (https://azure.microsoft.com/en-gb/updates/zone-behavior-change/) and when not specifying zone a non-zonal resource is created.

You are also not able to specify zones = ["1","2","3"]

Error: frontend_ip_configuration.0.zones: attribute supports 1 item maximum, config has 3 declared

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 "me too" comments, 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

Affected Resource(s)

• azurerm_lb

[ALK4]

We are seeing the same issue just running a plan in an environment with existing load balancers.

We are seeing this problem in the Azure Commercial cloud with Azurerm 2.43.0.
We are NOT seeing the problem in Azure Govnerment with Azurerm 2.43.0.

The fact that we aren't seeing it in our GovCloud environment makes me think this is may be a change to the azure API, as Gov changes tend to lag behind commercial.

[kazimierzbudzyk]

Also ran into that when upgrading to >2.60.0. Would be very curious to know if there's a fix or a workaround for this one.

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