Consistent Availability Zones across provider

[opslivia]

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

Background

Azure supports two types of placement of resources: the older Availability Sets and the newer Availability Zones.
Different Azure Regions and different Azure Services may or may not support Availability Zones and/or Availability Sets. The resources which do support Availability Zones either require a single Zone or multiple Zones to be specified depending on the Resource - and different Azure Regions support different Zones (e.g. some support 1 and 2, others 1, 2, and 3, etc.).

As Availability Zones have been rolled out across Azure there's been a couple of changes which means these are implemented inconsistently across the Provider:

1. Zones initially required 1 element. Over time this has differed per-resource, with some resources taking no zones being specified to mean "Zone Redundant" or "No Zone" depending on the Azure Region the resource is being deployed into.
2. Resources may have historically required no zone to be specified (and have no zone today) but new resources of that type may require a Zone.

What this means in practice is that using Zones across the provider is inconsistent.

With this feature, we will make the use of Zones consistent across the provider. Going forward:

• Resources will allow an element of a single zone or a list of multiple.
• We will do away with options like "All Zones" (those using "All Zones" should instead list all zones they desire for the resource).
• No zones listed will not imply "zone redundant."

Affected Resources

The following will be changed to allow multiple zones listed:

• azurerm_application_gateway
• azurerm_dedicated_hardware_security_module
• azurerm_firewall
• azurerm_kusto_cluster
• azurerm_linux_virtual_machine_scale_set
• azurerm_nat_gateway
• azurerm_redis_enterprise_cache
• azurerm_windows_virtual_machine_scale_set
• azurerm_kubernetes_cluster
• azurerm_managed_disk
• azurerm_nat_gateway
• azurerm_redis_cache

The following will be changed to allow a single zone listed:

• azurerm_dedicated_host_group
• azurerm_linux_virtual_machine
• azurerm_load_balancer
• azurerm_orchestrated_virtual_machine_scale_set
• azurerm_mysql_flexible_server
• azurerm_postgresql_flexible_server
• standby_availability_zone (is Optional & Computed, but should be just Optional)
• azurerm_public_ip
• azurerm_public_ip_prefix
• azurerm_windows_virtual_machine

The following resources aren't yet publicly deprecated, but will be in the future (they're feature-frozen as there are replacements available):

• azurerm_virtual_machine
• azurerm_virtual_machine_scale_set

Potential Terraform Configuration

TBD

References

While there are differences in the Azure Services here (notably No Zone, Zone Redundant, Single Zone and Multiple Zones), we should consolidate this behavior in Terraform so that it's consistent.

• Zone-Redundant Public IP Addresses should use list of regional zones #13505
• Public IP Zones #13402
• azurerm_lb in non availability zone regions errors. #12756
• r/api_management - support for publicIpAddressId for multi-zone deployments #13445

[github-actions]

This functionality has been released in v3.0.0 of the Terraform 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.