Terraform中注释azurerm_postgresql_flexible_server的private_dns_zone_id无效的原因？

resource "azurerm_postgresql_flexible_server" "default" {
  name                          = "${var.environment}-${var.name}-postgres-server"
  resource_group_name           = var.resource_group_name
  location                      = var.resource_group_location
  version                       = "16"
  delegated_subnet_id           = var.delegated_subnet_id
  #private_dns_zone_id           = var.private_dns_zone_id
  administrator_login           = var.admin_username
  administrator_password        = var.admin_password
  zone                          = "2"
  storage_mb                    = var.storage_mb
  sku_name                      = var.sku_name
  backup_retention_days         = 7
  public_network_access_enabled = false
  #depends_on                    = [var.private_dns_zone_id]
}

我们原本使用Azure专用DNS解析器，但成本过高，因此计划改用Bind，在Azure网络中添加额外DNS服务器并移除private_dns_zone_id参数。但发现无论在Terraform还是Azure平台中都无法实现该操作，且未找到相关官方文档说明是否支持此配置。此外，删除现有DNS区域不可行，因为这会删除与PostgreSQL灵活服务器关联的所有资源。请问该如何解决此问题？

核心限制说明 #

Azure PostgreSQL灵活服务器一旦在部署阶段配置了private_dns_zone_id，后续无法直接移除该参数或切换到自定义DNS服务器（如Bind）。这是因为服务器的私有终结点DNS记录与专用DNS区域强绑定，Azure平台不支持这类事后变更，强行操作会破坏服务的网络可达性。

彻底迁移方案（完全替换为Bind） #

由于无法修改现有服务器的DNS配置，只能通过迁移数据到新服务器实现目标，步骤如下：

1. 部署新的PostgreSQL灵活服务器
   • 部署时不配置private_dns_zone_id参数，确保服务器使用虚拟网络中已配置的Bind DNS服务器。
   • 保持版本、SKU、存储容量等核心配置与原服务器一致，避免兼容性问题。
   • 维持public_network_access_enabled = false，确保仅内网访问。
2. 迁移数据库数据
   • 使用PostgreSQL原生工具pg_dump/pg_restore或Azure数据库迁移服务（DMS）迁移数据：
     • 导出原服务器数据：

       pg_dump -h <原服务器私有IP> -U <管理员账号> -d <目标数据库名> -f backup.sql
       

     • 导入到新服务器：

       psql -h <新服务器私有IP> -U <管理员账号> -d <目标数据库名> -f backup.sql
       

   • 迁移完成后验证数据完整性和应用连通性。
3. 切换应用流量
   • 将应用的数据库连接地址改为新服务器的私有IP（或Bind中配置的自定义域名）。
   • 逐步停止原服务器的业务流量，确认新服务器运行稳定。
4. 清理旧资源
   • 确认新服务正常后，再删除原服务器及关联的专用DNS区域，避免误删导致业务中断。

临时过渡方案（无需迁移，降低成本） #

如果暂时无法进行数据迁移，可通过以下方式减少Azure专用DNS解析器的负载：

• 在Bind服务器中添加原专用DNS区域的转发规则，将该区域的DNS查询转发到Azure专用DNS解析器。
• 修改虚拟网络的DNS服务器为Bind的IP，这样应用通过Bind解析时，PostgreSQL相关的DNS请求会自动转发到Azure解析器，其他域名由Bind处理。
• 此方案无法完全停用Azure专用DNS解析器，但可降低其查询量，从而减少部分成本。

内容的提问来源于stack exchange，提问作者pregmatch