Private Endpoints & no public PaaS
Private IPs and disabling public access.
Two habits leave Azure data exposed: reaching PaaS services (Storage, SQL, Key Vault) over their public endpoints, and leaving those endpoints reachable from the internet at all. Private Endpoints and disabling public access close both.
Private Endpoints over Service Endpoints
A Private Endpoint projects a PaaS resource into your VNet as a private IP, so traffic to it never leaves the Azure backbone — and you can then disable the resource’s public network access entirely, removing its internet attack surface. That is stronger than the older Service Endpoints, which still route to the service’s public IP (just over the backbone) and leave it publicly reachable. Combine a Private Endpoint with a firewall rule that denies public access, and even a leaked key cannot connect from outside your network.
# Create a private endpoint for the blob service in your subnet...az network private-endpoint create -g rg -n st-pe --vnet-name app-vnet --subnet data \--private-connection-resource-id $(az storage account show -g rg -n acmedata --query id -o tsv) \--group-id blob --connection-name st-conn# ...then remove all public network access — only the VNet can reach it now.az storage account update -g rg -n acmedata --public-network-access Disabled --default-action Deny
Private by default across the estate
Apply the pattern consistently: Key Vaults, Storage, SQL, Cosmos DB, and container registries should all be reachable only via Private Endpoints with public access disabled, resolved through Azure Private DNS zones so names point at the private IPs. Enforce it with Azure Policy so a resource created with public access is denied or flagged, making "private by default" a property of the platform rather than a thing each team remembers.