This chapter covers two critical networking features in Google Cloud: Private Google Access (PGA) and Private Service Access (PSA). These technologies enable VM instances with internal (private) IP addresses to access Google APIs and services, and to connect to managed services like Cloud SQL or Memorystore without traversing the public internet. For the ACE exam, expect 2-3 questions on this topic, often testing the differences between PGA and PSA, their use cases, and configuration steps. Mastering these concepts is essential for designing secure, cost-effective, and high-performance network architectures.
Jump to a section
Imagine you work in a large corporate office building (your VPC). The building has a private internal mailroom (Private Google Access) that can request books from the company's vast internal library (Google APIs and services). To use the mailroom, you must first ensure the mailroom is enabled for your floor (subnet). When you send a request via the mailroom, it uses a special internal courier (default route with next hop 'default internet gateway') but the courier's badge identifies him as a building employee, so the library knows he's internal. The library delivers the book directly to your desk via the internal mail chute, never leaving the building. In contrast, for accessing a third-party bookstore across town (on-premises or other cloud), you need a dedicated, private shuttle service (Private Service Access). This requires you to set up a reserved pickup spot (peering connection) and a specific route that goes through a secure tunnel (VPC Network Peering). The shuttle has its own schedule and capacity limits, and you must coordinate with the bookstore to ensure the shuttle can park at their loading dock. If you try to use the mailroom for the bookstore, the bookstore will refuse delivery because the courier's badge is not recognized. Similarly, if you use the shuttle for the internal library, it's overkill and may cause delays. The key difference: Private Google Access is a one-way, outbound-only connection from your VPC to Google services using internal IPs, while Private Service Access is a two-way, peered connection to services owned by Google or other parties that are not in your VPC.
What is Private Google Access and Why Does It Exist?
Private Google Access (PGA) is a feature that allows VM instances in a VPC network to reach Google APIs and services using their internal IP addresses, even if the instances do not have external IP addresses. Without PGA, VMs without external IPs cannot access any Google service (e.g., Cloud Storage, BigQuery, Google Cloud APIs) because traffic would be sent to the default internet gateway, which requires an external IP for return traffic. PGA solves this by enabling a special routing path: when a VM sends traffic to the IP range of Google APIs (e.g., 199.36.153.4/30 for the restricted VIP), the VPC routes that traffic through a Google-owned path that does not require an external IP. The traffic stays within Google's network, never traversing the public internet.
Private Service Access (PSA) is a different mechanism. It is used to connect your VPC network to a Google-managed service that is not natively hosted within your VPC, such as Cloud SQL, Memorystore (Redis), Cloud Filestore, or Cloud Bigtable. These services run in VPCs owned by Google (tenant projects). PSA establishes a VPC Network Peering connection between your VPC and the service producer's VPC, allowing your VMs to access the service using internal IP addresses from a reserved subnet (e.g., 10.0.0.0/28) that you allocate for the service. This is a two-way peering, but only the service consumer (you) can initiate connections to the service; the service producer cannot initiate connections to your VPC.
How Private Google Access Works Internally
When a VM with an internal IP (e.g., 10.0.0.5) tries to reach storage.googleapis.com, DNS resolves the hostname to a Google API IP address. By default, the VM's default route (0.0.0.0/0) points to the default internet gateway. Without PGA, the packet would be sent to the gateway, which expects the source IP to be an external IP for return traffic. Since the VM has no external IP, the gateway drops the packet. With PGA enabled on the subnet, the VPC routes traffic to Google API IPs through a special internal path. Specifically, Google Cloud uses a set of IP ranges for its APIs: the "restricted" VIP range (199.36.153.4/30) and the "private" VIP range (199.36.153.8/30). When PGA is enabled, the VPC automatically adds a route for these IP ranges with a next hop of "default internet gateway" but with a special flag that tells the gateway to forward the traffic internally. The gateway then sends the traffic over Google's backbone to the requested API endpoint. The response follows the same path back to the VM, using the internal IP as the destination. This works because the gateway recognizes the destination as a Google API IP and handles it specially.
Key points:
PGA is a per-subnet setting. You enable or disable it on individual subnets.
PGA only works for Google APIs and services that are published in the restricted or private VIP ranges. Not all Google services are accessible via PGA (e.g., Google Maps API may not be).
The VM does not need an external IP. However, it must have a route to the Google API IPs (which is automatically added when PGA is enabled).
Traffic is not encrypted by default; use HTTPS to encrypt.
PGA is free of charge; you only pay for standard data transfer costs.
How Private Service Access Works Internally
PSA uses VPC Network Peering to connect two VPCs: your consumer VPC and the service producer's VPC. The process involves several steps:
Allocate an IP range: You must reserve a contiguous IP range (e.g., /24) from your VPC's address space to be used by the service. This range must not overlap with any existing subnets or static routes in your VPC.
Create a private connection: You initiate a request to create a private connection to a service producer (e.g., Cloud SQL). This creates a VPC peering connection between your VPC and the producer's VPC.
Accept the peering: The service producer automatically accepts the peering (for Google-managed services). The peering is then active.
Create a service attachment: For services like Cloud SQL, you create a private service connection that defines which IP range to use.
Provision the service: When you create a Cloud SQL instance, you specify the private service connection, and the instance gets an internal IP from the allocated range.
Once set up, your VMs can connect to the service using the internal IP. The traffic flows through the peering connection, which is a direct, private link between the two VPCs. No internet egress is involved. The connection is highly available and low latency, as it uses Google's network.
Key points:
PSA is service-specific. You need to set it up for each service (e.g., one for Cloud SQL, another for Memorystore).
The IP range you allocate must be unique per service. You can reuse the same range for different services if they are in different regions, but best practice is to use distinct ranges.
PSA supports both manual and automatic peering. For Google-managed services, the peering is auto-accepted.
PSA is not free; you pay for the peering egress (though often lower than internet egress).
The service producer cannot initiate connections to your VPC; the peering is one-directional for connection initiation.
Configuration and Verification Commands
Enable Private Google Access on a subnet:
gcloud compute networks subnets update SUBNET_NAME --region=REGION --enable-private-ip-google-accessTo verify:
gcloud compute networks subnets describe SUBNET_NAME --region=REGION | grep privateIpGoogleAccessSet up Private Service Access for Cloud SQL: 1. Allocate an IP range:
gcloud compute addresses create ps-range --global --prefix-length=24 --network=default --purpose=VPC_PEERING --description="PSA range"Create a private connection:
gcloud services vpc-peerings connect --service=servicenetworking.googleapis.com --ranges=ps-range --network=defaultVerify peering:
gcloud compute networks peerings list --network=defaultCreate a Cloud SQL instance with private IP:
gcloud sql instances create my-instance --network=default --no-assign-ip --private-network=defaultHow PGA and PSA Interact with Related Technologies
Cloud NAT: If you need outbound internet access for VMs with internal IPs (e.g., for updates), you must use Cloud NAT. PGA does not provide internet access; it only provides access to Google APIs. Cloud NAT and PGA can coexist on the same subnet.
VPC Network Peering: PSA is built on VPC peering. Understanding peering limits (e.g., maximum number of peerings per VPC, subnets overlap restrictions) is important.
Firewall Rules: Both PGA and PSA traffic are subject to VPC firewall rules. You must allow egress traffic to the Google API IP ranges (for PGA) or to the service's IP range (for PSA). Ingress rules are not typically needed for PGA (since responses are stateful), but for PSA, you may need ingress rules if the service initiates connections (rare).
DNS: For PGA, DNS resolution of Google API hostnames must return the private IP ranges. Google Cloud DNS automatically handles this for standard domains like *.googleapis.com. For PSA, you may need to configure private DNS zones to resolve the service hostname to the internal IP.
Specific Numbers, Defaults, and Timers
PGA is enabled per subnet; there is no global toggle.
The Google API VIP ranges: 199.36.153.4/30 (restricted) and 199.36.153.8/30 (private). These are used for routing.
PSA IP range prefix length: typically /24 (256 addresses) but can be /16 to /28.
Default route (0.0.0.0/0) is used for PGA; no additional routes needed.
VPC peering limits: up to 25 peerings per VPC (can be increased by quota request).
PSA setup is instantaneous; no timers.
Cloud SQL private IP provisioning takes a few minutes.
Exam-Relevant Details
PGA is for accessing Google APIs and services only, not for accessing on-premises or other cloud services.
PSA is for accessing Google-managed services that are not in your VPC (like Cloud SQL, Memorystore, Filestore).
Both require that the VM has no external IP to be useful; but PGA works even if the VM has an external IP (it's just unnecessary).
PGA does not support IAP (Identity-Aware Proxy) TCP forwarding; PSA does not either directly, but you can use IAP for SSH.
For services that support both PGA and PSA (e.g., Cloud Storage API), PGA is simpler but PSA is not applicable because Cloud Storage is a global API, not a managed service in a tenant VPC.
Common Pitfalls
Confusing PGA with PSA: PGA is for APIs, PSA is for managed services.
Thinking PGA provides internet access: It does not; it only provides access to Google APIs.
Forgetting to enable PGA on the subnet: It is disabled by default.
Overlapping IP ranges when allocating PSA ranges: Must be unique per service and not conflict with existing subnets.
Not configuring DNS: For PSA, you must ensure DNS resolves the service hostname to the private IP. Use Cloud DNS private zones or the service's DNS name.
Identify the Access Requirement
Determine whether you need to access Google APIs (e.g., Cloud Storage, BigQuery) or a managed service (e.g., Cloud SQL, Memorystore). For APIs, use Private Google Access. For managed services, use Private Service Access. If both are needed, configure both independently. This decision is based on the type of resource: APIs are global and accessible via PGA; managed services are regional and require PSA.
Enable Private Google Access on the Subnet
For PGA, use the gcloud command `gcloud compute networks subnets update SUBNET_NAME --region=REGION --enable-private-ip-google-access`. This enables the feature for all VMs in that subnet. The VPC automatically adds a route for Google API VIP ranges (199.36.153.4/30 and 199.36.153.8/30) with a special next hop. Verify with `gcloud compute networks subnets describe`. No additional firewall rules are needed for the API traffic, but ensure egress traffic to those IPs is allowed (default allow all egress).
Allocate an IP Range for Private Service Access
For PSA, first reserve an IP range in your VPC using `gcloud compute addresses create`. Specify the prefix length (e.g., /24) and purpose as VPC_PEERING. The range must not overlap with any existing subnets or routes. For example: `gcloud compute addresses create my-range --global --prefix-length=24 --network=default --purpose=VPC_PEERING`. This range will be used by the managed service.
Create a Private Connection to the Service Producer
Use `gcloud services vpc-peerings connect --service=servicenetworking.googleapis.com --ranges=my-range --network=default`. This initiates VPC peering between your VPC and the service producer's VPC (servicenetworking.googleapis.com for many services). The peering is automatically accepted by Google. Verify the peering with `gcloud compute networks peerings list`.
Provision the Managed Service with Private IP
When creating the managed service (e.g., Cloud SQL instance), specify the private network and optionally the allocated IP range. For Cloud SQL: `gcloud sql instances create my-instance --network=default --no-assign-ip`. The instance gets an internal IP from the allocated range. For Memorystore, use `gcloud redis instances create` with `--network` and `--connect-mode=private-service-access`. The service is now accessible from VMs in the VPC using its internal IP.
Enterprise Scenario 1: Secure Data Analytics Pipeline
A financial services company needs to process sensitive transaction data using BigQuery and Cloud Storage. Their VMs (Compute Engine) run in a VPC with no external IPs to minimize attack surface. They enable Private Google Access on all subnets so that the VMs can write to Cloud Storage and query BigQuery without internet egress. This keeps data within Google's network, satisfying compliance requirements. They also use Cloud NAT for occasional software updates. The PGA configuration is trivial: one command per subnet. They monitor traffic using VPC Flow Logs to ensure no data leaks to the internet. A common mistake: forgetting to enable PGA on new subnets, causing API calls to fail silently. They automate PGA enablement via deployment manager.
Enterprise Scenario 2: Microservices with Managed Database
An e-commerce platform uses Cloud SQL for their transactional database and Memorystore for caching. Their application runs on GKE. They set up Private Service Access for both services. They allocate separate IP ranges for Cloud SQL (10.1.0.0/24) and Memorystore (10.1.1.0/24) to avoid overlap. They create private connections and configure Cloud SQL and Redis instances with private IPs. The GKE pods connect to the database using private IPs, reducing latency and improving security. They use Cloud DNS private zones to resolve the Cloud SQL instance name to its private IP. A challenge: when scaling, they need to ensure the allocated ranges have enough capacity. They initially used /28 for Cloud SQL, but ran out of IPs; they now use /24. They also set up VPC peering with a on-premises network via Cloud VPN, but must ensure no overlapping IP ranges.
Enterprise Scenario 3: Hybrid Cloud with Private Service Access
A media company uses Cloud Filestore for shared storage and Cloud Bigtable for time-series data. Their on-premises data center connects to GCP via Dedicated Interconnect. They need on-premises servers to access Cloud Filestore and Bigtable privately. They set up PSA for these services, allocating IP ranges from their VPC that are also routed on-premises via the interconnect. They configure the on-premises DNS to resolve the service hostnames to the private IPs. This allows seamless hybrid access without public internet. Performance is critical; they use the interconnect's high bandwidth. A pitfall: if the allocated IP range overlaps with on-premises IP addresses, routing issues occur. They carefully plan IP address management (IPAM) to avoid conflicts. They also enable Private Google Access for on-premises access to Google APIs, using the same VPC and interconnect.
What the ACE Exam Tests
The ACE exam objectives under "Planning Solutions" (Objective 2.1) include configuring network connectivity for Google Cloud services. Specifically, you need to know:
The difference between Private Google Access and Private Service Access.
When to use each (PGA for APIs, PSA for managed services).
How to enable PGA on a subnet.
How to set up PSA (allocate IP range, create private connection).
That PGA does not provide internet access; Cloud NAT is needed for internet.
That PSA uses VPC peering and is one-directional (consumer to producer).
Common Wrong Answers and Why
"Private Google Access provides internet access to VMs without external IPs." This is false. PGA only provides access to Google APIs and services. Internet access requires Cloud NAT.
"Private Service Access uses Cloud VPN to connect to managed services." No, it uses VPC Network Peering, not VPN. VPN is for hybrid connectivity.
"You need to enable PGA on the VPC network level." Wrong; it is enabled per subnet, not per network.
"PSA allows the managed service to initiate connections to your VMs." No, the peering is one-directional; only your VMs can initiate connections to the service.
Specific Numbers and Terms on the Exam
The Google API VIP ranges: 199.36.153.4/30 and 199.36.153.8/30. You may need to identify these.
The service producer for many services is servicenetworking.googleapis.com.
Default prefix length for PSA is often /24, but can be /16 to /28.
Maximum VPC peerings: 25 (default quota).
PGA is free; PSA has peering egress costs.
Edge Cases and Exceptions
PGA does not work for all Google services; only those that support the private VIP ranges. For example, Google Maps API may not work.
PSA requires that the allocated IP range does not overlap with any existing subnets or static routes. Overlap causes peering failure.
If you use PGA on a subnet that also has Cloud NAT, the traffic to Google APIs will use PGA, not NAT (PGA takes precedence for Google API IPs).
For PSA, you cannot use the same IP range for two different services in the same region; they must be unique.
How to Eliminate Wrong Answers
If the question involves accessing a Google API (e.g., Cloud Storage API), the answer likely involves PGA.
If the question involves accessing a managed service (e.g., Cloud SQL), the answer is PSA.
If the question mentions "internet access" or "external IPs", think Cloud NAT, not PGA.
If the question mentions "peering" or "private connection", it's PSA.
If the question mentions "subnet" configuration, it's PGA.
Always check if the VM has an external IP; if it does, PGA is not needed (but can be used). The exam often asks for the "most secure" or "cost-effective" solution.
Private Google Access enables VMs without external IPs to access Google APIs using internal IPs.
Private Service Access uses VPC peering to connect your VPC to managed services like Cloud SQL.
PGA is enabled per subnet; PSA requires IP range allocation and a private connection.
PGA does not provide internet access; use Cloud NAT for internet.
PSA is one-directional: only your VMs can initiate connections to the service.
Google API VIP ranges for PGA are 199.36.153.4/30 and 199.36.153.8/30.
PSA IP ranges must not overlap with existing subnets or routes.
Both PGA and PSA keep traffic within Google's network, improving security and performance.
These come up on the exam all the time. Here's how to tell them apart.
Private Google Access (PGA)
Used for accessing Google APIs and services (e.g., Cloud Storage, BigQuery).
Enabled per subnet using a single gcloud command.
Does not require IP range allocation.
Traffic routes through default internet gateway with special handling.
Free of charge; no additional cost.
Private Service Access (PSA)
Used for accessing managed services (e.g., Cloud SQL, Memorystore, Filestore).
Requires IP range allocation and VPC peering setup.
Requires reserving a contiguous IP range from your VPC.
Traffic flows through VPC Network Peering connection.
Incurs peering egress costs.
Mistake
Private Google Access allows VMs to access the internet.
Correct
PGA only provides access to Google APIs and services, not the general internet. For internet access, Cloud NAT is required.
Mistake
Private Service Access uses Cloud VPN to connect to managed services.
Correct
PSA uses VPC Network Peering, not VPN. VPN is used for hybrid connectivity between on-premises and GCP.
Mistake
You can enable Private Google Access on a VPC network level.
Correct
PGA is enabled per subnet, not per network. Each subnet must be individually configured.
Mistake
Private Service Access allows the managed service to initiate connections to your VMs.
Correct
PSA peering is one-directional; only your VMs can initiate connections to the service. The service cannot initiate connections to your VPC.
Mistake
Private Google Access works for all Google services.
Correct
PGA works only for services that support the private VIP ranges (199.36.153.4/30 and 199.36.153.8/30). Some services like Google Maps API may not be accessible.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Private Google Access (PGA) allows VMs with internal IPs to access Google APIs and services (e.g., Cloud Storage, BigQuery) without external IPs. It is enabled per subnet and routes traffic through the default gateway with special handling. Private Service Access (PSA) allows VMs to access Google-managed services (e.g., Cloud SQL, Memorystore) that run in separate VPCs. PSA uses VPC peering and requires allocating an IP range. PGA is for APIs; PSA is for managed services.
No, but you can. VMs with external IPs can already access Google APIs via the internet. PGA is only necessary for VMs without external IPs. However, enabling PGA can improve performance and security by keeping traffic within Google's network.
No, PSA is specifically for connecting to Google-managed services. For on-premises connectivity, use Cloud VPN or Dedicated Interconnect.
If the allocated IP range is too small, you may run out of IPs for new service instances. You can expand the range by creating a new allocation and updating the private connection, but this may cause downtime. Plan for future growth.
No, PGA only works with services that support the restricted or private VIP ranges. Most Google Cloud APIs (e.g., Cloud Storage, BigQuery) are supported, but some consumer services like Google Maps API may not be.
Use the command `gcloud compute networks subnets describe SUBNET_NAME --region=REGION` and look for the field `privateIpGoogleAccess: true`. You can also check via the Cloud Console under VPC network > subnets.
No, each PSA connection requires a unique IP range. However, you can reuse the same range for different services if they are in different regions and do not overlap.
You've just covered Private Google Access and Private Service Access — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?