Azure OpenAI Private Endpoint: DNS und Landing Zone

Eine Azure-OpenAI- oder Microsoft-Foundry-Ressource ist im Moment ihrer Erstellung über das öffentliche Internet erreichbar - mit gültigem API-Key oder passender Entra-ID-Rolle kann grundsätzlich jeder Client der Welt eine Anfrage an sie stellen. Für viele Testumgebungen ist das kein Problem. Für Workloads mit personenbezogenen Daten, für regulierte Branchen oder schlicht für jede Sicherheitsvorgabe, die verlangt, dass produktive Dienste nicht am öffentlichen Internet hängen, ist es das dagegen sehr wohl.

Die Lösung heißt Private Endpoint: Die Ressource verschwindet aus dem öffentlichen Internet und wird ausschließlich über eine private IP-Adresse in Ihrem eigenen virtuellen Netzwerk erreichbar. Technisch ist das gut dokumentiert und in wenigen Schritten konfiguriert. Der Teufel steckt trotzdem im Detail - vor allem beim DNS, wo eine Foundry-Ressource nicht eine, sondern bis zu drei verschiedene Domains bedient, und bei der Frage, wer nach der Abschottung überhaupt noch an die Ressource herankommt: Entwicklerinnen am Laptop, CI/CD-Pipelines, oder Claude Code auf einem Build-Agenten. Dieser Artikel ordnet Konfiguration, DNS-Fallstricke und die Architektur- und Betriebsfragen ein, die mit Netzwerkisolation für Azure-KI-Dienste zwangsläufig mitkommen.

Private Endpoints sind dabei die eine Hälfte einer Zwei-Fragen-Antwort: Sie regeln, von wo auf eine Ressource zugegriffen werden darf. Die andere Hälfte - wer zugreifen darf, sobald die Anfrage im Netzwerk angekommen ist - regelt Managed Identity statt API-Keys. Beide Kontrollen sind unabhängig voneinander sinnvoll, entfalten ihre volle Wirkung aber erst gemeinsam.

Warum der Standardzugriff bei Azure-KI-Diensten ein Compliance-Problem sein kann

Microsoft dokumentiert den Ausgangszustand unmissverständlich: „By default, Foundry Tools resources accept connections from clients on any network.” Das gilt für Azure OpenAI, für Foundry-Ressourcen und für die übrigen Foundry Tools (Speech, Vision, Language, Content Safety) gleichermaßen - sie alle laufen technisch auf demselben Ressourcentyp Microsoft.CognitiveServices/accounts. Authentifizierung über einen API-Key oder eine Entra-ID-Rolle ist zwar weiterhin Pflicht, aber sie ersetzt keine Netzwerksegmentierung: Ein durchgesickerter Key ist von jedem beliebigen Internetanschluss aus nutzbar, solange die Ressource öffentlich erreichbar bleibt.

Für viele Sicherheitsvorgaben - etwa ein Vorgabenkatalog, der verlangt, dass produktive Datenverarbeitung ausschließlich innerhalb eines definierten Netzwerkperimeters stattfindet - reicht „Authentifizierung ist aktiviert” deshalb nicht aus. Verlangt wird dort in aller Regel, dass die Ressource technisch gar nicht erst öffentlich ansprechbar ist. Genau das leistet ein Private Endpoint in Kombination mit dem Abschalten des öffentlichen Netzwerkzugriffs.

Was ein Private Endpoint für Foundry- und Azure-OpenAI-Ressourcen technisch bewirkt

Ein Private Endpoint ist eine eigene Netzwerkschnittstelle in Ihrem virtuellen Netzwerk, die eine IP-Adresse aus Ihrem eigenen Adressraum bekommt und über Azure Private Link mit der Zielressource verbunden wird. Der Datenverkehr zwischen Client und Ressource läuft dabei über das Microsoft-Backbone-Netzwerk statt über das öffentliche Internet - auch wenn beide Seiten technisch in Azure liegen.

Microsoft unterscheidet für Foundry-Ressourcen ausdrücklich zwischen zwei Isolationsrichtungen: Inbound-Zugriff auf die Ressource (etwa durch Data-Scientist-Teams) und Outbound-Zugriff von der Ressource aus, etwa wenn ein Agent auf andere Azure-Dienste zugreift. Für den in diesem Artikel behandelten Kern - den Zugriff auf die Ressource absichern - ist die relevante Stellschraube das Public Network Access (PNA)-Flag. Es kennt drei Zustände: „All networks” (Standard), „Selected networks” (Zugriff nur von bestimmten IP-Adressen oder virtuellen Netzwerken) und „Disabled” - nur noch über einen genehmigten Private Endpoint erreichbar.

Wichtig für die Erwartungshaltung: Ein Private Endpoint allein macht eine Ressource nicht automatisch privat. Solange „All networks” aktiv bleibt, existiert der öffentliche Zugriffsweg parallel zum privaten weiter. Erst das Deaktivieren des öffentlichen Netzwerkzugriffs schließt diesen Weg. Umgekehrt gilt auch das Gegenteil: Entfernen Sie einen Private Endpoint wieder, wird die Ressource dadurch nicht automatisch öffentlich - Microsoft weist in der eigenen Dokumentation ausdrücklich darauf hin, dass dafür ein separater Schritt nötig ist.

Öffentlichen Netzwerkzugriff deaktivieren: Portal, Bicep und Terraform

Im Portal läuft die Konfiguration über den Tab Networking der Ressource. Bei einer neuen Foundry-Ressource wählen Sie dort während der Erstellung die Option Disabled für den öffentlichen Zugriff und legen anschließend im Abschnitt „Private endpoint” den Endpoint direkt mit an. Bei einer bestehenden Ressource führt der Weg über Resource Management → Networking → Private endpoint connections → + Private endpoint.

Für beide Wege gelten dieselben Rahmenbedingungen:

Der Private Endpoint muss in derselben Region und Subscription wie das virtuelle Netzwerk liegen.
Nur Private Endpoints im Zustand Approved können Datenverkehr zur Zielressource senden. Ohne Contributor- oder Owner-Rolle auf der Ressource bleibt die Verbindung im Zustand Pending, bis der Ressourcen-Owner sie freigibt.
Für das Anlegen selbst braucht es Network Contributor (oder äquivalent) auf dem virtuellen Netzwerk; wer eigene Private-DNS-Zonen pflegt, zusätzlich Private DNS Zone Contributor auf der jeweiligen Zone.
Der IP-Adressbereich 172.17.0.0/16 ist für Docker-Bridge-Networking reserviert und sollte im virtuellen Netzwerk nicht verwendet werden.

Für Infrastructure-as-Code stellt Microsoft ein Azure-Verified-Module (AVM) für Microsoft.CognitiveServices/accounts bereit, das privateEndpoints inklusive privateDnsZoneGroup- und subnetResourceId-Parametern direkt unterstützt - referenzierbar über br/public:avm/res/cognitive-services/account:<version>. Für den kompletten Netzwerkisolations-Stack (Standard- und Basic-Setup, inklusive Agent-Service-VNet-Injection) veröffentlicht Microsoft im foundry-samples-Repository außerdem fertige Bicep-Vorlagen, unter anderem 11-private-network-basic-vnet und 15-private-network-standard-agent-setup.

Eine Einschränkung, die beim Planen leicht übersehen wird: Ist die Ressource bereits mit Virtual Network Injection für ausgehenden Traffic (etwa für Agent Service) aufgesetzt, lässt sich das nachträglich nicht mehr ändern - Microsoft dokumentiert das ausdrücklich als „you cannot update your outbound networking settings currently”. Wer Outbound-Isolation nachrüsten will, muss die Foundry-Ressource neu aufsetzen.

Die DNS-Falle: drei FQDNs, drei Private-DNS-Zonen

Sobald der öffentliche Zugriff deaktiviert ist, verschiebt sich das Problem vom Netzwerk auf das DNS - und hier liegt der Stolperstein, der Private-Endpoint-Projekte am häufigsten verzögert. Beim Anlegen des Private Endpoints ändert Azure den CNAME-Eintrag der Ressource auf einen Alias unterhalb des privatelink-Subdomains und legt bei Nutzung der empfohlenen Namenskonvention automatisch eine passende Private DNS Zone mit den zugehörigen A-Einträgen an. Clients außerhalb des virtuellen Netzwerks lösen den Endpunkt weiterhin auf die öffentliche IP auf; Clients innerhalb des verlinkten virtuellen Netzwerks bekommen die private IP - dieselbe Connection-String funktioniert also für beide Seiten, nur das Ziel unterscheidet sich.

Der Punkt, der bei Foundry-Ressourcen regelmäßig übersehen wird: Eine Foundry-Ressource (kind: AIServices) bedient nicht eine, sondern drei separate FQDN-Muster - mit jeweils eigener Private DNS Zone. Microsofts eigene Referenztabelle für Private-Endpoint-DNS-Zonen benennt das ausdrücklich:

FQDN-Muster	Private-DNS-Zone	Relevant für
`*.openai.azure.com`	`privatelink.openai.azure.com`	Azure-OpenAI-Ressourcen (`kind: OpenAI`) sowie den weiterhin funktionierenden Azure-OpenAI-Endpunkt einer Foundry-Ressource
`*.cognitiveservices.azure.com`	`privatelink.cognitiveservices.azure.com`	Alle `Microsoft.CognitiveServices/accounts`-Ressourcen, unabhängig vom `kind`
`*.services.ai.azure.com`	`privatelink.services.ai.azure.com`	Foundry-Ressourcen (`kind: AIServices`) - Foundry-Portal, Projekt- und Agent-Zugriff

Microsoft kommentiert das in einer Fußnote der Referenztabelle so: „A Foundry resource can expose all three endpoints. Configure DNS for each endpoint that your workload uses.” Genau darin liegt das Risiko: Wer nur die Zone anlegt, die beim ersten Test funktioniert hat - meist openai.azure.com, weil bestehender Code darauf zeigt - , merkt oft erst später, dass ein SDK, ein Foundry-Portal-Aufruf oder ein Agent-Feature den Endpunkt services.ai.azure.com nutzt und ins Leere läuft, weil die passende Zone fehlt. Für unser bereits erschienenes Stück zur Umbenennung von Azure AI Foundry war genau das ein zentraler Fallstrick: Nach einem Upgrade einer Azure-OpenAI-Ressource auf kind: AIServices kommen die beiden zusätzlichen FQDNs hinzu, ohne dass ein bereits bestehender Private Endpoint sie automatisch mitbedient - er muss dafür neu erstellt werden, damit die passenden IP-Konfigurationen entstehen. Wer umgekehrt frisch mit einer Foundry-Ressource startet, sollte von Anfang an alle drei Zonen einplanen, statt sie nachträglich einzeln nachzuziehen.

Zwei weitere Details aus der offiziellen DNS-Dokumentation sind für den Betrieb wichtig:

Rufen Sie niemals die interne *.privatelink.openai.azure.com-URL direkt auf - sie ist Teil der internen CNAME-Auflösungskette. Clients müssen weiterhin die reguläre Custom-Subdomain der Ressource als Endpunkt-URL verwenden.
Wer einen eigenen DNS-Server statt der automatisch erzeugten Private DNS Zone betreibt, muss die privatelink-Subdomain auf die Private DNS Zone des virtuellen Netzwerks delegieren - alternativ die passenden A-Einträge manuell im eigenen DNS-Server pflegen und die öffentlichen Forwarder-Namen (cognitiveservices.azure.com, openai.azure.com, services.ai.azure.com) entsprechend weiterleiten.

Private Endpoint bei Claude: sichert die Foundry-Ressource, nicht den Weg zu Anthropic

Für Unternehmen, die neben OpenAI-Modellen auch Claude über Foundry einsetzen, stellt sich zusätzlich die Frage, ob Netzwerkisolation bei beiden Claude-Hosting-Varianten gleich funktioniert. Unsere separate Einordnung beschreibt die beiden Hosting-Varianten von Claude in Microsoft Foundry im Detail - dort finden sich auch die Unterschiede bei Datenresidenz, verfügbaren Deployment-Typen und API-Funktionsumfang, die Microsofts Vergleichstabelle der beiden Hosting-Optionen „Hosted on Azure” und „Hosted on Anthropic infrastructure” ausdrücklich aufführt. Zu Private Endpoints oder Netzwerkisolation als solchen macht diese Tabelle aber keine explizite Aussage.

Technisch lässt sich daraus mit Vorsicht Folgendes ableiten: Ein Private Endpoint sichert den Zugriff auf die Foundry-Ressource in Ihrer Subscription - also den API-Aufruf, den Ihr Client absetzt. Bei „Hosted on Azure” bleibt laut Microsoft die gesamte Verarbeitungskette einschließlich GPU-Inferenz innerhalb von Azure-Infrastruktur in der gewählten Geografie; ein Private Endpoint auf die Foundry-Ressource passt damit konsistent zur übrigen Isolationskette. Bei „Hosted on Anthropic infrastructure” werden Prompts und Outputs dagegen grundsätzlich auf Anthropic-eigener Infrastruktur verarbeitet, „möglicherweise außerhalb von Azure, einschließlich außerhalb Ihrer gewählten Azure-Region” - ein Private Endpoint auf die Foundry-Ressource in Ihrem Netzwerk ändert daran nichts, weil er nur die erste Wegstrecke bis zum Foundry-Frontend absichert, nicht den weiteren Weg der Anfrage zu Anthropics Infrastruktur. Wer für Claude-Workloads eine lückenlose Netzwerkisolation bis zur Modellinferenz braucht, sollte diesen Unterschied vor dem Deployment einplanen und im Zweifel „Hosted on Azure” wählen, statt sich allein auf den Private Endpoint zu verlassen.

Hub-and-Spoke und Landing Zones: wo der Private Endpoint hingehört

Ein einzelner Private Endpoint reicht selten aus - in der Praxis ist er Teil einer größeren Netzwerkarchitektur. Microsofts eigene Referenzarchitektur „Baseline Microsoft Foundry Chat Reference Architecture in an Azure Landing Zone” im Azure Architecture Center beschreibt dafür ein klassisches Hub-and-Spoke-Modell: Eine Spoke-VNet enthält die Workload-Ressourcen - darunter ein eigenes Subnetz snet-privateEndpoints für sämtliche PaaS-Private-Endpoints (Foundry, Azure AI Search, Cosmos DB, Storage, Key Vault) - , während eine zentrale Hub-VNet in einer Connectivity-Subscription gemeinsam genutzte Dienste bereitstellt: Azure Firewall für kontrollierten Egress-Traffic, Azure Bastion für administrativen Zugriff sowie die Private-DNS-Zonen für sämtliche Private Endpoints. Hub und Spoke werden über VNet-Peering verbunden.

Für die Praxis in gewachsenen Azure-Landschaften ist ein Detail aus dieser Architektur besonders relevant: In einer Landing-Zone-Aufteilung liegt die Verwaltung der Private-DNS-Zonen häufig nicht beim Workload-Team, sondern beim Platform-Team in der Connectivity-Subscription - inklusive der Frage, wie das virtuelle Netzwerk DNS-Anfragen überhaupt auflöst (über Azure Firewall als DNS-Proxy oder über Azure DNS Private Resolver). Foundry-, AI-Search- und Cosmos-DB-Clients lassen sich laut Microsoft dabei nicht auf einen alternativen DNS-Server umbiegen - sie nutzen zwingend Azure DNS. Wer eine Foundry-Ressource in eine bestehende Landing Zone einbettet, muss deshalb frühzeitig klären, wer die drei Private-DNS-Zonen aus dem vorigen Abschnitt anlegt, mit dem virtuellen Netzwerk verlinkt und pflegt - technisch ist das kein großer Aufwand, organisatorisch aber ein Punkt, der zwischen Workload- und Platform-Team abgestimmt sein muss, bevor das erste Deployment ansteht.

Der Preis der Isolation: Entwicklerzugriff, VPN/ExpressRoute und CI/CD

Netzwerkisolation ist kein Konfigurationsschalter ohne Folgekosten. Sobald der öffentliche Zugriff deaktiviert ist, braucht jeder legitime Client - Entwicklerin, Build-Pipeline, Monitoring-Tool - einen Weg in das virtuelle Netzwerk hinein. Microsoft benennt dafür in der Foundry-Dokumentation drei Standardwege:

Zugriffsweg	Typisches Einsatzszenario
VPN Gateway (Point-to-Site)	Einzelne Entwicklerinnen verbinden sich per VPN-Client von ihrem Rechner aus
VPN Gateway (Site-to-Site) oder ExpressRoute	Ganze Standorte oder Rechenzentren werden dauerhaft an das virtuelle Netzwerk angebunden
Azure Bastion + Jump-Box-VM	Eine VM im virtuellen Netzwerk dient als Entwicklungsumgebung; Zugriff per RDP/SSH über den Browser, ohne offene Ports

Für Entwicklerteams heißt das in der Praxis: Ohne VPN-Client, ExpressRoute-Anbindung oder eine im Netzwerk liegende Jump-Box kommt niemand mehr an die abgeschottete Ressource heran - auch nicht mit einem gültigen API-Key. Das ist gewollt, verändert aber den Entwickler-Alltag spürbar, insbesondere für Teams, die bislang direkt von überall aus gegen einen Azure-OpenAI-Endpunkt entwickelt haben.

Bei CI/CD-Pipelines verschärft sich dieselbe Frage. GitHub-gehostete Actions-Runner und von Microsoft bereitgestellte Azure-DevOps-Agents laufen außerhalb Ihres virtuellen Netzwerks und können einen privat abgeschotteten Endpunkt grundsätzlich nicht erreichen - unabhängig davon, wie korrekt Secrets und Berechtigungen konfiguriert sind. Der gängige Ausweg sind selbstgehostete Runner beziehungsweise Agents, die als VM, Azure Container Instance, Container-App-Job oder auf einem AKS-Cluster innerhalb des Spoke-Netzwerks laufen und von dort aus über den Private Endpoint auf die KI-Ressource zugreifen. Dass das kein Sonderfall, sondern ein eingeplantes Szenario ist, zeigt auch Microsofts eigene Landing-Zone-Referenzarchitektur: Sie reserviert im Spoke-Netzwerk ein eigenes Subnetz snet-buildAgents ausdrücklich für Build-Agenten, die regelmäßiges Patching benötigen und im selben Netzwerksegment wie die Private Endpoints liegen. Für Teams, die Claude Code in ihrer CI/CD-Kette einsetzen - etwa im automatisierten Review oder für Agenten-gestützte Build-Schritte, wie in unseren Artikeln zur Claude-Code-Harness und zum Intune-Rollout beschrieben - , gilt dieselbe Logik: Läuft die Pipeline auf einem selbstgehosteten Runner im Spoke-Netzwerk, funktioniert der Zugriff auf eine privat abgeschottete Foundry-Ressource wie für jeden anderen Client im Netzwerk auch; auf einem cloud-gehosteten Runner außerhalb dagegen nicht, ohne zusätzliche Konnektivität.

Ein weiterer Kompromiss betrifft vorgelagerte Gateways: Wird eine Foundry-Ressource über Azure API Management als KI-Gateway angesprochen, ist dieses Gateway laut Microsoft standardmäßig weiterhin öffentlich erreichbar, selbst wenn die dahinterliegende Foundry-Ressource privat ist - „to complete any data plane actions with a private Foundry, your AI Gateway must also have network isolation configured”, und diese Konfiguration erfolgt separat über das APIM-eigene VNet-Setup im Azure-Portal. Details dazu, wie ein vorgeschaltetes API-Management-Gateway separat netzwerkisoliert werden muss, finden Sie in unserem Artikel zur Absicherung von MCP-Servern über Azure API Management. Netzwerkisolation ist damit kein Zustand, den eine einzelne Ressource für sich allein herstellt, sondern eine Kette, die an jeder Stelle - Foundry-Ressource, Gateway, CI/CD-Runner, Entwicklerzugang - konsistent durchgezogen werden muss.

FAQ: Private Endpoints für Azure-KI-Dienste

Ist ein Private Endpoint für Azure OpenAI oder Foundry Pflicht?

Nein, technisch nicht - Foundry- und Azure-OpenAI-Ressourcen sind standardmäßig öffentlich erreichbar und bleiben es, solange Sie den öffentlichen Netzwerkzugriff nicht aktiv einschränken. Pflicht wird ein Private Endpoint erst durch externe Anforderungen: eine interne Sicherheitsrichtlinie, ein Kundenvertrag oder eine Zertifizierung, die Netzwerkisolation für produktive Datenverarbeitung verlangt.

Was passiert, wenn ich den öffentlichen Netzwerkzugriff deaktiviere, ohne vorher DNS zu konfigurieren?

Bestehende Clients außerhalb des virtuellen Netzwerks verlieren sofort den Zugriff - inklusive gültiger API-Keys, weil die Anfrage die Ressource technisch gar nicht mehr erreicht. Innerhalb des virtuellen Netzwerks funktioniert der Zugriff nur, wenn die passende Private DNS Zone existiert und korrekt verlinkt ist; fehlt sie, löst der Client weiterhin auf die öffentliche IP auf und läuft ins Leere.

Brauche ich für jede der drei Foundry-FQDNs eine eigene Private DNS Zone?

Ja, wenn Ihr Workload den jeweiligen Endpunkt tatsächlich nutzt. Microsoft empfiehlt ausdrücklich, für jeden verwendeten Endpunkt eine eigene Zone zu konfigurieren - privatelink.openai.azure.com, privatelink.cognitiveservices.azure.com und privatelink.services.ai.azure.com. Fehlt eine Zone, scheitert nur der Teil des Zugriffs, der genau diese FQDN nutzt, oft unbemerkt bis zum ersten produktiven Aufruf.

Wie kommen Entwicklerteams und CI/CD-Pipelines noch an eine privat abgeschottete Ressource?

Über eine Netzwerkverbindung in das virtuelle Netzwerk hinein: VPN Gateway (Point-to-Site für Einzelpersonen, Site-to-Site für Standorte), ExpressRoute für dauerhafte Unternehmensanbindungen, oder eine Jump-Box-VM per Azure Bastion. Für CI/CD-Pipelines ist die gängige Lösung ein selbstgehosteter Runner oder Agent, der innerhalb des Spoke-Netzwerks läuft - cloud-gehostete Runner erreichen einen privat abgeschotteten Endpunkt grundsätzlich nicht.

Gilt das auch für Claude-Modelle in Microsoft Foundry?

Ja, aber nur für den Zugriff auf die Foundry-Ressource in Ihrer Subscription - nicht zwangsläufig für den gesamten Weg der Anfrage. Ob das reicht, hängt davon ab, welche der beiden Claude-Hosting-Varianten Sie einsetzen; die beiden Hosting-Varianten von Claude in Microsoft Foundry im Detail beschreiben wir in einem eigenen Artikel.

Fazit

Ein Private Endpoint verschiebt eine Foundry- oder Azure-OpenAI-Ressource vom öffentlichen Internet in Ihr eigenes virtuelles Netzwerk - technisch überschaubar, solange man zwei Dinge nicht unterschätzt: das DNS für bis zu drei separate FQDNs pro Foundry-Ressource, und die Folgekosten für alles, was bislang direkt von außen auf die Ressource zugegriffen hat. Wer Netzwerkisolation zusammen mit Managed Identity statt statischer API-Keys plant, deckt damit die beiden zentralen Stellschrauben ab - von wo und von wem auf eine KI-Ressource zugegriffen werden darf. Beides gehört in eine Landing-Zone- oder Hub-and-Spoke-Architektur von Anfang an mitgedacht, nicht als nachträgliche Härtung kurz vor dem Compliance-Audit.

Quellen (Stand: August 2026):