Private Link at Scale

Private Link at Scaleを理解するための前提

scale問題の中心はPE resource数より、service/subresourceごとのPrivate DNS zone ownershipとrecord lifecycle、public access policy、cross-team approvalの一貫性。 Microsoftのhub-and-spoke guidanceではPrivate DNS zonesをcentral connectivity subscriptionへ置き、application teamによるprivatelink zone乱立を抑えるmodelが示される。

Azure PolicyのdeployIfNotExists等でPrivate EndpointのgroupId/resource typeを識別し、対応するprivateDNSZoneGroupをcentral zoneへ関連付ける自動化が可能。 application teamがPortalで独自Private DNS統合を作る運用とcentral policy automationを混在させると、同名zone/record ownership競合を起こしやすい。

public endpoint denyはPE DNS自動化とは別policy。Private Link導入を理由に全serviceを一律denyせず、service dependencyとbreak-glassを設計する。 central DNSはzoneを一箇所に置くだけでは成立しない。spoke/on-premからcentral authorityへ至るVNet link/ruleset/inbound resolver pathを明示する。

通信や判断の流れを追う

ClientDNS queryResolver / Private DNSPrivate endpointService

Control plane / DNS plane / Data plane

Platform team

Private DNS zone catalog、Resolver、policy definitions/assignments、RBAC、shared monitoringを所有。

Application team

PaaS resourceとPEを要求し、正しいgroupId/subresource、network requirement、public access要否を申告。

Automation contract

resource type + groupId → central zone resource ID → privateDNSZoneGroupを決定。exceptionsは明示的に記録。

判定順序まず client がどの resolver を使い何IPを得たか固定し、そのIPに対するroute/securityを確認します。DNSを確認せずroute tableだけを見る、またはprivate IPを得ただけでservice到達済みと判定するのは避けます。

Query / packet path

platform teamがPrivate Link対応serviceのresource type/groupId/private zone mappingをcatalog化する。
central connectivity subscriptionへ必要なPrivate DNS zonesとResolver/rulesetを配置する。
Policyでprivatelink zone乱立やpublic endpoint policyを必要範囲でguardする。
application teamがPaaS resource/PEをdeployする。
Policy/IaCがPEのgroupIdを判定し、central zoneへのprivateDNSZoneGroupをdeployする。
spoke/on-premのresolver pathからFQDN→PE private IPを確認し、service public access/authorizationも別に検証する。
inventory/drift jobでorphan PE、Pending connection、zone group欠落、duplicate zone、public access exceptionを継続監査する。

仕組みを分解する

大規模環境では、Private DNS zoneを「各application subscriptionにPEと一緒に自動作成」すると一見self-serviceですが、同じprivatelink namespaceが複数のauthorityに分裂しやすくなります。Microsoftのscale guidanceはplatform-managed central zoneとPolicyによるzone group連携を例示しています。重要なのは特定のPolicy JSONを固定コピーすることではなく、resource type/groupId/zone mappingをcurrent docsから更新できるcatalogと、application teamが勝手にauthorityを増やさないgovernanceを持つことです。

設計判断

判断軸	設計方針
Zone ownership	privatelink.* zoneはplatform-ownedをdefaultにし、例外zoneはreason/owner/expiryを持つ。
Policy blast radius	DenyとDeployIfNotExistsを同時導入せず、audit→remediation→denyの段階を設ける。
Cross-subscription RBAC	Policy managed identityがcentral zone group連携に必要な権限を持つ範囲を最小化し、role assignmentを監査する。
Service catalog lifecycle	Azureが新subresource/zoneを追加するため、Microsoft Learn zone valuesを定期reviewしてpolicy mappingを更新する。

確認手順

Read-only verification

代表serviceごとにresource type/groupId→central zone resource IDのmapping testを自動化する。
新PE作成後、zone groupが自動作成されA recordがcentral zoneに現れることを確認する。
spokeとon-prem双方でsame FQDNがexpected PE IPへ解決されることを確認し、central zoneが存在するだけで完了にしない。
public access deny policyは許可/拒否のnegative testをservice categoryごとに行い、break-glass pathも監査する。

Evidence to keep

resource ID / subscription / region / VNet / subnetを固定し、同名resource取り違えを防ぐ。
DNS queryはresolver IP、query name、answer/CNAME、TTL、timestampを一緒に保存する。
network testはsource、resolved destination IP、protocol/port、winning route/security decisionを保存する。
変更前後で同じquery/application journeyを再実行し、cache/既存sessionでの見かけ上成功を避ける。

Azure CLI / client — read-only first

az network private-endpoint list --query "[].{name:name,rg:resourceGroup,state:privateLinkServiceConnections[0].privateLinkServiceConnectionState.status}" -o table
az network private-dns zone list -o table
az policy assignment list -o table
az network private-endpoint dns-zone-group list -g <app-rg> --endpoint-name <private-endpoint> -o jsonc

PowerShell — read-only first

Get-AzPrivateEndpoint | Select-Object Name,ResourceGroupName,Location
Get-AzPrivateDnsZone
Get-AzPolicyAssignment
Get-AzPrivateDnsZoneGroup -ResourceGroupName <app-rg> -PrivateEndpointName <private-endpoint>

障害切り分け

症状	第一候補	証拠	次の確認
PEはあるがzone groupなし	Policy assignment/identity/remediation不全	Policy compliance + PE child resource	assignment scope/RBAC/mapping確認
同名zoneが多数subscriptionに存在	decentralized auto-create	private DNS zone inventory	central authorityへ段階統合
新serviceだけDNS automation失敗	catalogにgroupId/zone未登録	PE groupIdsとcurrent zone values	mapping更新
Policyでdeploymentが突然拒否	deny scope過大/Portal統合競合	Policy evaluation detail	audit段階/exception設計を見直す
on-premだけ解決不可	central resolver path不足	conditional forwarder/inbound endpoint	hybrid DNS path修正

変更時の確認と rollback

Policy変更前にassignment/version/parametersとcompliance snapshotを保存する。
Deny policy rollbackだけでなく、DeployIfNotExistsが作成したzone group/recordを消すか残すかを明示する。
central zone統合はold zoneを即削除せず、client resolver pathを切替・検証してからauthorityを整理する。
automation停止時のmanual fallbackは一時措置としてowner/expiryを付け、恒久的なrecord driftを残さない。

Current notes — 2026-09-11

Current behavior / guidance

Private Link at scaleのMicrosoft guidanceは、central Private DNS zonesとAzure PolicyでDNS integrationを自動化する考え方を示します。個別のPolicy schemaやservice groupIdは変化するため、2026-09-11時点のcurrent mappingをsource-of-truthとして扱い、固定の古い例へ依存しない構成にします。