Azure Private Link

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

Private Linkはconsumer VNet内のPrivate Endpointを入口にし、Azure PaaSまたはPrivate Link ServiceへMicrosoft backbone上で到達させる仕組み。public Internetをdata pathに必要としない。 Private Endpointはconsumer側のprivate IP/NIC。Private Link Serviceはprovider側が自分のserviceをPrivate Linkで公開するときの別resourceで、同じものではない。

接続はconsumerからserviceへ開始される方向が基本。Private Linkを作ったことでproviderからconsumer VNetへ任意に接続できるようになるわけではない。 Private Linkでnetwork pathをprivate化しても、resourceのpublic network access、application authentication/authorization、data-plane RBACは別controlとして確認する。

Private Endpointは特定のtarget subresourceへ接続する。Storageのblob/file/dfsなど、同じresourceでも必要なsubresourceとDNS zoneが異なる場合がある。実運用では「connection approval」「DNS resolution」「routing/security」「service authorization」を分離して観測し、どこで失敗しているかを固定する。

通信や判断の流れを追う

ClientDNS queryResolver / Private DNSPrivate endpointService

Control plane / DNS plane / Data plane

Consumer control plane

Private Endpoint、subnet、target resource/subresource、connection approval、DNS zone groupを構成。

Data plane

clientがservice FQDNをPrivate Endpoint IPへ解決し、そのprivate IP宛trafficをPrivate Link mapping経由でserviceへ送る。

Provider / service plane

Azure PaaSまたはPrivate Link Serviceが接続要求を承認し、service固有のnetwork/public accessとapplication authorizationを適用。

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

Query / packet path

client applicationは通常、serviceの既存FQDNへ接続する。
DNSがCNAME chain/Private DNS zoneを通じてPrivate Endpointのprivate IPを返す。
source VNet/peered VNet/on-premisesから、そのprivate IPへのrouteとsecurity判定が行われる。
packetはconsumer subnetのPrivate Endpointへ到達し、Private Linkのmappingで指定したservice/subresourceへ運ばれる。
service側ではPrivate Link connection stateに加え、service firewall/public network settingやidentity/data-plane authorizationが評価される。
responseはPrivate Link経由でclientへ戻る。stateful middleboxを挟む設計ではreturn path symmetryも別途確認する。

仕組みを分解する

Private Linkは「Azure service全体をVNetへ移設する」機能ではありません。consumerから見える接続点としてprivate IPを持つPrivate Endpointを作り、serviceへのmappingを確立します。したがって障害時は、Private Endpoint resourceがApprovedでもDNSがpublic IPを返していればprivate pathは使われず、逆にDNSがprivate IPを返していてもservice authorizationで拒否されれば接続は成立しません。network planeとservice planeを同一のgreen/red状態に潰さないことが重要です。

設計判断

判断軸	設計方針
Private Linkを選ぶ要件	on-premises/peered VNetを含むprivate IP到達、service instance単位のprivate access、public exposure最小化が必要なら第一候補。
provider boundary	自社serviceを他VNet/tenantへprivateに公開する場合はPrivate Link Serviceの設計が加わる。consumer PEだけのPaaS利用と混同しない。
DNS ownership	service別推奨privatelink zoneとsubresource mappingをplatform catalog化し、application teamが場当たり的に同名zoneを作らない。
security ownership	public access disable、Private Endpoint network policy、service identity/RBAC、loggingを別owner/別evidenceとしてchange recordへ残す。

確認手順

Read-only verification

Private Endpointのconnection stateがApprovedであることと、target resource/subresourceが意図したresource ID/groupIdであることを別々に確認する。
clientが実際に使うresolverからFQDNを引き、最終A/AAAAが期待するPE private IPか確認する。
resolved private IPに対するeffective route/NSG、必要ならfirewall sessionを確認し、public IP宛試験で代用しない。
service側のpublic network accessとapplication/data-plane認証を確認する。Private Link成功と認証成功を混同しない。

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 -g <rg> -o table
az network private-endpoint show -g <rg> -n <private-endpoint> -o jsonc
az network private-endpoint ip-config list -g <rg> --endpoint-name <private-endpoint> -o table
az network private-endpoint dns-zone-group list -g <rg> --endpoint-name <private-endpoint> -o jsonc

PowerShell — read-only first

Get-AzPrivateEndpoint -ResourceGroupName <rg> -Name <private-endpoint>
Get-AzPrivateDnsZoneGroup -ResourceGroupName <rg> -PrivateEndpointName <private-endpoint>

障害切り分け

症状	第一候補	証拠	次の確認
PEがApprovedなのにpublicへ出る	DNSがpublic answer	nslookup/digのCNAME/A chain	Private DNS zone/link/forwarderを修正
DNSはprivate IPだがtimeout	route/NSG/UDR/middlebox	effective route、NSG、packet capture	private IPを基準にforward/return pathを確認
TCPは成立するが403/authorization error	service plane authorization	service diagnostic/auth log	RBAC/key/token/firewall/public accessを確認
別VNet/on-premだけpublic answer	resolver pathの差	各場所から同一FQDN照会	zone linkまたはPrivate Resolver/conditional forwarderを確認
意図しないresourceへ接続	target subresource/resource取り違え	PE connectionのresource ID/groupIds	接続を作り直す前に影響範囲とDNS recordを固定

変更時の確認と rollback

変更前にPE resource ID、private IP、connection state、DNS zone group、対象FQDN結果を保存する。
DNS変更とPE削除を同時に行わず、どちらが通信へ影響したか追跡できる順序で戻す。
PE削除時はzone groupが管理していたrecord lifecycleも確認し、古いA recordを手作業で残さない。
public accessを一時復旧に使う場合は期限・source restriction・戻し条件を明文化し、恒久的なsecurity regressionにしない。

Current notes — 2026-09-11

Current behavior / guidance

2026-09-11時点のMicrosoft LearnではPrivate LinkはPaaS/private serviceへのprivate accessの中心機能として位置付けられています。設計時はPrivate Endpointそのものだけでなく、DNSとservice側public access/authorizationまで一体のacceptance criteriaにします。