Eigener Dienst soll Private Link anbieten? Private Link Service konfigurieren

Veröffentlicht am: 13. August 2026

Private Endpoints sind nicht auf Microsoft-PaaS-Ressourcen beschränkt. Ein Service Provider kann eine eigene Anwendung hinter einem Standard Load Balancer platzieren und ein internes Frontend über Azure Private Link Service veröffentlichen.

Erstelle diesen Provider-und-Consumer-Pfad für den vorhandenen CloudTrips-Webdienst:

WEB02 Consumer
    |
    v
Private Endpoint in snet-data
    |
    | Azure Private Link
    v
Private-Link-Service-NAT-IP in snet-pls
    |
    v
Internes Load-Balancer-Frontend -> WEB01 / WEB02

Dieser Trip baut auf Eine Webanwendung benötigt Traffic-Verteilung? Load Balancer erstellen und Storage muss privat bleiben? Private Endpoint erstellen auf. Behalte beide Web-VMs und ihre laufenden HTTP-Dienste, vnet-cloudtrips-test-weu und snet-data. Der vorhandene öffentliche Load Balancer bleibt unverändert; dieser Trip erstellt einen separaten internen Load Balancer, weil dessen Frontend eine private VNet-Adresse verwenden muss.

Provider und Consumer verstehen

Private Link verbindet zwei Rollen:

Der Provider betreibt einen Dienst und stellt ihn privat bereit. Hier stellt CloudTrips die Website auf WEB01 und WEB02 bereit. Der Provider erstellt Load Balancer und Private Link Service.
Der Consumer möchte diesen Dienst aus seinem eigenen Netzwerk aufrufen. Der Consumer erstellt einen Private Endpoint. Dadurch erhält der Dienst des Providers eine private IP-Adresse im VNet des Consumers.

In einem echten Design sind Provider und Consumer häufig unterschiedliche Unternehmen, Subscriptions oder VNets. Beispielsweise stellt ein Softwareunternehmen eine private API bereit, die ein Kunde ohne Traffic über das Internet verwendet.

Consumer-Netzwerk                         Provider-Netzwerk
----------------                         -----------------
Client                                    WEB01 / WEB02
  |                                             ^
  v                                             |
Private Endpoint -- Azure Private Link --> Private Link Service
                                                ^
                                                |
                                      Interner Load Balancer

Dieses kostengünstige Lab platziert beide Rollen in derselben Subscription und demselben VNet. WEB01 und WEB02 bleiben die Anwendungsserver des Providers; WEB02 wird nach dem Erstellen des Consumer Private Endpoints in snet-data zusätzlich als Test-Client verwendet. Die Wiederverwendung einer VM macht die Rollen optisch weniger deutlich, die Azure-Ressourcen haben aber weiterhin getrennte Aufgaben:

Ressource	Rolle
`pls-cloudtrips-web-test-weu`	Provider veröffentlicht den Dienst
`pep-cloudtrips-custom-web-test-weu`	Consumer verbindet sich mit dem veröffentlichten Dienst

Private Link Service führt Source NAT durch, damit überlappende Provider- und Consumer-Adressräume keine Mehrdeutigkeit verursachen. Die Anwendung sieht normalerweise die NAT-Adresse des Private Link Service und nicht die ursprüngliche private IP-Adresse des Consumers.

Die letzten drei Trips vergleichen

Die beiden vorherigen Trips verbanden sich mit Azure Storage, einem Microsoft-eigenen PaaS-Dienst. Dieser Trip verwendet dieselbe Private-Link-Plattform anders: Du bist der Provider und veröffentlichst deinen eigenen Dienst auf VMs.

Frage	Storage Private Endpoint	Storage Service Endpoint	Eigener Private Link Service
Wem gehört der Dienst?	Microsoft betreibt Azure Storage	Microsoft betreibt Azure Storage	CloudTrips betreibt WEB01 und WEB02
Wodurch verbindet sich der Client?	Private Endpoint	Service-Endpoint-Route	Private Endpoint zum Private Link Service des Providers
Zieladresse	Private IP im Consumer-VNet	Öffentliche Storage-IP	Private IP im Consumer-VNet
DNS-Verhalten	Private DNS löst Storage zur privaten IP auf	DNS löst weiterhin zu einer öffentlichen Storage-IP auf	Eigenes DNS ist optional; dieses Lab testet direkt über die private IP
Zugriffskontrolle auf Provider-Seite	Storage genehmigt die Private-Endpoint-Verbindung	Storage Firewall erlaubt `snet-app`	CloudTrips genehmigt die Private-Endpoint-Verbindung
Load Balancer erforderlich?	Nein	Nein	Ja, für den eigenen Dienst in diesem Lab
Öffentlicher Endpunkt erforderlich?	Nein; der öffentliche Storage-Zugriff wurde deaktiviert	Ja; er bleibt öffentlich, wird aber durch die Storage Firewall beschränkt	Für Private-Link-Consumer ist kein öffentlicher Endpunkt erforderlich

Verwende einen Private Endpoint für Azure Storage, wenn eine Microsoft-PaaS-Ressource privat in deinem VNet erscheinen soll. Verwende einen Service Endpoint, wenn der Zugriff auf den öffentlichen PaaS-Endpunkt über das Azure Backbone mit einer einfacheren subnetzbasierten Zugriffskontrolle ausreicht. Verwende Private Link Service, wenn du die Anwendung besitzt und anderen Consumern Zugriff über deren Private Endpoints ermöglichen möchtest.

Private Link Service und Private Endpoints verursachen Kosten für Bereitstellungszeit und verarbeitete Daten. Entferne dieses Lab nach dem Test.

NAT-Subnetz für Private Link Service erstellen

Öffne Virtual networks > vnet-cloudtrips-test-weu > Settings > Subnets, wähle + Subnet und konfiguriere:

Name: snet-pls
Starting address: 10.20.5.0
Subnet size: /24
Default outbound access: Disabled
Private link service network policy: Disabled

Lass Delegation, NSG, Route Table, NAT Gateway und Service Endpoints unkonfiguriert. 10.20.5.0/24 überschneidet sich weder mit snet-app unter 10.20.1.0/24, snet-data unter 10.20.2.0/24 noch mit dem Application-Gateway-Subnetz unter 10.20.4.0/24. Wähle Save.

Dediziertes snet-pls-Subnetz mit deaktivierten Private-Link-Service-Netzwerkrichtlinien

Die entsprechenden CLI-Befehle lauten:

az network vnet subnet create \
  --resource-group rg-cloudtrips-network-test-weu \
  --vnet-name vnet-cloudtrips-test-weu \
  --name snet-pls \
  --address-prefixes 10.20.5.0/24 \
  --default-outbound false

az network vnet subnet update \
  --resource-group rg-cloudtrips-network-test-weu \
  --vnet-name vnet-cloudtrips-test-weu \
  --name snet-pls \
  --disable-private-link-service-network-policies true

Separaten internen Load Balancer erstellen

Der vorhandene lb-cloudtrips-web-test-weu ist ein öffentlicher Load Balancer. Seine Seite Add frontend IP configuration verlangt daher eine öffentliche IP-Adresse und zeigt keine VNet- oder Subnetzfelder. Füge dort kein Frontend hinzu.

Suche nach Load balancers, wähle Create > Standard Load Balancer und konfiguriere Basics:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: lb-cloudtrips-private-link-test-weu
Region: West Europe
SKU: Standard
Type: Internal
Tier: Regional

Füge unter Frontend IP configuration hinzu:

Name: fe-cloudtrips-private-link-test-weu
Virtual network: vnet-cloudtrips-test-weu
Subnet: snet-app
IP address assignment: Dynamic
Availability zone: Zone-redundant, falls verfügbar

Füge unter Backend pools den Pool be-cloudtrips-private-link-test-weu für vnet-cloudtrips-test-weu mit NIC-Konfiguration hinzu. Füge die primären IP-Konfigurationen von WEB01 und WEB02 zu diesem Pool hinzu. Eine VM-NIC kann an Backend Pools mehrerer Load Balancer teilnehmen. Dadurch werden die VMs nicht aus dem vorhandenen öffentlichen Load Balancer entfernt.

Füge unter Inbound rules eine Load-Balancer-Regel hinzu und erstelle ihre Health Probe:

Name: rule-private-link-http-80
IP version: IPv4
Frontend IP address: fe-cloudtrips-private-link-test-weu
Backend pool: be-cloudtrips-private-link-test-weu
Protocol: TCP
Port: 80
Backend port: 80
Health probe: Create new
Health probe name: probe-private-link-tcp-80
Health probe protocol: TCP
Health probe port: 80
Session persistence: None
Idle timeout: 15 minutes
TCP reset: Enabled
Floating IP: Disabled

Wähle Review + create > Create. Öffne den bereitgestellten internen Load Balancer und bestätige, dass beide Web-Backends fehlerfrei sind. Diese Inbound-Regel konfiguriert keinen ausgehenden Internetzugriff für die Backend-VMs. Outbound-Konnektivität liegt außerhalb dieses Labs und wird zum Bereitstellen der Testseite nicht benötigt.

Separater interner Load Balancer mit privatem Frontend und beiden Web-VMs im Backend Pool

Private Link Service erstellen

Suche nach Private link services, wähle + Create und konfiguriere Basics:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: pls-cloudtrips-web-test-weu
Region: West Europe

Konfiguriere unter Outbound settings:

Load balancer: lb-cloudtrips-private-link-test-weu
Load balancer frontend IP address: fe-cloudtrips-private-link-test-weu
Source NAT virtual network: vnet-cloudtrips-test-weu
Source NAT subnet: snet-pls
Enable TCP proxy V2: No
Private IP address allocation: Dynamic

Beschränke Visibility für dieses Lab auf die aktuelle Subscription. Lass Auto-approval leer, damit der Provider Consumer-Anfragen ausdrücklich genehmigen muss. Wähle Review + create > Create.

Private-Link-Service-Outbound-Einstellungen mit internem Load-Balancer-Frontend und snet-pls

Öffne nach dem Deployment die Übersicht und kopiere den Alias. Consumer können diesen Alias verwenden, ohne Zugriff auf Subscription oder Resource IDs des Providers zu erhalten.

Consumer Private Endpoint erstellen

In einem Produktionsdesign gehört der Private Endpoint normalerweise zu einem separaten Consumer-VNet, häufig sogar in einer anderen Subscription oder einem anderen Tenant. Dieses Lab verwendet das vorhandene CloudTrips-VNet erneut, um ein zusätzliches VNet und eine weitere Test-VM zu vermeiden. Deshalb simuliert snet-data das Consumer-Netzwerk, während snet-app und snet-pls die Provider-Seite darstellen:

vnet-cloudtrips-test-weu
├── snet-data → simulierter Consumer Private Endpoint
├── snet-app  → Provider Load Balancer und Web-VMs
└── snet-pls  → NAT-Adressen des Provider Private Link Service

Die Rollen bleiben getrennt, obwohl die Subnetze dasselbe VNet verwenden. Ein realistisches Deployment würde den Private Endpoint in einem Consumer-eigenen VNet wie vnet-cloudtrips-consumer-test-weu platzieren und ihn ohne VNet-Peering mit diesem Provider Private Link Service verbinden. Der Consumer erstellt den Private Endpoint, weil er eine lokale private IP-Adresse benötigt, die den Dienst des Providers im eigenen Netzwerk repräsentiert.

Suche nach Private endpoints, wähle + Create und konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: pep-cloudtrips-custom-web-test-weu
Network interface name: nic-pep-cloudtrips-custom-web-test-weu
Region: West Europe

Wähle unter Resource die Option Connect to an Azure resource by resource ID or alias, füge den Alias des Private Link Service ein und trage ein:

Request message: CloudTrips consumer lab

Konfiguriere unter Virtual Network:

Virtual network: vnet-cloudtrips-test-weu
Subnet: snet-data
Private IP configuration: Dynamically allocate IP address

Für einen eigenen Dienst wird keine von Azure verwaltete Private-DNS-Zone angeboten. Wähle Review + create > Create.

Consumer Private Endpoint in snet-data für den eigenen Private Link Service

Consumer-Verbindung genehmigen

Öffne Private link services > pls-cloudtrips-web-test-weu > Private endpoint connections. Markiere die ausstehende Verbindung, wähle Approve, ergänze optional eine Beschreibung und bestätige.

Der Consumer Endpoint sollte zu Approved wechseln. Die Genehmigung ist die Consent-Grenze des Providers. Ohne Auto-Approval erhält ein Consumer durch das Erstellen eines Private Endpoints nicht automatisch Zugriff.

Genehmigte Consumer-Private-Endpoint-Verbindung im Private Link Service

Überprüfe den Status mit der CLI:

az network private-link-service show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name pls-cloudtrips-web-test-weu \
  --query '{State:provisioningState,Alias:alias,Connections:privateEndpointConnections[].privateLinkServiceConnectionState.status}' \
  --output yaml

Erwarte State: Succeeded und eine Verbindung mit Approved.

Eigenen Dienst privat testen

Lies die private IP-Adresse des Endpoints:

CUSTOM_SERVICE_NIC=$(az network private-endpoint show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name pep-cloudtrips-custom-web-test-weu \
  --query 'networkInterfaces[0].id' \
  --output tsv)

CUSTOM_SERVICE_IP=$(az network nic show \
  --ids "$CUSTOM_SERVICE_NIC" \
  --query 'ipConfigurations[0].privateIPAddress' \
  --output tsv)

printf 'Custom service private IP: %s\n' "$CUSTOM_SERVICE_IP"

Starte WEB02 bei Bedarf und rufe die Adresse aus dem VNet auf:

az vm start \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu

az vm run-command invoke \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --command-id RunShellScript \
  --scripts "for request in 1 2 3 4 5 6; do curl --silent --show-error --connect-timeout 5 http://${CUSTOM_SERVICE_IP}/; done"

Die Ausgabe sollte Antworten von WEB01, WEB02 oder beiden enthalten. Die Anfrage trat über den Consumer Private Endpoint ein, überquerte Private Link, erreichte das interne Load-Balancer-Frontend und wurde an ein fehlerfreies Backend verteilt.

WEB02 erhält Antworten des eigenen Webdienstes über den Private-Link-Service-Endpunkt

Private-Link-Service-Lab behalten oder entfernen

Deallokiere WEB02 nach dem Test. Lösche dieses Lab bei Bedarf in dieser Reihenfolge:

pep-cloudtrips-custom-web-test-weu
pls-cloudtrips-web-test-weu
lb-cloudtrips-private-link-test-weu
snet-pls

Behalte den vorhandenen öffentlichen Load Balancer, VMs, VNet und snet-data, weil andere Networking-Trips sie verwenden.