Why would a team reach a managed store through an endpoint inside its own address range instead of the store's public address?
answer
- one fewer network to cross
- no internet route needed for that service
- an address out of your own subnet
- you own the endpoint, not the service
- changes the route, not the permission
basics
~20 sAn endpoint inside your own range keeps the call on the provider's internal network: the workload connects to an address in one of your subnets, so the request does not take the public path and the subnet needs no route to the internet.
solid answer
~40 sThe provider lets you place an **endpoint for a service you do not run** inside your own private address range. It consumes an address from one of your subnets, and traffic sent to it is carried over the provider's internal network to the managed service instead of out through an internet route. Three things follow: the packets never traverse the public internet, the workload's subnet no longer needs an internet-facing route or an address-translating gateway just to reach that service, and the traffic is metered as private-path usage rather than as internet transfer. What it does **not** do is decide who may call the service — the endpoint changes the route, not the permission.
go deeper
Recall the shape: an address in your own subnet standing in front of a service the provider runs, so the call stays on the provider's network and the subnet needs no internet route for it.
Explain the three things that move — the first hop, the address the client connects to, and the charge shape — and be explicit that permission is not one of them.
Show the design consequences: address consumption per placement, whether the endpoint is zonal, and what happens to workloads if the private path is the only path you allow and its zone is lost.
Frame the estate-wide call: private by default costs addresses and a standing charge per service per network, so decide which service tiers earn it and what the standard is for the rest.
## The construct A managed service — an object store, a managed relational engine, a message broker — is normally reached at a hostname the provider publishes to everyone, which resolves to an address on the provider's public front door. A call to that address leaves your subnet through whatever path reaches the internet: a routed subnet with a public address on the workload, or an address-translating gateway on the routed side that gives private workloads outbound-only reachability. **Private service access** replaces that first hop. The provider lets you create an **endpoint** for the service *inside your own private address range*. Two ownership facts make everything else follow: - The **endpoint is a tenant-side resource.** You create it, it takes an address out of one of your subnets, your route tables reach it, and your boundary filtering applies to it exactly as it would to any workload address. - The **service behind it is not yours.** You get a front door to a capability the provider operates — not a machine, not a port map, not a process you can log into. ## What changes on the wire | | Public path | Endpoint inside your range | |---|---|---| | First hop | out through an internet route | to an address in your own subnet | | Address the client connects to | provider's public address | an address from your prefix | | Internet route needed in the subnet | yes, for that service | no, for that service | | Charge shape | metered as internet transfer | metered as private-path usage | | Who may call the service | a valid credential from anywhere | unchanged by the endpoint alone | The first row is the whole point and the last row is the one candidates get wrong. Moving the route does not move the authorization decision: the service still evaluates the caller's credential and its own resource-attached rules. The private path is a *network* fact. ## Why a regulated estate asks for it - **A stated control.** "No packet reaches the data tier over the public internet" is a control an auditor can be shown, and a private endpoint is the mechanism that implements it for a service you do not run. - **Subnets with no internet path at all.** Without private service access, a workload in a subnet with no outbound route cannot reach the managed tier either, because that tier is reached at a public address. The endpoint lets the subnet stay genuinely closed. - **A narrower exposure surface.** The bytes stay inside the provider's network between two things you have named, which removes a class of interception and misrouting concerns from the design review. - **A place to hang policy.** Because the call now arrives through a named endpoint, the service can be told to accept traffic only from that path — the mechanism that turns "we prefer private" into "public is refused". ## The three ways teams misread it 1. **"It means only we can reach the service."** No. Unless something else refuses the public path, any caller anywhere holding a valid credential still reaches the same service at its public address. 2. **"It encrypts the traffic."** No. Transport encryption is a separate mechanism and is still expected; the endpoint narrows *where the bytes go*, not *whether they are readable in flight*. 3. **"It is a tunnel to the provider."** No. A tunnel or a dedicated circuit is how an estate outside the platform reaches in — a different leaf's subject. A private endpoint is an address inside a range you already have on the platform. ## Practical consequences to name in an interview - The endpoint **consumes addresses** from the subnet it is placed in, so it belongs in the address plan. Platforms differ in whether one endpoint serves a whole region or whether you place one per zone or per subnet for resilience, and the resilient shape costs more addresses. - The endpoint is a **failure domain of its own**: if it is placed in one zone only, losing that zone takes the private path with it while the public path — which you may have deliberately refused — is still there. - Because the subnet no longer needs an internet route for this service, the **address-translating gateway's load drops**, and with it the port pressure that gateway carries. - The charge stops looking like internet transfer and starts looking like a standing rental plus per-unit processing, which is a different bill shape rather than automatically a smaller one.
- Does placing a private endpoint remove the need for transport encryption to the service?No. The endpoint narrows the network path; it says nothing about whether the bytes are readable in flight. Providers still expect the session to be encrypted, and a design review that drops transport security because "the traffic is private now" has swapped one control for another that does not cover it.
- Where does the endpoint's address come from, and why does that matter to the address plan?From the subnet you place it in — it consumes usable addresses out of your prefix like any workload. That matters because a resilient layout usually means an endpoint placement per zone, multiplied by every managed service you reach privately, and a prefix sized years earlier can run short.
- If a subnet has no internet route at all, what did workloads there do before private service access existed?They either could not reach the managed tier, or the subnet was given an outbound path through an address-translating gateway purely so the public hostname could be reached. The endpoint is what lets the subnet stay genuinely closed while still using the managed tier.
It is the difference between a supplier's public reception, which anyone can walk into with the right badge, and a delivery door they cut directly into your own building. The walk is shorter and private — but the badge check has not moved.
saying these in an interview costs you the question
- Thinks a private endpoint also decides who is allowed to call the service
- Believes the service's public address stops existing once an endpoint is created
- Says private access is what finally encrypts traffic to the managed service
- Describes it as a tunnel dug between the tenant and the provider
- Assumes the subnet still needs an outbound internet route for that service