When you put a Microsoft Foundry resource behind a private endpoint, your Claude traffic stops traversing the public internet and enters Azure's backbone through a network interface with a private IP inside your virtual network (VNet). Yet your application keeps calling the same {resource}.services.ai.azure.com hostname it always did. The entire redirection happens in DNS, and understanding the mechanism is the difference between a smooth rollout and a week of "why does it work from the VM but not from the office."
The CNAME rewrite
A private endpoint is created against the Foundry resource (the "account" target in the portal), in the same region and subscription as the VNet, and only endpoints in the Approved state carry traffic. When the endpoint is approved, Azure rewrites the resource's public DNS record: the hostname's CNAME chain now points into a privatelink subdomain, and Azure creates a private DNS zone for that subdomain containing A records that resolve to the endpoint's private IP.
The result is split-horizon DNS — the same question gets two different answers depending on who asks:
- Inside the VNet (or a network linked to the private DNS zone), the resolver follows the CNAME into the
privatelinkzone, finds the A record, and returns the endpoint's private IP. Traffic flows to the private endpoint. - Outside the VNet, public DNS has no view of the private zone, so the chain resolves to the public endpoint as before. Whether that connection is then accepted depends on the resource's public network access setting — with PNA disabled, outside callers resolve an address they are not allowed to use. (See the three PNA modes for that half of the story.)
Because the hostname never changes, clients keep the same connection string, the same TLS certificate validation works, and SDK configuration such as AnthropicFoundry(resource=...) is untouched. There is no "private hostname" to plumb through your config.
Where it breaks: custom and on-premises DNS
The split-horizon magic depends on queries reaching Azure's own resolver, which lives at the fixed virtual IP 168.63.129.16 — reachable only from inside Azure networks. VMs that use Azure-provided DNS get this for free. Two common setups do not:
Custom DNS servers in Azure. If your VNet points at your own DNS servers (common in enterprises that run Active Directory DNS), those servers answer from public DNS and never see the private zone. The fix Microsoft documents: configure your DNS servers to forward the privatelink subdomain to Azure DNS at 168.63.129.16. A conditional forwarder for the relevant zone sends just those queries to Azure's resolver, which answers from the private DNS zone.
On-premises networks. Machines on-prem (connected via VPN or ExpressRoute) can't reach 168.63.129.16 directly from outside Azure, so the standard pattern is to forward the privatelink zone to a DNS forwarder running inside the VNet, which in turn queries 168.63.129.16. Check the official Private Link DNS documentation for the reference architectures if you are wiring this into an existing hybrid DNS estate.
Permissions and one sharp edge
Creating and approving private endpoints requires Network Contributor on the VNet and Contributor or Owner on the Foundry resource — often two different teams in practice, so plan the handshake. And avoid using 172.17.0.0/16 for the VNet address space: it is claimed by Docker's default bridge network, and containerized workloads will suffer exactly the kind of confusing connectivity failure this article is trying to save you from.
Where to go next
The broader lockdown picture — inbound modes, trusted-service bypass, and management access to a sealed resource — is covered in Foundry private endpoints, the trusted-services bypass, and VNet integration.