Home › Associate Cloud Engineer › Section 3: Deploying and Implementing a Cloud Solution › Serverless VPC Access and Private Google Access

Serverless VPC Access and Private Google Access Study Notes

By the Cloud Cert Notes Editorial Team
Last updated: November 2026

Serverless services and private VMs both start life outside or isolated from your VPC, and two different features bridge the gaps. Serverless VPC Access lets Cloud Run, Cloud Functions, and App Engine reach VPC resources, while Private Google Access lets private subnet resources reach Google APIs without public addresses.

Exam tip: Memorise the direction of each bridge: connector brings serverless into the VPC, Private Google Access brings Google APIs to private subnets — direction decides the answer.

Key facts

Serverless VPC Access uses a connector, a regional resource placed in a subnet or dedicated /28 range, through which serverless environments send traffic into your VPC network.
With a connector configured, Cloud Run services and Cloud Functions can reach Compute Engine VMs, Memorystore instances, and on-premises addresses reachable from the VPC by private IP.
Egress settings on a serverless service choose whether only private destinations use the connector or all outbound traffic is routed through the VPC for inspection and NAT.
Private Google Access is a per-subnet boolean setting that lets VMs and serverless workloads using that subnet call Google APIs using internal addresses without any external IP.
Private Google Access requires compatible DNS and routes; by default the default route and Google API DNS names work, while restricted API access uses the restricted VIP range.
Private Google Access does not give access to the general internet; a private VM still needs Cloud NAT for non-Google destinations such as third-party APIs or OS repositories.
Serverless VPC Access connectors have throughput settings that scale within configured instance limits, and an undersized connector can throttle high-traffic Cloud Run services.
Direct VPC egress for Cloud Run, available alongside connectors, lets services attach directly to a subnet, but the ACE exam traditionally tests the connector model and its subnet requirements.
Neither feature gives inbound access from the VPC to a serverless service's internal address by itself; internal ingress for Cloud Run is controlled by its own ingress settings.

What the exam expects you to know

Choose Serverless VPC Access when Cloud Run, Cloud Functions, or App Engine must reach a private resource such as a Cloud SQL private IP instance or Memorystore.
Choose Private Google Access when VMs without external IPs on a subnet cannot reach Cloud Storage, BigQuery, or other Google APIs and no internet access is required.
Know the connector needs its own IP range or subnet and lives in one region, which must match the region planning of the serverless service using it.
Identify all-traffic egress routing through the connector as the design when serverless outbound internet traffic must exit via Cloud NAT or a firewall appliance.
Distinguish these features from each other under time pressure: serverless-to-VPC is the connector; VM-subnet-to-Google-APIs is Private Google Access.
Recognise connector throughput and scaling limits as the culprit when a heavily loaded serverless service shows throttling to VPC destinations.

Serverless VPC Access and Private Google Access vs Cloud NAT: when to use which

Use Private Google Access when private resources need only Google APIs, because it is a simple subnet setting with no NAT addresses, ports, or internet exposure involved. Use Cloud NAT when those same resources also need arbitrary internet endpoints such as vendor APIs, external package repositories, or webhook callbacks. Many architectures enable both together. The exam tests the boundary precisely: Google APIs in the requirement means Private Google Access suffices, while any non-Google internet destination in the same scenario forces you to add Cloud NAT as well. See also the Cloud NAT notes.

Useful gcloud commands

gcloud compute networks vpc-access connectors create my-connector --region=us-central1 --network=my-vpc --range=10.8.0.0/28
gcloud compute networks vpc-access connectors describe my-connector --region=us-central1
gcloud compute networks subnets update my-subnet --region=us-central1 --enable-private-ip-google-access
gcloud run deploy my-service --vpc-connector=my-connector --vpc-egress=private-ranges-only

Common exam traps

Trap: Enabling Private Google Access and expecting general internet access. It reaches Google APIs only; third-party endpoints remain unreachable without Cloud NAT or external IPs.
Trap: Assuming serverless services are in your VPC by default. Without a Serverless VPC Access connector or direct egress, they cannot reach private VPC addresses at all.
Trap: Placing the connector in a different region from the workload design and expecting optimal behaviour; connectors are regional and placement affects latency and availability.
Trap: Forgetting Cloud SQL private IP still needs authorised network configuration alongside the connector; the connector alone does not authorise the database connection.

Frequently asked questions

Why can my Cloud Run service not reach a VM's private IP address?

By default a Cloud Run service is not attached to your VPC, so it has no route to private addresses. You must configure Serverless VPC Access with a connector in the correct region, or use direct VPC egress, and set the service's egress to route private ranges through it. Firewall rules in the VPC must also allow the traffic.

What does Private Google Access actually enable?

Private Google Access lets resources with only private IP addresses on an enabled subnet reach Google APIs and services, such as Cloud Storage and BigQuery, without traversing the public internet or holding external addresses. It is enabled per subnet. It does not provide general internet access, so workloads needing third-party endpoints still require Cloud NAT in addition.

Does Serverless VPC Access route all traffic through the VPC?

Only if you configure it that way. The default private-ranges-only setting sends traffic destined for private IP ranges through the connector while internet traffic leaves the serverless environment directly. The all-traffic setting routes everything through the VPC, which organisations use to enforce Cloud NAT addressing, firewall inspection, or fixed egress IPs for serverless workloads.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.