When traffic to a managed service moves onto a private endpoint, how does the shape of the charge change?

## Two different billing shapes The public path to a managed service is charged like any other internet transfer: **per unit moved, mostly in the outbound direction**, with inbound normally not charged. It is purely usage-shaped. A month with no traffic produces no line. A private endpoint typically introduces a second dimension: - a **standing charge per placement** — the endpoint exists, so it is billed by time, usually multiplied by however many zones or subnets you placed it in for resilience; - a **per-unit charge for bytes processed** through it, which replaces the internet transfer charge for that traffic. The practical difference is that the bill acquires a **floor that does not scale to zero**. ## The arithmetic, qualitatively With `P` placements, `H` hours in the month, a standing rate `r` per placement-hour and a processing rate `p` per unit: - private path ≈ `P × H × r + volume × p` - public path ≈ `outboundVolume × internetRate` The crossover is a volume, not a policy. Below it the private path costs more; above it, less — because the standing term is amortised over more bytes and the processing rate is typically the gentler of the two per-unit rates. Two consequences follow that teams do not expect: 1. **Many small endpoints are the expensive shape.** Ten services reached privately from three networks, each placed in three zones, is ninety standing charges before a single byte moves. 2. **A quiet environment is the worst case.** A pre-production estate mirroring production's private layout pays nearly production's floor on a fraction of the traffic. ## Why this is a design decision and not a finance one - The number of placements is set by the **resilience** requirement — one placement per zone if losing a zone must not take the private path with it — so cost and availability are traded against each other in the same choice. - The number of endpoints is set by the **network layout**: extending the private answer to a peered network keeps one endpoint serving both, while giving each network its own endpoint buys independence and pays for it monthly. - Once the store refuses the public path, the endpoints are **not optional any more**, so this is a recurring cost the design has committed to, not one that can be trimmed later without revisiting the control. ## Things that are still true regardless of the path - Crossing a **zone or region boundary** is charged on its own schedule, and taking the private path does not make that boundary free. If the endpoint is in one zone and the caller in another, that crossing is still a crossing. - **Direction still matters.** Whatever the path, the charged direction is normally the one leaving; do not describe a private path as having removed a charge without naming which boundary the bytes no longer cross. - The private path is **not free just because it is private**. The single most common framing error is to present private service access as a cost saving, when the reason it exists is control and the cost effect is a consequence that can go either way. ## How to answer this in an interview Say the shape, then the break-even, then the estate effect: usage-only against standing-plus-usage; a crossover volume rather than a universal saving; and a fleet of thinly used endpoints replicated per zone and per network as the pattern that surprises people. Add that platforms price this differently — some charge nothing standing for certain kinds of private path — which is why the durable answer is the shape rather than a rate. Detailed transfer pricing is a separate subject; what belongs to the private path is that it swaps a purely metered charge for one with a floor.