Prepare and test your skills
Prepare and test your skills
Private Service Connect (PSC) (opens in a new tab) is a service-sharing model that lets one Virtual Private Cloud (VPC) (opens in a new tab) network use a specific service in another network through a private internal IP address. Traffic flows from virtual machines (VMs) in the consumer VPC network to an endpoint IP address in that same network, then across Google's private backbone to the producer service, without traversing the public internet and without exposing the entire producer VPC network. This model supports first-party services, third-party software-as-a-service, and Google APIs with centralized control and least-privilege access.
Consumer and producer responsibilities in Private Service Connect separate the side that uses a service from the side that publishes it. The consumer creates a PSC endpoint, which is a forwarding rule with an internal IP address inside the consumer VPC network that represents the distant service. The producer hosts the service behind an internal load balancer and publishes it through a service attachment in the producer VPC network. Traffic flows from consumer VMs to the consumer endpoint IP address, then to the producer service attachment and load balancer, so only the published service is visible to the consumer.
The producer retains ownership of its VPC network, subnets, and backends, while the consumer controls only its endpoint, DNS, and firewall rules. The same pattern extends to hybrid access, where on-premises hosts reach a PSC endpoint in a transit VPC network over Cloud VPN (opens in a new tab) or Cloud Interconnect to consume Google APIs or a managed service in another VPC network. This replaces subnet-level reasoning with service-level reasoning, because each endpoint exposes one service with an explicit, auditable path.
Layer 4 and Layer 7 service consumption in Private Service Connect differ in producer requirements and routing behavior. At Layer 4, the producer must create one or more PSC-specific subnets, also called NAT subnets, in each region where the service is published. Private Service Connect performs source network address translation (NAT) using an IP address selected from one of the NAT subnets to route requests to the producer, which allows consumer and producer VPC networks to use overlapping IP addresses.
At Layer 7, the consumer creates a Private Service Connect backend using an internal Application Load Balancer (opens in a new tab). The internal Application Load Balancer uses a URL map to choose which services and URL paths are available to that backend. Choose Layer 4 when private TCP or UDP connectivity with overlapping address support is needed, and choose Layer 7 when HTTP routing decisions by host and path are needed.
Endpoints for Google APIs and published services provide private access to two different service locations. Published services are VPC-hosted services that run on Compute Engine VMs in a VPC network and are exposed through a service attachment, and they can be managed by Google, a third party, or your own organization. Google APIs run on Google's production infrastructure, not in a VPC network, and include services such as Cloud Storage, BigQuery, Dataproc, Cloud Logging, and Compute Engine.
A consumer VPC network uses a private IP address endpoint to reach either type without using external IP addresses. For Google APIs, you configure PSC endpoints and DNS in the VPC network for every API the workload depends on, such as dataproc.googleapis.com, storage.googleapis.com, logging.googleapis.com, bigquery.googleapis.com, and compute.googleapis.com. For a service in another VPC network, you create a consumer endpoint that points at that service's attachment, which keeps the network path explicit because traffic to one service does not share a path with other API traffic.
Configuring endpoints, attachments, and subnets in Private Service Connect follows an ordered build where consumer and producer resources depend on the base network and on Private Google Access. A typical workload project sequence is:
The transit VPC network that bridges Google Cloud and on-premises follows the same dependency order. First, the transit custom-mode VPC network is created, then a Private Service Connect subnet is added in each region where hub or on-premises services will be published. Then, for each on-premises service to expose, an internal HTTP(S) or TCP proxy load balancer is created and exposed through Private Service Connect, and Private Service Connect for Google APIs is configured for the transit VPC network.
DNS resolution and firewall enforcement for Private Service Connect ensure that service names resolve to the local endpoint and that traffic cannot bypass it. Private Cloud DNS zones in each VPC network map service names to the Private Service Connect endpoint IP address for that network. The private zone for googleapis.com. maps *.googleapis.com. with a CNAME record to restricted.googleapis.com., and restricted.googleapis.com. maps with an A record to the endpoint IP address. The same two-record pattern is used for container and artifact services:
gcr.io. maps *.gcr.io with a CNAME to gcr.io., and gcr.io. maps with an A record to the endpoint IP address.pkg.dev. maps *.pkg.dev. with a CNAME to pkg.dev., and pkg.dev. maps with an A record to the endpoint IP address.googleapis.com. maps *.googleapis.com. with a CNAME to restricted.googleapis.com., and restricted.googleapis.com. maps with an A record to the endpoint IP address.DNS resolution flows from the workload VM to the private zone in its VPC network to the endpoint IP address, so verification with dig or nslookup from a VM in the subnet should return the internal endpoint address. Enforcement depends on two firewall policy rules in each Shared VPC network: a rule that allows outbound traffic from all sources to the endpoint IP address on TCP:443, and a rule that denies outbound traffic to 0.0.0.0/0, which blocks the default domains used for Google Cloud access. This pair forces API traffic through the endpoint, so a rule can allow egress from Managed Service for Apache Spark (opens in a new tab) VMs exclusively to the BigQuery endpoint while denying all other egress.
How Private Service Connect compares to other private paths depends on path, endpoint ownership, and primary use. Private Google Access and Private Service Connect keep traffic within Google's private network, while Cloud NAT sends traffic through a NAT gateway to a service public IP address over the internet.
| Method | Path to service | Destination endpoint | Direction and scope |
|---|---|---|---|
| Private Google Access | Google private network | Google-owned address at private.googleapis.com | Outbound-only from VM to Google; enabled per subnet; Google APIs only |
| Private Service Connect | Google private network | Internal IP address endpoint owned in your VPC network | Bidirectional between VM and service; deployed per endpoint; Google APIs, third-party, and own services |
| Cloud NAT | Public internet | Service public IP address | General outbound internet access for VMs with private addresses |
Private Google Access is the simpler subnet-level method where cluster VMs contact the control plane through a shared Google address range. Private Service Connect is the granular method where each service gets a dedicated internal endpoint that supports precise firewall rules and auditing. Even clusters with internal-only addresses and Private Google Access enabled by default, such as Managed Service for Apache Spark image version 2.2 and later, gain tighter control by adding Private Service Connect endpoints for required APIs.
Exam tip: Private Service Connect connects a consumer VPC network to Google-managed services, not directly to another customer-owned VPC network or on-premises database; access to data sources in a different VPC network or on-premises still requires VPC Network Peering or hybrid connectivity with Cloud VPN or Cloud Interconnect.
VPC Network Peering (opens in a new tab) is a private connectivity method that lets workloads in two separate Virtual Private Cloud (VPC) (opens in a new tab) networks communicate using internal RFC 1918 addresses over Google's private backbone. A peering connects two VPC networks whether they are in the same project, different projects, or different organization resources, and traffic between the peers never traverses the public internet. Peering is commonly used for hub-and-spoke designs where multiple application VPC networks need access to common logging, authentication, or egress controls in a central hub VPC network.
How VPC Network Peering forwards traffic is by merging route propagation between the two peered networks while keeping firewalls separate. After peering is established, subnets, alias IP ranges, and internal forwarding rules in one VPC network become reachable from the other VPC network, with the same forwarding behavior as if all virtual machines (VMs) were in the same VPC network. Traffic flows directly from a VM in the source VPC network to a VM in the peered VPC network over Google's software-defined network, and peered VMs communicate at the full network bandwidth of the VMs. Each VPC network retains its own distributed firewall, so connectivity still depends on firewall rules in both the source VPC network and the destination VPC network.
Peering prerequisites and IP address planning require non-overlapping IP addresses between the two networks to be peered. Each VPC network is an isolated private partition with its own address space, so the same RFC 1918 range can be reused in disconnected VPC networks without conflict. Once two VPC networks are connected or peered, that reuse is no longer possible, and an overlap will prevent peering from working. Address planning must therefore reserve unique ranges for any VPC networks that will peer now or in the future, while disconnected VPC networks can safely reuse ranges to conserve address space.
Peering administration also requires watching aggregate scale. When VPC Network Peering is used, the combined resource needs of all directly peered networks must stay within limits for VM instances, number of peering connections, and internal forwarding rules. Peering is recommended when the design needs to insert network virtual appliances (NVAs), such as firewall VMs, or when an application requires full VPC-to-VPC reachability and cannot use Private Service Connect.
Transitive versus non-transitive routing in hub-and-spoke designs is the key limit of VPC Network Peering. VPC Network Peering is non-transitive, which means routes learned from one peer are not passed to another peer. In a hub-and-spoke architecture using VPC Network Peering, each workload spoke VPC network has a peering with the central routing hub VPC network, and the hub VPC network holds the hybrid connection to on-premises over Cloud VPN or Cloud Interconnect. Traffic flows from a spoke VPC network to the hub VPC network and from the hub VPC network to a spoke VPC network, but traffic does not flow from one spoke VPC network to another spoke VPC network through the hub, and on-premises routes do not automatically reach the spokes.
That limitation shapes where shared services and hybrid access live in a peering design:
Firewall control and troubleshooting peering connectivity stay local to each VPC network because peering does not merge firewall policy. The distributed Cloud Next Generation Firewall (Cloud NGFW) (opens in a new tab) in the source VPC network evaluates outbound traffic and the Cloud NGFW in the destination VPC network evaluates inbound traffic. A connection fails if either side lacks an allow rule for the protocol, port, and source identity, even when routes are correctly exchanged.
Troubleshoot a failed peering by checking boundaries in order. First, verify that subnet ranges, including secondary alias ranges for containers, do not overlap between the two VPC networks. Then, verify that peering is configured on both sides and that required subnet routes and internal forwarding rules are visible in each VPC network. Finally, verify firewall rules on both VPC networks, including hierarchical firewall policies applied at the organization or folder level, and confirm that DNS peering and forwarding and Cloud NAT for internet egress are configured separately in each VPC network where they are needed.
Choosing VPC Network Peering over other inter-VPC options depends on transitivity, performance, address reuse, and inspection needs. VPC Network Peering provides full-bandwidth private connectivity with merged forwarding, Cloud VPN (opens in a new tab) between VPC networks provides transitive connectivity limited by tunnel bandwidth, and Network Connectivity Center (NCC) (opens in a new tab) VPC spokes provide scalable transitive connectivity with centralized route exchange.
| Option | Reachability | Choose when |
|---|---|---|
| VPC Network Peering | Non-transitive between peers; full VM bandwidth; requires non-overlapping IPs | The design needs NVA insertion or full subnet-level access without Private Service Connect |
| NCC VPC spokes | Transitive across up to 250 VPC networks per hub; distributed data plane with no gateway bottleneck | The design needs any-to-any VPC connectivity, cross-organization reach, or integrated inter-VPC Cloud NAT for address reuse |
| Cloud VPN between VPC networks | Transitive through hub with custom advertisement; bandwidth limited by tunnels | The design needs transitive reach to service access points that are not transitively reachable over NCC |
A centralized hybrid design can combine these options by terminating Dedicated Interconnect, Partner Interconnect, or HA VPN in one or more connectivity VPC networks and sharing those routes to spokes through NCC route exchange or through VPC Network Peering custom routes.
Exam tip: VPC Network Peering does not provide transitive route announcements, while Cloud VPN and Network Connectivity Center (NCC) VPC spokes do allow transitive reach through a hub.
Shared VPC (opens in a new tab) is a centralized networking model in Google Cloud where one host project owns the Virtual Private Cloud (VPC) (opens in a new tab) network and one or more service projects own the workloads that use it. The host project contains subnets, routes, and firewalls, while each attached service project contains instances such as Compute Engine VMs that receive internal IP addresses from the shared subnets. This split lets a central network team control connectivity and policy once, while workload teams deploy and manage their own resources without making network-impacting changes.
Centralized ownership with host projects and service projects defines who owns the network and who owns the workloads in Shared VPC. The host project holds a global VPC network whose subnets span regions and zones, so VMs in any region or attached service project communicate privately over Google's backbone using local VPC routes. A service project is attached to the host project to participate in Shared VPC, and that attachment determines which subnets its VMs, clusters, and other resources can use. For stronger isolation, an organization can define two VPC networks in two host projects and attach separate service projects for production and testing, which keeps test and production traffic and administration in distinct networks.
Centralized management in the host project covers the core networking controls that all service projects inherit through attachment. The host team manages peering configuration, subnet configuration, Cloud Firewall (opens in a new tab) configuration, and permission configuration from one place:
Because VPC resource quotas are enforced at the project level, the aggregate demand of all attached service projects counts against the limits of the host project design. When scale or administrative separation requires it, the design moves from one shared network to multiple host projects with their own Shared VPC networks.
Identity and Access Management (IAM) (opens in a new tab) separation for network and workload administration enforces least privilege between central network owners and workload owners. Network and security administrators receive roles in the host project to create subnets, routes, and firewall rules, while instance administrators in service projects receive permissions only to create and manage instances in authorized subnets. IAM policies assigned at the organization, folder, or host-project level are inherited by lower resources and cannot be altered by owners lower in the hierarchy, which preserves central control over network policy.
Subnet-level sharing is the mechanism that enforces security and operational boundaries between teams and environments. Granting the network user role at the subnet level limits a service project to only its assigned subnets, while granting it at the host-project level makes all subnets available to that service project. A common pattern is to dedicate a different subnet to each service project for team or environment isolation, or to share the same subnets between service projects when workloads have common requirements and trust. Choose subnet-level grants when different teams, data sensitivities, or environments must not be able to select each other's address space.
Subnet allocation and global VPC foundation in Shared VPC start with a custom-mode VPC network in the host project. Custom-mode networks integrate with existing IP address management because every subnet and IP range is explicitly created by the network team, and they avoid the overlap problem of auto-mode networks, which use the same internal ranges and therefore cannot be peered with each other. Because each VPC network is a fully isolated virtual partition with its own private IP space, the same RFC 1918 addresses can be reused in disconnected VPC networks, but addresses must not overlap once networks are connected or peered.
Each subnet is a regional resource with a non-overlapping CIDR range, and best practice is to enable Private Google Access (opens in a new tab) on every workload subnet. Private Google Access is enabled at the subnet level and lets VM instances without external IP addresses reach Google APIs and services while remaining isolated from the public internet. Grouping applications into fewer subnets with larger ranges simplifies route, firewall, and IAM management, while still allowing per-team boundaries by assigning different service projects to different subnets or different host projects.
Provisioning order for host and workload projects creates the network authority first in the host project and then grants controlled use to each workload service project. The host project must have the Compute Engine API enabled and Shared VPC configured before subnets are shared, and each service project must have the Compute Engine API enabled before it is attached.
Traffic flows from instances in the service project into subnets owned by the host project, so the service project depends on the host project for routing, firewall evaluation, and hybrid connectivity. Repeating the workload steps for each additional service project preserves centralized network ownership while scaling to many teams, and repeating the full sequence creates parallel environments such as non-production and production.
Scaling with single or multiple host projects balances quota scale, network-interface constraints, and administrative independence. A single Shared VPC network fits resources with common routing, firewall, and operational requirements, while multiple Shared VPC networks fit autonomous teams, sensitive data, or scale beyond one project's limits.
| Design | Use when | Tradeoff or boundary |
|---|---|---|
| Single host project | Workloads require multiple network interfaces on the same instances | All bridged VPC networks must reside in the project that hosts the multi-NIC appliance, so aggregate VPC resources share one project quota |
| Multiple host projects | Resource demand exceeds a single project quota or each VPC needs separate administration policies | Each host owns its subnets, firewalls, and peering independently, which increases isolation but requires duplicated network management |
Use multiple host projects when independent IAM controls are needed for different business units, when sensitive data must be isolated in its own VPC network, or when centralized hybrid connections and shared services must scale without hitting per-project limits. Use a single host project when centralized appliances or multi-NIC VMs must bridge networks, because that bridging depends on all involved VPC networks living in the same project.
Exam tip: Grant the network user role at the subnet level for least-privilege isolation, and keep multi-network-interface workloads in a single host project because multi-NIC bridging requires all VPC networks to reside in the same project.
*.googleapis.com with a CNAME to restricted.googleapis.com and an A record to the Private Service Connect endpoint IP address, paired with firewall rules that allow TCP:443 to the endpoint and deny 0.0.0.0/0.Private Service Connect (PSC) exposes one published service through an internal endpoint IP address in the consumer Virtual Private Cloud (VPC) network that connects to a producer service attachment and internal load balancer, while VPC Network Peering merges route propagation between two VPC networks so subnets in each network become reachable from the other. Peering is non-transitive and requires non-overlapping RFC 1918 ranges, whereas PSC at Layer 4 performs source network address translation using producer NAT subnets so consumer and producer networks can use overlapping addresses.
Choose Layer 4 in Private Service Connect (PSC) when private TCP or UDP connectivity with overlapping address support is needed, and choose Layer 7 when HTTP routing decisions by host and path are needed. Layer 4 requires the producer to create PSC-specific NAT subnets in each region where the service is published, while Layer 7 uses a consumer internal Application Load Balancer with a URL map to choose which services and URL paths are available.
In Shared VPC, the host project owns the Virtual Private Cloud (VPC) network including subnets, routes, firewalls, and peering configuration, while attached service projects own workload instances that receive internal IP addresses from the shared subnets. Least-privilege isolation is enforced by granting the network user role at the subnet level so a service project can use only its assigned subnets.
Private Cloud DNS zones in each Virtual Private Cloud (VPC) network map service names to the local Private Service Connect (PSC) endpoint IP address, where the private zone for googleapis.com maps wildcard googleapis.com with a CNAME to restricted.googleapis.com and restricted.googleapis.com with an A record to the endpoint address. Enforcement uses a firewall rule that allows outbound traffic to the endpoint IP address on TCP port 443 paired with a rule that denies outbound traffic to 0.0.0.0/0, which forces API traffic through the endpoint.
Your organization operates a multi-VPC architecture across multiple Google Cloud projects. You have a central hub network named hub-vpc (10.0.0.0/16) that is connected via VPC Network Peering to spoke-a-vpc (10.1.0.0/16). You deploy a new custom VPC named spoke-b-vpc (10.2.0.0/16) and configure VPC Network Peering between spoke-b-vpc and hub-vpc.
Workloads running in spoke-b-vpc must directly access backend services running in spoke-a-vpc over private RFC 1918 IP addresses. Currently, network traffic from spoke-b-vpc fails to reach spoke-a-vpc. Furthermore, the ingress firewall rules in spoke-a-vpc only allow traffic originating from 10.1.0.0/16.
How should you resolve the connectivity issue while adhering to Google Cloud networking best practices?
Last updated