The default instinct on Azure is to put a Private Endpoint on every PaaS resource. Storage, Key Vault, SQL, all of it. It feels like the secure thing to do, and nobody gets fired for choosing the most locked-down option. But Private Endpoints are not free, and applied by reflex they quietly run up a bill and add real DNS complexity. Here is how I actually decide.
What you are choosing between
There are three common ways to reach a PaaS service like Storage or SQL, and they are not priced the same.
- Public endpoint with firewall rules. The default. The resource keeps its public endpoint, but you restrict access by IP range or selected networks. It costs nothing and is perfectly fine for plenty of workloads.
- Service Endpoint. Also free. It keeps traffic on the Azure backbone and lets the resource trust a specific subnet, so only your VNet can reach it. No private IP, no DNS changes to manage.
- Private Endpoint. This gives the resource a private IP inside your VNet. It is billed per endpoint per hour, plus a charge per GB of data processed, and it needs Private DNS zones to resolve correctly. This is true network isolation, and you pay for it.
Where the cost actually hides
One Private Endpoint is cheap enough to ignore. The bill shows up when the pattern becomes the default: a Private Endpoint on every storage account, every Key Vault, and every database, across dev, test, and production. Now multiply the per-endpoint hourly charge and the per-GB processing across dozens of resources and three environments, then add the Private DNS zones and the time your team spends untangling name resolution when something cannot connect.
None of that is wasted if you needed the isolation. A lot of it is wasted if you did not.
When a Private Endpoint earns its keep
- On-prem systems need to reach the resource over a private IP, across a VPN or ExpressRoute.
- You have a hard requirement to keep traffic off public endpoints entirely, for compliance or data-exfiltration controls.
- You are exposing the resource to a network you do not fully trust, and you need real isolation rather than a firewall rule.
When a free Service Endpoint does the same job
- Everything that talks to the resource already lives in Azure.
- You just need to guarantee that only your VNet or subnet can reach it.
- There is no on-prem private-IP requirement and no mandate to eliminate the public endpoint.
In that situation a Service Endpoint gives you the control you wanted for nothing, and skips the DNS overhead.
A rule of thumb
Start from the requirement, not the pattern. Default to public-with-firewall or Service Endpoints, and reach for Private Endpoints where private on-prem access or strict isolation is an actual, written requirement. Tag the ones you deploy and review the count every quarter, because this is the kind of cost that creeps in one resource at a time.
Cost-effective architecture is not about always choosing the cheapest option. It is about not paying for isolation you do not need.
If you want a second set of eyes on where your environment is spending money it does not have to, that is exactly what a readiness assessment is for.