Private service access in Google Cloud provides secure, private connectivity to managed services without traversing the public internet. The primary methods for achieving this are Private Service Connect (PSC), VPC Network Peering, and Private Google Access, each serving distinct use cases and offering different levels of control and security.
Private Service Connect enables private access to Google-managed services by creating a private endpoint with an internal IP address inside your VPC network that maps directly to a specific Google service. Unlike Private Google Access, which uses a shared set of endpoints to connect to Google APIs, PSC provides fine-grained control over which services can be accessed and allows you to create firewall rules that permit traffic exclusively to the PSC endpoint IP address. This approach makes the network path explicit and easier to audit for security and compliance, since traffic to a service such as Cloud Storage does not share a path with other API traffic. PSC supports accessing Google APIs, third-party services, and your own services published through service attachments.
VPC Network Peering establishes a peering connection between two VPC networks, allowing route exchange between the consumer and producer networks. When you configure private services access, Google Cloud establishes a VPC peering connection between your VPC network and the service producer's VPC network. A key requirement is that you must allocate a dedicated internal IP address range for the service producer's use, which is reserved and cannot be used in your own VPC to prevent IP address conflicts. Once connected, the two networks always exchange subnet routes, and you can optionally import both static and dynamic custom routes if configured to export them. VPC peering is not transitive, meaning traffic cannot flow through a peered network to reach a third network.
Private Google Access and Private Service Connect keep traffic within Google's private network without traveling over the public internet, which is ideal for security and predictable performance. Cloud NAT, by contrast, reaches a Google Cloud service by connecting to a public endpoint, with traffic leaving your VPC network through the NAT gateway and traveling over the internet. Private Service Connect offers significant enhancements compared to private services access, including network transitivity and lower consumption of IP addresses, making it the recommended solution for most scenarios. VPC Network Peering is simpler to configure and suitable for small-scale, single-VPC scenarios with minimal cost, while PSC provides better security through isolation of consumer and producer VPC networks.
For scenarios requiring access to Google services like Cloud Storage or BigQuery without sending traffic over the public internet, Private Service Connect offers a solution. When connecting your on-premises network to Google Cloud using multiple hybrid networking connections, you can send some traffic from on-premises to specific Google APIs or published services over one connection and the rest over another connection. You can also use Private Service Connect global access to provide failover options. For gated ingress patterns, traffic passes through a Private Service Connect endpoint in your application VPC associated with the service producer's VPC, with an internal load balancer used to expose application APIs through the PSC endpoint. Firewall rules and traffic filtering at the application VPC provide fine-grained, controlled access and help prevent systems from directly reaching applications without passing through the PSC endpoint and API gateway.
Private Service Connect connects to Google-managed services but not directly to other customer VPC networks; if your data sources or custom applications are in a different VPC network, VPC peering is typically required. For on-premises networks accessing Dataproc clusters, you need a Cloud VPN or Cloud Interconnect connection, often combined with VPC peering. While PSC provides private access to configured Google services such as Cloud Storage and BigQuery, internal control plane communications or specific features might require VPC peering to access underlying Google infrastructure. Choose VPC Network Peering when you need to insert network virtual appliances or when your application doesn't support Private Service Connect, and choose PSC when you need granular security control, explicit network path auditing, or connectivity to multiple VPC networks from a single endpoint.
Private Service Connect (PSC) is a Google Cloud networking capability that allows consumers to privately access managed services and Google APIs across Virtual Private Cloud (VPC) networks without using public IP addresses or VPC peering. The connection is established between a service attachment published in the service producer VPC and a private endpoint or backend deployed in the consumer VPC. This architecture keeps traffic entirely within Google's private network, preventing data from traveling over the public internet.
A service attachment is a producer-side resource that exposes a service to consumer VPC networks through a unique target uniform resource identifier (URI). The producer defines connection policies by maintaining a consumer accept list (consumerAcceptList), which explicitly specifies the Google Cloud project IDs allowed to connect to the attachment. If an administrator removes a consumer project from the accept list, existing active network endpoint groups in that project continue to function, but all new connection requests are rejected. Multiple producer service instances can share a single service attachment when they share identical project allowlists, simplifying attachment management across multi-tenant deployments.
A Private Service Connect endpoint is a consumer-side forwarding rule that assigns an internal IP address from a consumer VPC subnet to target a producer's service attachment. Consumer workloads and connected on-premises hosts route traffic to this single internal IP address, which supports both RFC 1918 and non-RFC 1918 addressing schemes. Because the endpoint resides directly within the consumer VPC, network administrators can enforce strict egress VPC firewall rules that allow traffic exclusively to the endpoint's specific IP address while blocking all other outbound paths. Over hybrid connections using Cloud VPN or Cloud Interconnect, Cloud Router can advertise the endpoint subnet to extend private service access to on-premises environments.
A Private Service Connect backend uses a network endpoint group (PSC NEG) to link a consumer-managed regional internal or external HTTP(S) load balancer to a producer service attachment. When deploying regional Envoy-based load balancers with PSC backends, the consumer VPC must include a dedicated proxy-only subnet configured with the regional managed proxy purpose. This architecture enables advanced traffic management, logging, monitoring, and integration with Google Cloud Armor security policies before traffic reaches the producer. For high availability across multiple PSC NEGs, active health checks are not supported, requiring administrators to configure outlier detection within the traffic management policies instead.
A Private Service Connect interface is a specialized network interface that allows traffic to originate from a producer VPC and flow outward into a consumer VPC network. Because the interface resides inside the consumer environment, the producer organization cannot manage consumer VPC firewall rules directly. To protect the producer workload from unauthorized consumer-initiated connections, administrators configure guest operating system policies using iptables to drop unsolicited ingress traffic while permitting established and related reply packets. Creating a PSC interface requires the compute.instances.pscInterfaceCreate permission, which is granted through the Compute Admin or Compute Instance Admin (v1) Identity and Access Management (IAM) roles.
Choosing between Private Service Connect and private services access (PSA) depends on IP space availability, scalability requirements, and transit routing needs. Private services access relies on underlying VPC Network Peering, which requires consumers to allocate large CIDR blocks (such as a /16 prefix) and does not support transitive routing across multiple network hops. In contrast, Private Service Connect requires only a single IP address per endpoint, prevents IP address overlap issues, and provides unidirectional isolation by default. While PSC incurs costs for endpoint hours and processed data transfer, it eliminates VPC peering limits and enables secure multi-tenant network topologies.
Evaluating the security, routing, and operational implications of accessing managed services through Private Service Connect (PSC) and VPC Network Peering involves analyzing how each method controls access, directs traffic, and impacts ongoing management. This assessment is critical for designing resilient hybrid and multi-cloud networks where private connectivity to Google Cloud services like Dataproc, Cloud SQL, and Vertex AI is required. The choice between these methods affects network security posture, path predictability, routing complexity, and administrative overhead.
The security posture of private access methods is defined by the granularity of access controls, the network path data traverses, and integration with broader security frameworks. Private Service Connect (PSC) creates a private endpoint with a dedicated internal IP address inside your VPC network that maps directly to a specific Google service. This allows for fine-grained firewall rules that can restrict egress traffic from consumer VMs exclusively to that endpoint IP, a more secure approach than the broader rules required with Private Google Access (PGA). Traffic using PSC remains within Google's private network and does not travel over the public internet, enhancing security and providing predictable performance. In contrast, Cloud NAT reaches services via public endpoints, sending traffic over the internet and exposing it to potential interception.
VPC Network Peering, which underlies the older Private Services Access (PSA) method, establishes a direct, bi-directional peering connection between consumer and producer VPC networks. While this provides private connectivity, it results in a full exchange of subnet routes between the peered networks, which can expand the attack surface if not carefully governed with firewall rules. PSC offers enhanced isolation as the consumer and producer VPCs remain separate, with connections typically being unidirectional (inbound) by default unless specifically configured for outbound traffic. Both methods integrate with Identity and Access Management (IAM) for authorization and can be enclosed within VPC Service Controls perimeters to guard against data exfiltration, with PSC endpoints often used as controlled ingress points within these perimeters.
Routing behavior determines how traffic flows between on-premises, multi-cloud environments, and Google Cloud services, impacting latency, cost, and failover capabilities. With Private Service Connect, the network path is explicit and easier to audit. A consumer creates a forwarding rule in their VPC that references a producer's service attachment, creating a private IP endpoint. Traffic from the consumer VPC, or from on-premises systems via hybrid connections (Cloud VPN or Cloud Interconnect), is directed to this endpoint. PSC supports global access, allowing endpoints in one region to be reachable from VPC networks in other regions, which provides failover options and simplifies multi-region architectures. You can also deploy multiple PSC endpoints in the same VPC network and control paths using Cloud Router and firewall rules, enabling complex routing policies—for example, sending traffic from on-premises to specific Google APIs over one hybrid connection and other traffic over another.
VPC Network Peering, used by PSA, creates a transitive routing relationship. Once peering is active, the networks automatically exchange subnet routes. For hybrid connectivity, the consumer VPC must export its custom routes so the producer's network can correctly route traffic back to on-premises systems. This can lead to routing complexity, especially in multi-VPC or multi-cloud hub-and-spoke topologies. A key limitation is that VPC peering is not transitive; a VPC peered with two others does not automatically route traffic between those two. This often necessitates additional peering connections or the use of a central transit VPC, increasing operational complexity. PSC, through endpoints or backends, can provide transitive reachability across VPC spokes when used with Network Connectivity Center, offering a more scalable routing model for large environments.
Operational management encompasses the lifecycle administration of connections, quota and limit considerations, and the complexity of ongoing configuration changes. Private Service Connect generally simplifies operational management compared to PSA/VPC Peering. Setting up PSC for a service like Dataproc Metastore or Cloud SQL involves creating an endpoint in a subnet, which reserves a single IP address and creates a forwarding rule. This consumes fewer IP addresses and does not require dedicating large CIDR blocks, unlike PSA which requires allocating a reserved IP address range (e.g., /16) from the consumer's VPC for the producer's use. PSC also does not consume VPC peering quotas, which can be a limiting factor in crowded networks.
However, PSC has its own operational constraints. For example, a Dataproc Metastore service configured with PSC cannot dynamically add or remove subnetworks; the service must be recreated. Similarly, updating a service from PSC to VPC peering (or vice versa) is not supported and requires recreation. VPC Network Peering operations involve managing peering connections, which have limits on the number of active peerings per network and per project. Scaling beyond these limits may require architectural changes, such as creating multiple VPC networks. Operationally, peering also requires coordination between network administrators of both the consumer and producer projects to establish and maintain the connection, whereas PSC allows a consumer to connect to a producer's published service attachment without direct coordination after the service is exposed.
The choice between these methods involves trade-offs between granular security control (PSC) versus broad internal connectivity (VPC Peering), between simplified routing (PSC with global access) versus complex transitive routing (peering), and between per-endpoint operational overhead (PSC) versus per-peering connection overhead (VPC Peering). For most new deployments, especially those requiring secure, granular access to managed services in hybrid or multi-cloud setups, Private Service Connect is the recommended solution due to its enhanced security model, network transitivity, and more efficient IP address consumption.
StudyCerts
StudyCerts/16 prefix) for the producer's use, while PSC requires only a single IP address per endpoint.Private Service Connect (PSC) creates a private endpoint with a single internal IP address in the consumer VPC, requires no large CIDR allocation, supports transitive routing, and provides unidirectional isolation by default. Private services access (PSA) relies on VPC Network Peering, requires the consumer to allocate a large reserved IP range (such as a /16 prefix) for the producer, does not support transitive routing, and exchanges subnet routes bi-directionally between the peered networks.
Choose VPC Network Peering when you need to connect directly to other customer VPC networks, insert network virtual appliances, or when your application does not support Private Service Connect. VPC peering is also simpler to configure for small-scale, single-VPC scenarios. You may also need VPC peering for internal control plane communications or specific features that require access to underlying Google infrastructure, which PSC does not provide.
Private Service Connect extends to on-premises networks through hybrid connections using Cloud VPN or Cloud Interconnect. Cloud Router can advertise the endpoint subnet to the on-premises environment, allowing on-premises hosts to route traffic to the PSC endpoint's internal IP address. You can also deploy multiple PSC endpoints in the same VPC and use Cloud Router with firewall rules to control paths, such as sending traffic to specific Google APIs over one hybrid connection and other traffic over another.
Private Service Connect has specific operational constraints: a Dataproc Metastore service configured with PSC cannot dynamically add or remove subnetworks and must be recreated to do so, and updating a service from PSC to VPC peering (or vice versa) is not supported and requires recreation of the service. PSC also incurs costs for endpoint hours and processed data transfer, though it does not consume VPC peering quotas.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills