---
cuppy_hub: gcp
cuppy_path: reference/networking/private-service-connect.md
cuppy_section: docs
cuppy_doc: RM7V-E873
cuppy_doc_uuid: 1df16dc1-261a-4d30-b41d-a9d1fd9e5190
cuppy_permalink: https://cuppy.io/gcp/d/RM7V-E873
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/networking/private-service-connect
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 1d3cf591882e0568a4b2413875a0a505a36b294167a1be58308dba538e3fba21
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Private Service Connect

## 1. What it is

> "Private Service Connect is a capability of Google Cloud networking that allows consumers to access managed
> services privately from inside their VPC network."

The producer's service lives in the producer's VPC network. The consumer reaches it on an **internal IP
address from the consumer's own subnet**, and the traffic never leaves Google Cloud. **No peering, and
therefore no address-range overlap problem and no transitivity problem.**

## 2. The five objects, and which side owns each

| Object | Side | What it is |
|---|---|---|
| **endpoint** | **consumer** | a forwarding rule giving an internal IP address mapped to a service. The consumer initiates |
| **backend** | **consumer** | a network endpoint group used with a load balancer — more visibility and control over the traffic |
| **service attachment** | **producer** | targets the producer's load balancer, and defines the **consumer accept list** and the **NAT subnets** |
| **published service** | **producer** | the service itself, hosted in the producer's network |
| **interface** | **producer** | a network interface letting the **producer initiate** to the consumer — the reverse of an endpoint |

**Two of those five are the ones people miss.**

- a **backend** rather than an endpoint is what you want when the service should sit behind your own load
  balancer, with your own policies (including Cloud Armor) in front of it;
- an **interface** is the only object in the set that runs the other way. A producer that must call back into a
  consumer's network — a managed data plane reading a customer's database, say — needs this, not a second
  endpoint.

## 3. Why this and not peering

VPC Network Peering is **not transitive** and it joins whole address spaces. Private Service Connect joins a
**service to a consumer**, one IP address at a time. Which means:

| | Peering | Private Service Connect |
|---|---|---|
| address overlap between the two networks | a blocker | **irrelevant** |
| transitivity | none, so a hub does not route | not needed: each consumer connects directly to the service |
| blast radius | the whole peered network is reachable subject to firewall rules | one service, one address |
| who approves | both network owners | the producer, through the **accept list** on the service attachment |

For anything that is *a service* rather than *a network*, Private Service Connect is the better tool, and it is
how Google's own managed services are reached privately.

## 4. Across organizations

The documentation's own example is that it lets **"two independent companies communicate with each other by
using internal IP addresses"**. So this is not only an intra-organization mechanism: it is the private
integration path between two separate customers of Google Cloud, with the producer controlling who may connect.

## 5. For a migration estimate

Private Service Connect is the closest counterpart to **AWS PrivateLink** and **Azure Private Link**, and
Microsoft's own mapping table pairs it with Private Link directly. The object model is comparable enough that
a design ports. The two things to budget:

1. **IP address consumption.** Every endpoint takes an address from a consumer subnet. An estate with hundreds
   of private service connections needs that in the address plan — on all three clouds — and it is routinely
   left out.
2. **The producer-side work**, if you are the producer. A service attachment, a NAT subnet and an accept list
   per published service is real configuration, and it is per service rather than per consumer.

See `guides/networking/reach-a-private-service.md` for the order to build it in.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->