Azure Networking

Azure Private Endpoint
How It Works

A private endpoint lets your VM talk to Azure services like Storage, SQL, or Key Vault over a private IP inside your VNet — never touching the public internet.

What is a Private Endpoint?

Normally when your application connects to an Azure service (e.g. Azure Blob Storage), the hostname resolves to a public IP address and traffic flows over the internet — even if both your VM and the storage account are in Azure.

A Private Endpoint is a virtual network interface card (NIC) that Azure injects directly into your VNet subnet. It gets a private IP from your address space (e.g. 10.0.0.10). Azure Private DNS then overrides the public hostname so it resolves to this private IP instead. Your app connects normally — zero code changes — but traffic never leaves Microsoft's backbone.

🔌

Virtual NIC

Azure injects a NIC with a private IP into your subnet. That's the "endpoint" — a door into the service.

🔍

Private DNS zone

Overrides public DNS so the service hostname resolves to the private IP, not a public one.

🛡️

No internet

Traffic stays entirely on Microsoft's private backbone — never exposed to the public internet.

⚙️

Zero code changes

Your app still uses the same hostname. DNS does the magic silently in the background.

How it works — step by step

01

VM does a DNS lookup

Your Linux VM queries mystore.blob.core.windows.net — same as always.

02

Private DNS zone intercepts

Instead of returning a public IP like 52.x.x.x, the private DNS zone returns 10.0.0.10 — the private endpoint's IP inside your VNet.

03

VM connects to private IP

The connection goes to 10.0.0.10 — the virtual NIC sitting inside your subnet. No public route is involved at all.

04

Azure routes internally to the service

Azure maps the private endpoint NIC to the actual storage account behind the scenes, over Microsoft's private backbone. Traffic never hits the internet.

Before & after diagram

// network traffic flow — linux vm → azure storage
Azure Private Endpoint Before and After Diagram Diagram showing how Linux VM accesses Azure Storage before and after Private Endpoint BEFORE — Without Private Endpoint Your VNet 10.0.0.0/16 Linux VM 10.0.0.4 curl mystore.blob.core... Public Internet Azure Storage mystore.blob.core .windows.net Public IP: 52.x.x.x Public access: ON DNS: mystore.blob.core.windows.net → 52.x.x.x ⚠ Traffic travels over the public internet AFTER — With Private Endpoint Your VNet 10.0.0.0/16 Linux VM 10.0.0.4 Private Endpoint Virtual NIC IP: 10.0.0.10 Private DNS Zone mystore.blob.core.windows.net → 10.0.0.10 Azure Storage mystore.blob.core .windows.net Public access: OFF Private only ✓ Microsoft backbone Private traffic only ✓ Traffic stays inside Microsoft's private network Step-by-step — DNS magic explained 01 VM does DNS lookup mystore.blob.core.windows.net (same hostname as always) 02 Private DNS intercepts Returns 10.0.0.10 — NOT 52.x.x.x Public IP never reached 03 VM connects to 10.0.0.10 Hits the Private Endpoint NIC inside your own VNet subnet 04 Azure routes internally NIC maps to storage account over Microsoft backbone Same hostname. Different IP. Zero internet. Zero code changes. DNS does all the work silently

Key benefits

Security — the storage account (or any Azure service) is never reachable from the public internet. You can disable public access entirely.
Compliance — data in transit never leaves Microsoft's network, satisfying strict regulatory requirements like PCI-DSS, HIPAA, and ISO 27001.
No code changes — your application uses the exact same hostname. Private DNS overrides the resolution transparently.
Works across services — supported by Azure Storage, SQL Database, Cosmos DB, Key Vault, Service Bus, Event Hub, AKS, and many more.
Reduced attack surface — combined with NSGs and firewall rules, private endpoints eliminate the entire class of internet-exposed Azure service attacks.