The question this answers
How does a private workload reach another network or a provider service without a path to the internet?
The application must read from object storage, call an internal service owned by another team in a different network, and reach a corporate directory on-premises. None of those destinations should be reached over the public internet, and none of them should require the workload to be internet-reachable.
Reachability to a specific named destination over the provider's own network — no public address, no internet transit, no NAT capacity consumed, and a path that is enumerable in an audit.
Four shapes, four different problems
These constructs get conflated constantly, so it is worth separating them by the problem each solves. Peering joins two virtual networks so their private addresses route to each other; it is point-to-point, non-transitive, and requires non-overlapping ranges — which is why Virtual Private Cloud insists on an address plan. A private endpoint places an interface for a specific service inside your subnet, giving it a private address in your range; traffic to that service never leaves the provider network. A service endpoint (a gateway-style route) achieves something similar by routing service traffic off the internet path without giving you an address. A transit hub is a router that many networks and on-premises connections attach to, converting a quadratic peering mesh into a set of attachments.
The distinction that matters operationally is *what appears in your address space*. A private endpoint gives you an address you can point a security group at, which means the destination service becomes a resource you can write firewall rules about. A route-based service endpoint does not, so you get the path but not the same granularity of control.
And the distinction that matters architecturally is transitivity. Peering does not chain: if A peers with B and B peers with C, A cannot reach C, and no amount of route configuration changes that. Teams discover this after building a mesh, which is the moment a transit hub stops looking expensive.
The exposure argument, and the bill that follows it
The security case is straightforward: traffic that never traverses the public internet cannot be intercepted on it, and a destination reachable only over a private path cannot be reached by anyone who has not already got into your network. More importantly, a private endpoint lets you make the service itself default-deny — some providers allow a storage bucket policy that accepts requests only from a specific endpoint, which converts "this bucket has a strong policy" into "this bucket is not reachable from the internet at all". That is a categorically stronger statement. See Public Exposure, Read With Context.
The cost case is the one that surprises teams. A private workload reading from object storage over a NAT device pays the NAT per-gigabyte data-processing charge on every byte — for traffic that never needed to leave the provider network in the first place. Analytics jobs, log shipping, backup writes and container image pulls are all large-volume flows that commonly take this path by default. Routing them through a private endpoint removes the charge and simultaneously removes the load from a component with a hard concurrency ceiling.
That combination — cheaper *and* less exposed *and* less load on a fragile component — is rare enough to be worth stating plainly: for provider services, a private endpoint is usually the first thing to do, before any NAT sizing conversation. See NAT Gateway and Egress: Moving Data Costs Money, Not Just Storing It.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
What it costs you that is not money
Private connectivity is not free complexity. Each endpoint is an object with its own DNS behaviour — the service's hostname must resolve to the private address inside your network, which usually means a private DNS zone, and a misconfigured one sends the traffic straight back out through the NAT while everything appears to work. That failure is invisible until someone reads the bill or the flow logs.
Peering brings the address-overlap constraint into every future decision, and it brings route-table entries in both networks that must be maintained in step. A transit hub brings a shared dependency: it is now on the path between many networks, so its failure or its route-table mistake is a multi-team incident, and its attachment charges scale with the number of networks you created for reasons that may not have been good ones.
The honest counsel is to reach for private endpoints eagerly — they are cheap, they reduce exposure and they reduce load — and to reach for peering and transit hubs only when there genuinely is more than one network. A great deal of transit complexity exists to reconnect networks that were split for no strong reason. See Scoring Operational Complexity.
| Shape | Use when | Gives you an address? | The catch |
|---|---|---|---|
| Private endpoint (interface) | Reaching a provider service or a partner service privately. | Yes — in your subnet, nameable by a security group. | Needs private DNS to resolve correctly, or traffic silently uses the internet path. |
| Service endpoint (gateway route) | High-volume provider traffic where a route is enough. | No — it is a route-table target. | Coarser control; you cannot write a firewall rule against an address you do not have. |
| Peering | Joining exactly two networks that trust each other. | Uses existing private addresses. | Non-transitive, requires non-overlapping ranges, and the mesh grows quadratically. |
| Transit hub | Three or more networks, or connecting on-premises. | Uses existing private addresses. | A billed, shared dependency, and a route-table mistake there is everyone's incident. |
| VPN or dedicated link | Reaching on-premises systems. | Uses on-premises addresses. | Bandwidth ceilings, tunnel liveness, and a whole second network team's conventions. |
Key points
- A private endpoint puts a service's interface in your subnet, so it gets an address you can write security-group rules against.
- Peering is point-to-point and non-transitive; a transit hub exists to convert a quadratic mesh into linear attachments.
- Private paths reduce exposure and usually cost less, because they remove traffic from the NAT per-gigabyte meter.
- They also remove load from the NAT's concurrency ceiling, which is a reliability gain, not just a cost one.
- Private DNS is the part that goes wrong: a wrong resolution sends traffic back out the internet path while everything appears to work.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • An interface endpoint provisions a network interface with an address from your subnet, and requests to the service hostname resolve to it via a private DNS zone.
- • A gateway-style service endpoint adds a route-table entry that sends traffic for that service to a provider target instead of to a NAT device.
- • Peering establishes a route between two networks' address ranges; both sides need routes and neither side's peers are reachable through it.
- • A transit hub terminates attachments from many networks and routes between them according to its own route tables.
- • In every case the traffic stays on the provider's network, so no public address is involved at either end.
- • Own private DNS resolution for every endpoint, and verify it — the failure is silent and shows up only on the bill.
- • Own endpoint policies where the provider offers them, so the endpoint restricts which resources may be reached through it.
- • Own the peering inventory and the address-overlap rule; every new network must fit the plan or it can never be joined.
- • Own transit-hub route tables as shared infrastructure with a real review process, because their blast radius spans teams.
- • Own the periodic audit that provider-service traffic is actually taking the private path, using flow logs or NAT byte counts.
- • Private DNS not configured, so the service hostname resolves publicly and traffic goes through the NAT — working, expensive and non-private.
- • A peering assumed transitive: A→B and B→C exist, A→C fails, and nothing in either route table looks wrong.
- • Overlapping address ranges blocking a peering that the architecture already assumed, discovered during a migration.
- • An endpoint policy too narrow, blocking a legitimate operation with a permission-shaped error that sends the investigation to IAM.
- • A transit-hub route change breaking connectivity for several networks at once, with each team debugging their own side independently.
- • Endpoints scale per service and often per zone, so a large environment accumulates many small objects with small fixed charges.
- • A peering mesh grows quadratically and hits both route-entry quotas and human comprehension limits.
- • A transit hub scales linearly in attachments and centralizes the bandwidth, which makes its own throughput and route-entry limits the constraint.
- • The saving scales with data volume, so the case for a private endpoint gets stronger exactly as the workload grows.
- • Removes public internet transit for the traffic entirely, which is a genuine reduction in interception and exposure surface.
- • Enables a much stronger statement on the destination: some services can be configured to accept requests only through a named endpoint.
- • The path is enumerable — endpoints, peerings and attachments are all listable objects, which makes an exposure audit tractable.
- • It is not authorization. A private path to a service still requires that service's access control to be correct. See Infrastructure Trust Boundaries.
- • Endpoints carry small fixed charges and low or zero per-gigabyte rates; gateway-style endpoints are often free.
- • The saving comes from traffic no longer processed by a NAT device, which is usually the larger meter by a wide margin.
- • Peering bills per gigabyte transferred; transit hubs bill per attachment-hour and per gigabyte, so the mesh replacement is not free.
- • For high-volume provider traffic the endpoint typically pays for itself quickly, which makes it one of the few unambiguous wins in this domain.
- • NAT bytes processed, split by destination — a drop after adding an endpoint is the proof that the private path is actually being used.
- • Endpoint connection counts and error rates, which separate an endpoint problem from a service problem.
- • DNS resolution results from inside the subnet, verified explicitly rather than assumed.
- • The signal that lies: application success rate. Traffic taking the expensive public path succeeds perfectly; only the bill and the flow logs know.
- • A NAT device alone, when outbound volume is small — a handful of API calls does not justify an endpoint per service.
- • One network instead of several, which removes the need for peering and transit entirely and is frequently the right correction.
- • Public endpoints with strong authentication and TLS, for a low-volume third-party service that offers no private option.
- • A VPN for a single on-premises destination, rather than a transit hub, when there is exactly one connection to make.
- • Buys lower exposure and usually a lower bill; costs a set of per-service objects and a DNS dependency that fails silently.
- • Peering buys a direct private path; costs the overlap constraint forever and a mesh that does not scale.
- • A transit hub buys a manageable topology; costs a shared, billed dependency whose failures are multi-team incidents.
What people believe, and what is true
Traffic to a provider service stays inside the provider network anyway.
Without an endpoint it typically leaves through your NAT device and returns over the service's public address — billed per gigabyte and consuming NAT capacity.
Peering is transitive if I add the routes.
It is not. The provider does not forward between two peerings, regardless of what the route tables say. That is what a transit hub is for.
A private endpoint makes the service secure.
It removes internet transit and enables a stronger destination policy. The service's own authorization is still doing the work of deciding who may read what.