如何使用Bicep模板创建Azure NSG流日志 解决Network Watcher配额报错

• Azure 每个公开区域在订阅开通网络能力后，会自动在固定托管资源组 NetworkWatcherRG 下创建唯一的 NetworkWatcher 资源，该资源的单区域订阅配额固定为 1，不支持重复创建
• 原模板的直接触发点为：将流日志定义为顶级资源，名称写为NetworkWatcher_${location}/${nsgFlowName}时，ARM在资源路径解析阶段会将路径拆分的上一级节点NetworkWatcher_${location}识别为待新建的NetworkWatcher资源，叠加系统已存在的1个实例，最终触发配额校验失败。

• 用Bicep的existing语法直接引用已存在的系统NetworkWatcher资源，不触发新建校验逻辑
• 将NSG流日志资源设置为上述已存在NetworkWatcher的子资源，修正ARM的路径解析规则，避免误判为新建NetworkWatcher

1. 引用已存在的默认NetworkWatcher资源

// 关联目标区域系统预置的NetworkWatcher，无新建资源的开销
resource defaultNetworkWatcher 'Microsoft.Network/networkWatchers@2020-08-01' existing = {
  name: 'NetworkWatcher_${location}'
  scope: resourceGroup('NetworkWatcherRG')
}

2. 定义关联的NSG流日志资源

resource nsgFlowLogs 'Microsoft.Network/networkWatchers/flowLogs@2020-08-01' = {
  parent: defaultNetworkWatcher // 绑定已存在的NetworkWatcher作为父资源
  name: nsgFlowName
  location: location
  properties: {
    targetResourceId: nsg.Id // 关联模板内定义的目标NSG资源ID
    storageId: stg.Id // 关联模板内定义的流日志存储账户ID
    enabled: true
    retentionPolicy: {
      days: 2
      enabled: true
    }
    format: {
      type: 'JSON'
      version: 2
    }
  }
}

• 不要在模板内编写任何新建NetworkWatcher的代码逻辑，否则必然触发单区域1个实例的配额限制
• 系统默认的NetworkWatcherRG为Azure托管专用资源组，不要随意修改其名称、删除组内的NetworkWatcher资源
• 用于存储流日志的存储账户需满足前置要求：为StorageV2类型、与NSG部署在同一区域、未开启会拦截流日志服务写入的存储防火墙规则

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