Azure Private Link costs: model endpoint-hours, data processed, and trade-offs vs NAT

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-01-27. Editorial policy and methodology.

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.


Private Link-style networking typically charges for time (endpoint-hours) and volume (data processed). The decision is often driven by security posture and architecture, but you can model it with a simple breakdown and validate it with real traffic.

0) Count endpoints the right way (avoid sprawl)

Start with an inventory. Private endpoints tend to multiply as teams add environments and regions.

  • Environments: prod, staging, dev (and any isolated tenants).
  • Regions: active-active or multi-region DR can double or triple endpoint count.
  • Services: storage, registries, key vaults, databases, messaging.

Endpoint-hours scale with count, not with traffic. A low-traffic endpoint still costs hours.

1) Endpoint-hours (baseline)

The baseline is: number of endpoints × hours per month. If you have many small environments, endpoint hours can dominate the bill even if data processed is low.

2) Data processed (GB/month)

Estimate how much data flows through private endpoints. The common dominant flows are registry pulls, storage downloads, and any large artifacts accessed privately.

Tools: Unit converter, Transfer estimator, Egress model (GB/month).

  • Registry pulls: node churn and deploys create peaks; model baseline + peak.
  • Storage access: large downloads are often few endpoints but big bytes.
  • Database traffic: usually smaller bytes, but can be constant and high-frequency.

3) Compare scenarios: Private Link vs NAT/public

For cost comparisons, model two scenarios for the same traffic:

  • A) Public endpoint via NAT: NAT hours + NAT throughput + any internet egress charges.
  • B) Private endpoint: endpoint-hours + endpoint processed GB (plus any remaining egress for other traffic).

Related: Azure NAT Gateway cost.

4) Pitfalls that create double-paying

  • DNS mismatch: endpoint exists but traffic resolves to the public hostname and still uses NAT.
  • Partial rollout: some workloads use private endpoints, others still use public endpoints.
  • Cross-region hairpins: traffic crosses regions unexpectedly; model those transfer legs separately.
  • Endpoint sprawl: endpoints created "just in case" across many VNets and environments.

Worked estimate template (copy/paste)

  • Endpoints = count by env/region/service
  • Endpoint-hours = endpoints × hours/month
  • Processed GB/month = sum of private flows (baseline + peak)
  • Comparison = scenario A (NAT/public) vs scenario B (private endpoint)

How to validate

  • Validate DNS: private zones and actual resolution from workloads.
  • Validate routing: confirm which subnets reach the service via the private endpoint.
  • Measure bytes: find top private flows (registries, storage) and confirm baseline vs peak.
  • After changes, verify you reduced NAT/public traffic rather than adding an endpoint on top of it.

Related tools

Sources


Related guides


Related calculators


FAQ

What usually drives Private Link costs?
Endpoint-hours are the baseline. Data processed (GB) becomes meaningful when you move a lot of data through private endpoints (registries, storage, large downloads).
How do I estimate quickly?
Count private endpoints × hours per month, then estimate GB/month through those endpoints. Compare that to a NAT/public-endpoint path for the same traffic.
How do I validate?
Validate DNS (private zones), routing, and which workloads actually use the private endpoint. A common failure is 'endpoint exists but traffic still uses public/NAT', which can lead to paying for both paths.
What is the most common mistake?
Endpoint sprawl: creating endpoints per environment, per region, per service without tracking count and utilization. Endpoint-hours can dominate even with modest traffic.

Last updated: 2026-01-27. Reviewed against CloudCostKit methodology and current provider documentation. See the Editorial Policy .