Public and Private Endpoints in Azure
Slide deck explaining public and private endpoints in Azure, including Azure Private Link, DNS resolution, service endpoints, access scenarios, and common pitfalls.
Public and Private Endpoints in Azure
Introduction to public and private endpoints in Azure, covering how clients reach Azure services.
Public and Private Endpoints in Azure
Introduction to public and private endpoints in Azure, covering how clients reach Azure services.
Endpoint = the service 'door'
An endpoint is how your client reaches an Azure service—usually by hostname. Endpoint equals network entry point for a service. Apps usually connect using a hostname. Public vs private equals where that hostname leads. DNS often decides what really happens.
FQDN → DNS → IP → Connection
Your client connects to whatever IP address DNS returns. FQDN (Fully Qualified Domain Name) equals full hostname. DNS (Domain Name System) resolves name to IP. IP (Internet Protocol) address is the destination. Rule: your client follows DNS.
Public endpoint
Public endpoint equals reachable via public IP (internet-routable). Uses a public IP address. Reachable from the internet in principle. Can still be restricted (auth plus firewall rules). Public does not equal automatically open.
Private endpoint (Azure Private Link)
Private endpoint equals private IP in your VNet using Azure Private Link. VNet (Virtual Network) gets a private IP for the service. NIC (Network Interface) is placed in your subnet. Works for VNet plus peering plus VPN (Virtual Private Network) / ExpressRoute. Public access may still exist unless you disable it.
Private endpoint + DNS
If DNS resolves to the public IP, your traffic goes public—even with a private endpoint. Private endpoint needs DNS attention. Service hostname should resolve to private IP. Private DNS zone often provides the mapping. First check when 'still public': DNS resolution.
Service endpoints vs private endpoints
Service endpoints secure subnet access; private endpoints provide a private IP in your VNet. Service endpoint: secure access from specific subnet(s). Service endpoint: service stays on normal endpoint. Private endpoint: private IP (NIC) inside your VNet. Private endpoint: commonly needs private DNS.
Situation 1: private-only access
Use a private endpoint plus DNS; disable public access if you need private-only. App in VNet needs Storage privately. Create private endpoint (private IP in subnet). Configure DNS to resolve privately. Disable public network access (if supported).
Situation 2: public + private together
It's normal to use public for partners and private for internal systems. Partner uses public endpoint (secured). Internal systems use private endpoint. Same service, different access paths. Don't assume 'must pick one'.
Situation 3: subnet restriction (simpler DNS)
Service endpoints can restrict access from a subnet without creating a private IP in your VNet. Enable service endpoint on a subnet (supported services). Allow only that subnet/VNet on the service. Uses Azure backbone for traffic. Does not create a private IP for the service.
Situation 4: 'It still connects public'
If it's still public, validate DNS resolution first. Check hostname → resolved IP from the app. If resolved IP is public → traffic goes public. Configure private DNS mapping to private IP. Remember: routing won't override DNS choice.
Common pitfalls
Most issues come from assumptions: DNS, public access, and feature confusion. Private endpoint does not equal 'internet encryption'. Forgetting DNS breaks private routing. Public access isn't auto-disabled. Service endpoint does not equal private endpoint. 'Private' can still include peering/on-prem.