大規模私人連結和 DNS 整合

發行項
07/04/2024

本文說明如何將適用於 PaaS 服務的 Azure Private Link 與中樞和輪輻網路架構中的 Azure 私用 DNS 區域整合。

簡介

許多客戶會使用中樞和輪輻網路架構在 Azure 中建置其網路基礎結構，其中：

網路共享服務（例如網路虛擬設備、ExpressRoute/VPN 閘道或 DNS 伺服器）部署在中樞虛擬網路（VNet）中。
輪輻 VNet 會透過 VNet 對等互連來取用共用服務。

在中樞和輪輻網路架構中，應用程式擁有者通常會提供 Azure 訂用帳戶，其中包含連線至中樞 VNet 的 VNet（輪輻）。 在此架構中，他們可以部署其虛擬機，並透過 ExpressRoute 或 VPN，對其他 VNet 或內部部署網路進行私人連線。

中央網路虛擬設備（NVA），例如 Azure 防火牆，可提供因特網輸出連線能力。此外，該裝置，例如使用 Azure 防火牆 DNS Proxy，或中樞相鄰的另一個服務，通常用來自定義 DNS 轉送。

許多應用程式小組會使用 Azure IaaS 和 PaaS 資源的組合來建置其解決方案。某些 Azure PaaS 服務（例如 SQL 受管理執行個體）可以部署在客戶 VNet 中。因此，流量會在 Azure 網路內保持私人狀態，且可從內部部署完全路由傳送。

但某些 Azure PaaS 服務（例如 Azure 儲存體或 Azure Cosmos DB）無法部署在客戶的 VNet 中，而且可透過其公用端點存取。在某些情況下，此設定會導致與客戶的安全策略發生爭用。公司流量可能不允許透過公用端點部署或存取公司資源（例如 SQL 資料庫）。

Azure Private Link 支援透過私人端點存取 Azure 服務清單，但您必須在對應的私人 DNS 區域中註冊這些私人端點記錄。

本文說明應用程式小組如何在只能透過私人端點存取的訂用帳戶中部署 Azure PaaS 服務。

本文也說明應用程式小組如何確保服務自動與私人 DNS 區域整合。他們會透過 Azure 私用 DNS 進行自動化，因此不需要在 DNS 中手動建立或刪除記錄。

中樞和輪輻網路架構中的 Private Link 和 DNS 整合

私用 DNS 區域通常會集中裝載於中樞 VNet 部署所在的相同 Azure 訂用帳戶中。此中央裝載做法是由跨單位 DNS 名稱解析所驅動，以及其他中央 DNS 解析的需求，例如 Active Directory。在大部分情況下，只有網路和身分識別系統管理員有權管理區域中的 DNS 記錄。

應用程式小組有權在自己的訂用帳戶中建立 Azure 資源。它們沒有任何中央網路連線訂用帳戶中的許可權，包括管理私人 DNS 區域中的 DNS 記錄。此存取限制表示他們無法建立使用私人端點部署 Azure PaaS 服務時所需的 DNS 記錄。

下圖顯示使用中央 DNS 解析之企業環境的典型概略架構，以及透過 Azure 私人 DNS 的 Private Link 資源名稱解析在何處進行：

具有私人鏈接資源中央 DNS 解析和名稱解析的高階架構圖表。

從上圖中，請務必醒目提示：

內部部署 DNS 伺服器已針對每個私人端點公用 DNS 區域設定條件式轉寄站，指向裝載於中樞 VNet 中的私用 DNS 解析程式。
裝載於中樞 VNet 中的私用 DNS 解析程式會使用 Azure 提供的 DNS （168.63.129.16）作為轉寄站。
中樞 VNet 必須連結至 Azure 服務的私用 DNS 區域名稱（例如 privatelink.blob.core.windows.net，如圖所示）。
所有 Azure VNet 都會使用裝載在中樞 VNet 中的私用 DNS 解析程式
由於私用 DNS 解析程式對客戶的公司網域不具權威性，因為它只是轉寄站，（例如 Active Directory 功能變數名稱），它應該有輸出端點轉寄站到客戶的公司網域，指向內部部署 DNS 伺服器（172.16.1.10 和 172.16.1.11）或部署在 Azure 中，這些伺服器是這類區域的授權。

注意

您可以在中樞虛擬網絡與 ExpressRoute 閘道等一起部署 DNS 私人解析程式。不過，您必須確保允許公用 FQDN 的解析，並透過 DNS 轉送規則集規則回復至目標 DNS 伺服器的有效回應。由於某些 Azure 服務依賴將公用 DNS 名稱解析為運作的能力。請在此深入了解

雖然上圖描述單一中樞和輪輻架構，但客戶可能需要跨多個區域擴充其 Azure 使用量，以解決復原、鄰近性或數據落地需求，但出現了數個案例，其中必須透過多個私人端點存取相同 Private-Link 的 PaaS 實例。

下圖顯示企業環境的典型高階架構，其中中央 DNS 解析部署於中樞（每個區域一個），其中私人鏈接資源的名稱解析是透過 Azure 私用 DNS 完成。

建議部署多個與 PaaS 實例相關聯的區域私人端點，每個區域中都有一個用戶端存在、啟用每個區域的 Private Link 和私用 DNS 區域。使用具有內建DR功能的 PaaS 服務時（異地備援記憶體帳戶、SQL DB 故障轉移群組等），需要多個區域私人端點。

此案例需要在每個區域中手動維護/更新 Private Link DNS 記錄集，因為這些區域目前沒有自動化生命週期管理。

對於其他使用案例，可以部署單一全域私人端點，藉由將來自相關區域的路由新增至單一區域中的單一私人端點，讓所有用戶端都能存取。

若要啟用解析，因此從內部部署網路到 privatelink 私人 DNS 區域和私人端點的連線能力，必須在 DNS 基礎結構中布建適當的 DNS 設定（例如條件式轉寄站）。

應用程式小組必須有兩個條件，才能在其訂用帳戶中建立任何必要的 Azure PaaS 資源：

中央網路和/或中央平臺小組必須確保應用程式小組只能透過私人端點來部署和存取 Azure PaaS 服務。
中央網路和/或中央平臺小組必須確保當他們建立私人端點時，他們會設定如何處理對應的記錄。設定對應的記錄，使其會在符合所建立服務的集中式私人 DNS 區域中自動建立。
DNS 記錄必須遵循私人端點的生命週期，也就是說，刪除私人端點時會自動移除。

注意

如果需要在 Azure 防火牆和防火牆原則中使用以 DNS 解析為基礎的網路規則中的 FQDN（此功能可讓您使用任何 TCP/UDP 通訊協定來篩選輸出流量，包括 NTP、SSH、RDP 等等）。您必須啟用 Azure 防火牆 DNS Proxy，才能在網路規則中使用 FQDN，然後這些輪輻 VNet 會強制將其 DNS 設定從自定義 DNS 伺服器變更為 Azure 防火牆 DNS Proxy。變更輪輻 VNet 的 DNS 設定需要重新啟動該 VNet 內的所有 VM。

下列各節說明應用程式小組如何使用 Azure 原則來啟用這些條件。此範例使用 Azure 儲存體作為應用程式小組部署所需的 Azure 服務。但相同的原則適用於支援 Private Link 的大部分 Azure 服務。

平臺小組所需的設定

平臺小組設定需求包括建立私人 DNS 區域、設定原則定義、部署原則，以及設定原則指派。

建立私人 DNS 區域

針對支援的 Private Link 服務，在中央連線訂用帳戶中建立私人 DNS 區域。如需詳細資訊，請參閱 Azure 私人端點 DNS 設定。

在此情況下， 具有 Blob 的記憶體帳戶就是範例。其轉譯為在連線訂用帳戶中建立 privatelink.blob.core.windows.net 私人 DNS 區域。

顯示連線訂用帳戶中私人 DNS 區域的螢幕快照。

原則定義

除了私人 DNS 區域，您也需要建立一組自定義 Azure 原則定義。這些定義會強制執行私人端點的使用，並在您建立的 DNS 區域中自動建立 DNS 記錄：

Deny PaaS 服務原則的公用端點。

此原則可防止使用者使用公用端點建立 Azure PaaS 服務，並在建立資源時未選取私人端點時，提供錯誤訊息。

PaaS 服務之間的確切原則規則可能會有所不同。如需 Azure 儲存體帳戶，請查看 networkAcls.defaultAction 屬性，以定義是否允許來自公用網路的要求。在此情況下，如果屬性 networkAcls.defaultAction 不是 Deny，請設定條件來拒絕建立 Microsoft.Storage/storageAccounts 資源類型。下列原則定義會顯示行為：
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny 能夠建立具有 privatelink 前置詞原則的私人 DNS 區域。

使用集中式 DNS 架構搭配平臺小組所管理訂用帳戶中裝載的條件轉寄站和私人 DNS 區域。必須防止應用程式小組擁有者建立自己的 Private Link 私人 DNS 區域，並將服務連結至其訂用帳戶。

請確定當您的應用程式小組建立私人端點時，選項Integrate with private DNS zone會在 Azure 入口網站中設定為 No 。

如果您選取 Yes，Azure 原則會防止您建立私人端點。在原則定義中，如果區域具有privatelink前置詞，則會拒絕建立 Microsoft.Network/privateDnsZones 資源類型的能力。下列原則定義會顯示前置 privatelink 詞：
```
{
  "description": "This policy restricts creation of private DNS zones with the `privatelink` prefix",
  "displayName": "Deny-PrivateDNSZone-PrivateLink",
  "mode": "All",
  "parameters": null,
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Network/privateDnsZones"
        },
        {
          "field": "name",
          "contains": "privatelink."
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
DeployIfNotExists 原則，可自動在中央私人 DNS 區域中建立必要的 DNS 記錄。

下列原則範例示範兩種方法，用來識別在私人端點上建立的方法 privateDNSZoneGroup 。

第一個原則依賴， groupId 而第二個原則則同時使用 privateLinkServiceId 和 groupID。當與另一個資源發生衝突時，請使用第二groupId個原則。

例如，groupIdSQL 用於 Cosmos DB 和 Synapse Analytics。如果已指派資源類型部署和第一個原則，以在私人端點專案上建立 privateDNSZoneGroup ，則會建立並對應至 Cosmos DB 或 Synapse Analytics 中不正確的私用 DNS 區域。然後，它可能會切換每個區域，因為第一個原則在其原則規則中尋找的衝突 groupId 。

如需 Private-link 資源groupId清單，請參閱什麼是私人端點？中的子資源數據行。

提示

Azure 原則內建定義不斷新增、刪除和更新。強烈建議使用內建原則與管理您自己的原則（如果有的話）。使用 AzPolicyAdvertizer 尋找具有下列名稱 'xxx ... 的現有內建原則使用私人 DNS 區域』。此外，Azure 登陸區域（ALZ）也有原則方案：設定 Azure PaaS 服務以使用私人 DNS 區域，其中包含內建原則，並定期更新。如果您的情況無法使用內建原則，請考慮在azure-policy意見反應網站 Azure 治理上建立問題。遵循 GitHub 存放庫上 Azure 原則新的內建原則提案程式社群。

第一個`DeployIfNotExists`原則 - 僅比對`groupId`

如果您建立具有服務特定 groupId的私人端點資源，就會觸發此原則。 groupId是從遠端資源（服務）取得的群組標識元，此私人端點應該連線到該群組。然後，它會觸發私人端點內的部署 privateDNSZoneGroup ，以將私人端點與私人 DNS 區域產生關聯。在範例中，groupIdAzure 儲存體 blob 的是 blob。如需其他 Azure 服務的詳細資訊groupId，請參閱子資源數據行底下的 Azure 私人端點 DNS 組態。當原則 groupId 在私人端點中找到時，它會在私人端點內部署 privateDNSZoneGroup ，並將它連結到指定為參數的私人 DNS 區域資源識別符。在此範例中，私人 DNS 區域資源識別碼為：

/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net

下列程式代碼範例顯示原則定義：

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Network/privateEndpoints"
        },
        {
          "count": {
            "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
            "where": {
              "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
              "equals": "blob"
            }
          },
          "greaterOrEquals": 1
        }
      ]
    },
    "then": {
      "effect": "deployIfNotExists",
      "details": {
        "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
        ],           
        "deployment": {
          "properties": {
            "mode": "incremental",
            "template": {
              "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
              "contentVersion": "1.0.0.0",
              "parameters": {
                "privateDnsZoneId": {
                  "type": "string"
                },
                "privateEndpointName": {
                  "type": "string"
                },
                "location": {
                  "type": "string"
                }
              },
              "resources": [
                {
                  "name": "[concat(parameters('privateEndpointName'), '/deployedByPolicy')]",
                  "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
                  "apiVersion": "2020-03-01",
                  "location": "[parameters('location')]",
                  "properties": {
                    "privateDnsZoneConfigs": [
                      {
                        "name": "storageBlob-privateDnsZone",
                        "properties": {
                          "privateDnsZoneId": "[parameters('privateDnsZoneId')]"
                        }
                      }
                    ]
                  }
                }
              ]
            },
            "parameters": {
              "privateDnsZoneId": {
                "value": "[parameters('privateDnsZoneId')]"
              },
              "privateEndpointName": {
                "value": "[field('name')]"
              },
              "location": {
                "value": "[field('location')]"
              }
            }
          }
        }
      }
    }
  },
  "parameters": {
    "privateDnsZoneId": {
      "type": "String",
      "metadata": {
        "displayName": "privateDnsZoneId",
        "strongType": "Microsoft.Network/privateDnsZones"
      }
    }
  }
}

第二個`DeployIfNotExists`原則 - 在和上比對`groupIdprivateLinkServiceId`

如果您建立具有服務特定 groupId 和 privateLinkServiceId的私人端點資源，就會觸發此原則。 groupId是從遠端資源（服務）取得的群組標識元，此私人端點應該連線到該群組。 privateLinkServiceId是遠端資源（服務）這個私人端點應該連線到的資源識別碼。然後，觸發私人端點內的部署 privateDNSZoneGroup ，以將私人端點與私人 DNS 區域產生關聯。

在這裡範例中， groupId 適用於 Azure Cosmos DB 的是 SQL ，而且 privateLinkServiceId 必須包含 Microsoft.DocumentDb/databaseAccounts。如需其他 Azure 服務的詳細資訊groupIdprivateLinkServiceId，請參閱子資源數據行底下的 Azure 私人端點 DNS 組態。當原則在私人端點中尋找 groupId 和 privateLinkServiceId 時，它會在私人端點內部署 privateDNSZoneGroup 。而且它會連結至指定為參數的私人 DNS 區域資源識別碼。下列原則定義會顯示私人 DNS 區域資源識別碼：

/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.documents.azure.com

下列程式代碼範例顯示原則定義：

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
     "allOf": [
       {
         "field": "type",
         "equals": "Microsoft.Network/privateEndpoints"
       },
       {
         "count": {
           "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*]",
           "where": {
             "allOf": [
               {
                 "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId",
                 "contains": "Microsoft.DocumentDb/databaseAccounts"
               },
               {
                 "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
                 "equals": "[parameters('privateEndpointGroupId')]"
               }
             ]
           }
         },
         "greaterOrEquals": 1
       }
     ]
   },
    "then": {
      "effect": "[parameters('effect')]",
      "details": {
        "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
        ],           
        "deployment": {
          "properties": {
            "mode": "incremental",
            "template": {
              "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
              "contentVersion": "1.0.0.0",
              "parameters": {
                "privateDnsZoneId": {
                  "type": "string"
                },
                "privateEndpointName": {
                  "type": "string"
                },
                "location": {
                  "type": "string"
                }
              },
              "resources": [
                {
                  "name": "[concat(parameters('privateEndpointName'), '/deployedByPolicy')]",
                  "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
                  "apiVersion": "2020-03-01",
                  "location": "[parameters('location')]",
                  "properties": {
                    "privateDnsZoneConfigs": [
                      {
                        "name": "cosmosDB-privateDnsZone",
                        "properties": {
                          "privateDnsZoneId": "[parameters('privateDnsZoneId')]"
                        }
                      }
                    ]
                  }
                }
              ]
            },
            "parameters": {
              "privateDnsZoneId": {
                "value": "[parameters('privateDnsZoneId')]"
              },
              "privateEndpointName": {
                "value": "[field('name')]"
              },
              "location": {
                "value": "[field('location')]"
              }
            }
          }
        }
      }
    }
  },
  "parameters": {
     "privateDnsZoneId": {
       "type": "String",
       "metadata": {
         "displayName": "Private Dns Zone Id",
         "description": "The private DNS zone to deploy in a new private DNS zone group and link to the private endpoint",
         "strongType": "Microsoft.Network/privateDnsZones"
       }
     },
     "privateEndpointGroupId": {
       "type": "String",
       "metadata": {
         "displayName": "Private Endpoint Group Id",
         "description": "A group Id for the private endpoint"
       }
     },
     "effect": {
       "type": "String",
       "metadata": {
         "displayName": "Effect",
         "description": "Enable or disable the execution of the policy"
       },
       "allowedValues": [
         "DeployIfNotExists",
         "Disabled"
       ],
       "defaultValue": "DeployIfNotExists"
     }
  }
}

原則指派

部署原則定義之後，請在管理群組階層中指定所需範圍的原則。請確定原則指派是以應用程式小組用來部署具有私人端點存取權的 PaaS 服務專用的 Azure 訂用帳戶為目標。

重要

除了指派原則中定義的 roleDefinition 之外，還記得在訂用帳戶和資源群組中指派私用 DNS 區域參與者角色角色，其中私人 DNS 區域裝載至原則指派所建立的DeployIfNotExists受控識別，該指派將負責在私人 DNS 區域中建立和管理私人端點 DNS 記錄。這是因為私人端點位於應用程式擁有者 Azure 訂用帳戶中，而私人 DNS 區域位於不同的訂用帳戶中（例如中央連線訂用帳戶）。

平臺小組完成設定之後：

應用程式小組的 Azure 訂用帳戶已可供小組使用，然後專門建立具有私人端點存取權的 Azure PaaS 服務。
小組必須確保私人端點的 DNS 記錄會自動註冊（一旦刪除私人端點後移除），從對應的私人 DNS 區域移除。

應用程式擁有者體驗

在平臺小組部署平臺基礎結構元件（私人 DNS 區域和原則）之後，當應用程式擁有者嘗試將 Azure PaaS 服務部署到 Azure 訂用帳戶時，就會有下列體驗。此體驗與它們透過 Azure 入口網站或其他用戶端執行活動相同，例如 PowerShell 或 CLI，因為 Azure 原則會控管其訂用帳戶。

透過 Azure 入口網站建立記憶體帳戶。在 [ 基本] 索引 標籤中，選擇您想要的設定、提供記憶體帳戶的名稱，然後選取 [ 下一步]。
在 [網络] 索引標籤中，選取 [私人端點]。如果您選取 [私人端點] 以外的選項，Azure 入口網站將不允許您在部署精靈的 [檢閱 + 建立] 區段中建立記憶體帳戶。如果啟用公用端點，此原則會防止您建立此服務。
您現在可以在建立記憶體帳戶之後或建立私人端點。此範例示範在建立記憶體帳戶之後建立私人端點。選取 [ 檢閱 + 建立] 以完成步驟。
建立記憶體帳戶之後，請透過 Azure 入口網站建立私人端點。
在 [資源] 區段中，找出您在上一個步驟中建立的記憶體帳戶。在 [目標子資源] 下，選取 [Blob]，然後選取 [ 下一步]。
在 [組態] 區段中，選取 VNet 和子網之後，請確定 [與私人 DNS 區域整合] 已設定為 [否]。 否則，Azure 入口網站會防止您建立私人端點。 Azure 原則不允許您建立具有privatelink前置詞的私人 DNS 區域。
選取 [ 檢閱 + 建立]，然後選取 [ 建立 ] 以部署私人端點。
幾分鐘后，原則就會 DeployIfNotExists 觸發。後續 dnsZoneGroup 部署接著會在集中管理的 DNS 區域中，為私人端點新增必要的 DNS 記錄。
建立私人端點之後，請加以選取，然後檢閱其 FQDN 和私人 IP：
檢查建立私人端點之資源群組的活動記錄檔。或者，您可以檢查私人端點本身的活動記錄檔。您會注意到幾分鐘后，原則 DeployIfNotExist 動作就會執行，並在私人端點上設定 DNS 區域群組：
如果中央網路小組移至 privatelink.blob.core.windows.net 私人 DNS 區域，他們會確認您建立的私人端點有 DNS 記錄，而且名稱和 IP 位址都符合私人端點內的值。

此時，應用程式小組可以透過中樞和輪輻網路環境及內部部署中任何 VNet 的私人端點，使用記憶體帳戶。 DNS 記錄已自動記錄在私人 DNS 區域中。

如果應用程式擁有者刪除私人端點，系統會自動移除私人 DNS 區域中的對應記錄。

下一步

檢閱內部部署和 Azure 資源的 DNS。檢閱規劃虛擬機遠端訪問。

重要

本文概述使用指派給管理群組的 DINE（DeployIfNotExists）原則大規模整合 DNS 和私人連結整合。這表示使用此方法建立私人端點時，不需要在程式代碼中處理 DNS 整合，因為原則會處理它。應用程式小組也不太可能擁有集中式私用 DNS 區域的 RBAC 存取權。

以下是使用 Bicep 和 HashiCorp Terraform 建立私人端點時所要檢閱的實用連結。

針對使用基礎結構即程式代碼建立私人端點：

快速入門：使用 Bicep 建立私人端點。

在 Terrafrom 登錄中使用 HashiCorp Terraform azurerm_private_endpoint 建立私人端點。

不過，如果您在基礎結構即程式代碼工具中建立私人端點，但如果使用本文中所述的 DINE 原則方法，您應該將 DNS 整合端排除在程式碼外，並讓具有所需 RBAC 的 DINE 原則改為處理私用 DNS 區域。

共用方式為

大規模私人連結和 DNS 整合

簡介

中樞和輪輻網路架構中的 Private Link 和 DNS 整合

平臺小組所需的設定

建立私人 DNS 區域

原則定義

第一個`DeployIfNotExists`原則 - 僅比對`groupId`

第二個`DeployIfNotExists`原則 - 在和上比對`groupIdprivateLinkServiceId`

原則指派

應用程式擁有者體驗

下一步

意見反應

其他資源

共用方式為

大規模私人連結和 DNS 整合

簡介

中樞和輪輻網路架構中的 Private Link 和 DNS 整合

平臺小組所需的設定

建立私人 DNS 區域

原則定義

第一個DeployIfNotExists原則 - 僅比對groupId

第二個DeployIfNotExists原則 - 在 和 上比對groupIdprivateLinkServiceId

原則指派

應用程式擁有者體驗

下一步

意見反應

其他資源

第一個`DeployIfNotExists`原則 - 僅比對`groupId`

第二個`DeployIfNotExists`原則 - 在和上比對`groupIdprivateLinkServiceId`