Require private endpoints for Azure PaaS services

Unlike many security controls, private endpoints are not free, but the cost is small and entirely predictable. Each private endpoint carries a low fixed hourly charge plus a few pence per gigabyte of data processed, and a workload typically needs one endpoint per service, sometimes one per sub-resource, such as separate blob and file endpoints on a storage account. There is also a one-off cost in private DNS zones, which are inexpensive, and in the engineering time to wire each service into a subnet and update its DNS. The bill is countable in advance: number of endpoints multiplied by a known rate.

Set that against what it removes. Every public endpoint on a data service is an internet-facing attack surface that has to be defended with firewalls, monitoring and key rotation indefinitely. A private endpoint takes the service off the internet entirely, so the expected loss it removes is the cost of a public-exposure incident on regulated data, which is large and well documented. Frame each failing recommendation by the sensitivity of what sits behind it rather than by the endpoint count.

The trade is therefore a small, forecastable operating cost against a large, uncertain tail risk. The finance role is to budget the endpoints for the services that genuinely hold or move sensitive data first, and to make sure the few services that are public on purpose, such as a public API front end, are recorded as deliberate exceptions rather than swept into the same line item.

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with seven private-link findings across the estate. Unlike the storage lock-downs the team handled last quarter, these are not free: each private endpoint carries a small fixed hourly charge plus a per-gigabyte data-processing rate, and a few services need more than one endpoint. The instinct is not to wave through a blanket budget; it is to ask which services genuinely hold or move sensitive data, because those are the endpoints worth paying for first.

Priya asks the team to map each failing service to what flows through it. The SQL database and the storage account hold customer records, the App Configuration store carries connection strings and feature flags, the SignalR service relays live application traffic, and a couple of the findings are on non-production or low-sensitivity services. The list is reframed as a budget line: 'Roughly seven endpoints at a known per-endpoint rate, prioritised so the customer-data services go private this sprint and the low-sensitivity ones follow. The total is a small, predictable monthly figure, and it buys us taking the estate's data services off the public internet, which is exactly the evidence the auditor wants.' The point that lands with the team is that the cost is countable up front and the risk it removes is not.

The cost model here is unusual for this lesson series because the remediation is not free: private endpoints carry a small, ongoing charge. But the trade is still strongly favourable. The cost is a known per-endpoint rate, forecastable to the pound, while the risk it removes is the unbounded cost of a public-exposure incident on the data or secrets behind each service. Each service left public is one where a future firewall mistake could expose its contents, and the probability of at least one such mistake across the estate over years is not small.

The documented cost of a data-exposure breach, mandatory notification within tight regulatory windows, forensics, legal fees and customer churn, routinely runs into six and seven figures. Against that, the remediation is a modest monthly endpoint bill plus the engineering time to wire DNS. The finance role is to attach the sensitivity of the data behind each service to its recommendation, so the customer-data and secrets services are funded for private endpoints first and the low-sensitivity ones are scheduled rather than skipped.

Most of the data and event flow in a modern Azure estate runs through managed services: databases, storage, machine-learning workspaces, messaging and configuration stores. By default each of those answers on a public endpoint, which means the question 'is our data reachable from the internet?' has the uncomfortable answer 'yes, behind a firewall, unless we changed it.' A private endpoint changes the answer to a flat 'no, those services are not on the internet.'

The leadership question is not 'is each service firewalled today?' It is 'can a workload's data plane be reached from outside our network at all?' The defensible end state is that the services holding or moving sensitive data sit on private endpoints, reached only over the Azure backbone, and that the handful of services that must stay public are a named, owned list rather than an oversight.

This one does carry a small, ongoing cost, unlike free lock-downs such as disabling anonymous access. That makes it a clear budget-versus-risk decision: a modest, predictable per-service charge in exchange for taking the estate's data services off the public internet. For anything holding regulated data, that is usually an easy trade to approve.

After a regulator asked a peer firm to prove its customer database was not reachable from the internet, and the peer struggled to answer because it relied on firewall rules rather than network isolation, the CTO asked the same question internally: if a regulator asked us tomorrow, what would we say? The honest answer was that the databases and storage accounts were firewalled but still had live public endpoints, so the truthful answer was 'reachable in principle, blocked in practice', which is not the answer anyone wants to give a regulator.

The team's response was to treat private endpoints as the default for any service holding or moving sensitive data. They inventoried which services were still public, put private endpoints on the storage accounts, the SQL databases, the App Configuration store and the SignalR service, wired the private DNS so applications kept using the same hostnames, then disabled public network access on each. The next time the question came up, the answer had changed from 'firewalled but reachable' to 'those services are not on the internet, they are reached only over our own network, and here is the list of the few that are public on purpose.' That shift, from defending a public front door to removing it, is the confidence signal this capability delivers, and it costs a small, predictable monthly figure to reach.

The services that hold and move the organisation's data, databases, storage, messaging, configuration, are the ones a regulator or auditor will ask about directly. Being able to say those services are not reachable from the internet at all is a categorically stronger position than saying they are firewalled, because a firewall is a rule that can drift and a private endpoint is the absence of a public door.

This is one of the few controls in this area with a genuine ongoing cost, which makes it an explicit budget-versus-risk decision rather than a free lock-down. For the services that carry regulated or sensitive data, the modest, predictable per-service charge in exchange for removing internet reachability is the kind of asymmetric trade leadership should approve quickly. The judgement call is only ever about the few services that must stay public, and the requirement there is that they are a named, owned list.