Private Service Connect (PSC) is a networking mechanism that lets organizations access managed services privately without exposing traffic to the public internet. PSC works by creating a special endpoint in your Virtual Private Cloud (VPC) network that connects directly to a service producer's attachment. When you allocate an IP address for PSC, it starts in a RESERVED state, and when the connection is established, the status changes from PENDING to ACCEPTED in system logs. All data traffic between the consumer and the managed service flows through these private endpoints, keeping everything within Google's network infrastructure.
In a Shared VPC setup, service project administrators can deploy PSC endpoints using IP addresses from host project subnets. The host project administrator must grant the Compute Network User role to enable this cross-project resource assignment. If clients in other regions or on-premises environments need to reach the PSC endpoint, administrators enable the global access option on the forwarding rule. This creates a secure, one-way communication channel from the consumer network to the service producer.
Google Cloud combines multiple security layers to protect private service access. Organization policy administrators can use the constraint constraints/compute.disablePrivateServiceConnectCreationForConsumers to block users from creating certain types of endpoint forwarding rules. The policy compute.restrictPrivateServiceConnectProducer limits connections to verified producer organizations or Google-owned services identified by organization ID 433637338589. If an endpoint configuration violates these policies, resource creation fails automatically during the control-plane validation step.
VPC firewall rules add another protection layer by filtering traffic directed toward PSC endpoints. For advanced routing scenarios, static routes can use a Network Load Balancer's forwarding rule as a next hop to reach PSC endpoints in the same VPC and region. However, routing configurations cannot specify a next hop by load balancer IP address, PSC endpoint name, or endpoint IP address. Administrators monitor connection changes and audit events using VPC Flow Logs and Cloud Audit Logs to track unauthorized access attempts.
VPC Service Controls (VPC-SC) adds perimeter security that works independently from IAM to prevent data exfiltration from Google Cloud services. When a VPC network containing a PSC endpoint sits inside a VPC-SC service perimeter, the endpoint becomes part of that perimeter, and all supported services accessed through it are enforced by perimeter boundaries. Creating a PSC connection between consumer and producer projects in different perimeters does not require explicit egress rule authorization for the initial handshake, but all subsequent data traffic remains governed by the destination service's perimeter policy.
Private access to Google APIs under perimeter controls uses the restricted virtual IP range 199.36.153.4/30. Network administrators configure Cloud DNS private managed zones to map API domains like *.googleapis.com to these virtual addresses. When VPC-SC is enabled across peered VPC networks, default internet routes in the producer project are removed to prevent unauthorized external access. Workloads needing outbound internet access must route through customer-managed NAT gateways, standard web proxies, or Secure Web Proxy instances deployed within the consumer VPC.
Service connection policies automate how PSC endpoints are created and managed in consumer VPC networks. A network administrator configures a policy by specifying a target network, region, service class (such as google-cloud-sql), allowed subnets for address allocation, and optional connection limits. When the managed service and connection policy exist in separate resource hierarchies, the administrator configures a custom service instance scope with authorized project, folder, or organization IDs. The managed service then automatically provisions internal endpoints into the designated consumer subnets.
For workloads requiring bidirectional communication, a Private Service Connect interface provides a dedicated network path into the consumer VPC using network attachments. Administrators create a network attachment in the host or service project and grant the Compute Network Admin role or specific attachment update permissions to the producer service agent. Private DNS peering works alongside the PSC interface to resolve dynamic service IP addresses, allowing producer agents to look up human-readable internal hostnames through the consumer VPC's Cloud DNS private zones.
Private Service Connect is a Google Cloud service that enables private, secure connectivity to managed services across hybrid and multi-cloud environments without exposing traffic to the public internet. It uses a producer-consumer model where a service producer publishes a service using a service attachment, and a service consumer connects through a PSC endpoint within their own VPC network. This model provides explicit control over network paths, enhances security through isolation, and simplifies connectivity compared to older methods like VPC peering.
A PSC endpoint is a consumer-side resource that provides a private IP address within the consumer's VPC network, mapping to a specific published service. The consumer creates a forwarding rule referencing the producer's service attachment URI, which creates this internal IP endpoint. Traffic from resources within the consumer VPC or from on-premises systems over hybrid connections flows to this private IP address and routes privately through Google's network to the producer service. This design keeps all traffic off the public internet and allows fine-grained firewall rules scoped to the specific endpoint IP address.
A service attachment is the producer-side connection point for a managed service. The producer, such as a Google API service like Cloud Storage or BigQuery, creates this attachment typically associated with an internal load balancer in their VPC. The service attachment includes a consumer accept list and consumer reject list, which the producer uses to approve or deny connection requests based on the consumer's project, VPC network, or specific PSC endpoint. This gives producers control over which consumers can access their service.
PSC supports two primary connectivity models: endpoints and backends. With a PSC endpoint, traffic flows directly from consumer resources to the endpoint's private IP and then to the producer's service. With a PSC backend, the consumer uses a PSC Network Endpoint Group as a backend for an internal or external regional load balancer. This adds a load balancer hop but enables advanced features like logging, monitoring, traffic management, Google Cloud Armor integration, and transitivity over VPC peering.
The transitivity property is a key advantage over Private Services Access. A consumer in a peered VPC can access the PSC service without requiring a direct connection to the producer's VPC. This eliminates complex full-mesh peering arrangements and avoids IP range conflicts that often occur in large-scale deployments.
Private Service Connect is the recommended solution over the older Private Services Access (PSA). PSA relies on VPC Network Peering and requires the consumer to allocate a dedicated, non-overlapping RFC 1918 IP range for the producer's use, which becomes unavailable in the consumer's VPC. PSC endpoints consume only a single IP address per endpoint from the consumer's subnet. PSA connections are bidirectional by default, while PSC connections are unidirectional (inbound-only from consumer to producer) unless specifically configured for outbound. PSC also offers superior security through explicit endpoint isolation and better scalability for multi-VPC and hybrid scenarios.
Security in PSC combines IAM permissions, VPC firewall rules, and producer consumer accept/reject lists. Producers control initial access through service attachment lists. Consumers apply VPC firewall rules to control which subnets or IP ranges can initiate traffic to the PSC endpoint's IP address. For scenarios where the producer must initiate traffic to the consumer (such as a managed service calling back into the customer's network), PSC interfaces using network attachments are used. These are producer-managed interfaces placed in the consumer's VPC, and the consumer can limit ingress using subnet-based firewall rules.
For hybrid connectivity, on-premises systems reach PSC endpoints over Cloud VPN or Cloud Interconnect. The consumer's VPC advertises the route to the PSC endpoint's private IP over these connections. For multi-cloud or complex multi-VPC environments, the transitivity property of PSC backends is crucial: a consumer in VPC A can access a PSC service published in VPC B if VPC A is peered to a VPC that has a PSC endpoint, without needing direct peering between VPC A and the producer's VPC.
Serverless VPC Access enables Cloud Run, Cloud Functions, and App Engine standard environment to connect directly to resources inside a VPC network using private IP addresses without routing traffic over the public internet. This capability is essential for applications that must access managed databases, internal APIs, or other VPC-hosted resources while maintaining network isolation and reducing exposure to external threats.
A Serverless VPC Access connector acts as a bridge between serverless runtime environments and the VPC network. When you configure a serverless service to use a connector, outbound traffic flows through the connector into your VPC, allowing access to internal IPs, Cloud SQL instances, Memorystore, GKE clusters, and other VPC resources. The connector handles routing and scales automatically to accommodate traffic demands without requiring you to manage underlying compute infrastructure. Traffic flows from the serverless service to the connector, then from the connector into the VPC toward the target resource.
The three serverless platforms integrate through the same connector mechanism but have different configuration interfaces. Cloud Run services configure VPC connectivity by specifying the connector's fully qualified name in the service's VPC connector settings. Cloud Functions (both 1st gen and 2nd gen) enable VPC connector configuration through the function's runtime settings. App Engine standard environment applications configure VPC connectivity through the app.yaml file by specifying the connector name. In all cases, the application code connects to the target resource using its internal VPC IP address or DNS name, and the connector handles the network transit.
Serverless VPC Access eliminates the need for intermediate proxies when connecting to managed services that support private IP connectivity. When connecting to a Cloud SQL instance with private IP enabled, a Cloud Run service connects directly through the Serverless VPC Access connector without deploying the Cloud SQL Auth Proxy. The application uses the Cloud SQL instance's private IP address as the connection target, and the connector ensures traffic stays within the VPC boundary. This direct connection reduces latency, simplifies the architecture, and removes the operational burden of maintaining a separate proxy. The same pattern applies to Memorystore for Redis, Bigtable, and Spanner when configured with private service access.
Deploying a Serverless VPC Access connector requires allocating a dedicated IP address range from your VPC subnet for the connector's instances. This range must not overlap with any existing subnet ranges in your VPC or peered VPC networks. The connector uses these IP addresses as the source for outbound traffic flowing from serverless services into the VPC. Egress path selection directs all outbound traffic through the connector, which forwards packets based on the VPC's routing tables. Because the connector appears as a logical instance within your VPC subnet, it inherits the VPC's routing behavior, including custom routes to on-premises networks via Cloud VPN or Cloud Interconnect. Each serverless service or function can only use a single VPC connector at a time.
Managing Serverless VPC Access requires understanding the IAM roles that control connector operations. The Serverless VPC Access Admin role grants full permissions to create, delete, update, and use connectors, along with the ability to list locations and view operationsāappropriate for network administrators setting up connector infrastructure. The Serverless VPC Access User role grants permissions to use an existing connector and list its details, suitable for developers deploying Cloud Run services or Cloud Functions needing VPC connectivity. The Serverless VPC Access Service Agent role is a service account role that Google Cloud uses internally to manage connector resources. The Serverless VPC Access Viewer role provides read-only access to list and describe connectors, useful for auditors or developers verifying configuration.
Private Service Connect differs fundamentally from Serverless VPC Access. Serverless VPC Access creates a connector in your VPC that handles all outbound traffic from serverless workloads. PSC creates a dedicated endpoint with a single IP address in your VPC that consumers use to reach a specific published service. For managed services like Cloud SQL, you can choose between private services access and PSCāPSC consumes only one IP address regardless of how many service instances you connect to, making it more scalable for accessing many different managed services. Serverless VPC Access is simpler for serverless workloads needing broad access to many resources within a single VPC, while PSC provides granular control over specific service endpoints and minimizes IP address consumption in large-scale deployments.
StudyCerts
StudyCerts199.36.153.4/30 and requiring NAT gateways or proxies for outbound internet access.Private Service Connect uses dedicated endpoints with single IP addresses and supports transitivity over VPC peering, while Private Services Access uses VPC Network Peering and requires allocating dedicated IP ranges that cannot be used in the consumer's VPC. PSC connections are unidirectional by default, while PSA connections are bidirectional.
Use Serverless VPC Access when serverless workloads need broad access to many resources within a single VPC, as it handles all outbound traffic through a single connector. Use PSC when you need granular control over specific service endpoints or want to minimize IP address consumption in large-scale deployments with many managed services.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills