GCP Serverless Networking Masterclass

Cloud Run access, egress, tenant isolation, Cloud SQL private services, Private Google Access, and service-to-service patterns

Intent: Move from generic boxes to actual packet paths, IP ownership, subnet allocations, tenant boundaries, and enterprise control points.

Cloud Run services and jobs Shared VPC IPv4 examples

Scope and currency: Verified against Google Cloud documentation accessed 24 July 2026. Product behavior, quotas, and Preview features can change; confirm the linked documentation before production rollout. All IP addresses, domains, project names, and service names in the diagrams are illustrative.

1. Mental Model: How to Read Cloud Run Networking

Treat every architecture as a packet walk plus two independent decisions: who can enter, and where outbound packets go.

Caller: Internet user, partner, employee, service, on-premises client, or VPC workload.
Ingress path: default run.app URL, external Application Load Balancer, internal Application Load Balancer, Private Service Connect (PSC), or a supported service-mesh route.[3]
Runtime identity: A service account is the principal; roles/run.invoker is an authorization role; a Google-signed OIDC ID token is a credential; Identity-Aware Proxy (IAP) is an optional user-facing authentication layer in front of a load balancer.[5][4]
Egress path: default Cloud Run egress, Direct VPC egress, or a Serverless VPC Access connector.[2]
Destination controls: private services access (PSA), Private Google Access (PGA), PSC, Cloud NAT, explicit proxy or secure web gateway, DNS, routes, and firewall policy.

Operating principle: A Shared VPC does not make Direct VPC egress an inbound path. For Cloud Run services and jobs, Direct VPC egress is outbound only; private inbound access uses Cloud Run ingress settings together with an internal load balancer, PSC, or another supported ingress pattern. Cloud Run worker pools have a separate Direct VPC ingress capability and are outside this deck's primary scope.[1][3]

2. Core Concepts: Access Method Vocabulary

The terms sound similar, but each belongs to a different part of the packet path.

Ingress to Cloud Run	Egress from Cloud Run	Google Private Access	Enterprise Controls
`run.app` URL: The default service endpoint. Cloud Run ingress settings determine which network origins can reach it, while IAM can require an authenticated invoker.[3][5]	Direct VPC egress: Revision instances receive ephemeral addresses from a selected subnet; no connector fleet is in the data path.[1]	PSA: A private services access connection uses VPC Network Peering to a Google producer VPC; Cloud SQL private IP is a common example.[9]	Cloud Run IAM: Authorize callers with `roles/run.invoker` and a Google-signed ID token whose audience matches the receiving service URL or configured custom audience.[5]
External Application Load Balancer + serverless NEG: Public Layer 7 entry with custom domains, managed TLS, Cloud Armor, and optional Cloud CDN. Restrict Cloud Run ingress to prevent clients from bypassing the load balancer via the default URL.[4]	Serverless VPC Access connector: A managed connector fleet used when Direct VPC egress is unsuitable or a connector-specific behavior is required. Direct VPC egress is the recommended default for most new designs.[2]	PGA: A subnet setting, plus compatible DNS, routes, and firewall rules, that lets resources without external IP addresses reach supported Google APIs and services.[8]	IAP / Cloud Armor: IAP can authenticate users at the load-balancer edge; Cloud Armor supplies WAF and edge protection. IAP and Cloud CDN cannot be enabled on the same backend service.[4]
Internal Application Load Balancer + serverless NEG: Private Layer 7 entry for VPC and hybrid clients. Serverless NEG backends do not support load-balancer health checks; optional outlier detection is a different mechanism.[4]	Default egress: Internet-bound traffic that is not routed through a VPC uses Google-managed dynamic source addresses; those addresses are not intended for allowlisting.[7]	PSC: A consumer endpoint or published-service pattern for private access across projects, VPCs, organizations, or hybrid networks. Publishing Cloud Run through PSC normally places an internal Application Load Balancer in front of the serverless NEG.[3]	Cloud NAT / explicit proxy: Cloud NAT supplies source NAT and stable external addresses. A proxy, secure web gateway, or network virtual appliance is required when content inspection, DLP, URL policy, or application-aware filtering is needed.[7]

3. Direct VPC Egress and Subnet Capacity

With Direct VPC egress, Cloud Run allocates ephemeral IPv4 addresses from the selected VPC subnet. Capacity planning therefore affects scaling and deployment headroom.[1]

Subnet sizing facts for services:
1. Cloud Run reserves addresses in blocks of 16 (a /28) to accelerate scale-out.
2. The subnet's primary IPv4 range must be /26 or larger.
3. At steady state, plan for approximately 2× the maximum instance count in addresses.
4. A scaled-down revision can retain addresses for up to 20 minutes. During a deployment, old and new revisions can overlap, so add rollout and operational buffer.[1]

Do not build policy around a single instance IP. Addresses are ephemeral. Apply firewall policy to the delegated subnet range or supported network tags. Cloud Run jobs have different allocation behavior: one address per task plus retention after completion.[1][6]

+--------------------------------------------------------------+
| HOST PROJECT: TENANT A SUBNET 10.42.16.0/22                 |
|                                                              |
|  Old revision: addresses retained while instances drain      |
|  New revision: /28 address blocks acquired during scale-out  |
|                                                              |
|  Firewall policy targets subnet range / supported tags,      |
|  not a specific ephemeral Cloud Run instance address.        |
+--------------------------------------------------------------+

Operational caveats: Direct VPC egress has regional quotas and documented connection/startup limitations. VPC Flow Logs do not identify the Cloud Run revision by name, and Firewall Rules Logging and Packet Mirroring are not supported for this traffic. Cloud NAT with Direct VPC egress can also add cold-start connection delay, so load-test the exact design.[1]

4. Shared VPC Tenant Isolation and IAM Delegation

Service projects own Cloud Run resources; the host project owns the Shared VPC, subnets, routes, and firewall policy.[6]

Least-privilege delegation:
Grant the Cloud Run service agent from the service project
service-SERVICE_PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com
the ability to use only the tenant's dedicated subnet. Google documents a least-privilege pattern using roles/compute.networkViewer on the host project and roles/compute.networkUser on the selected subnet.[6]

IAM is not the data-plane isolation boundary. Subnet-scoped IAM controls who may attach a Cloud Run revision to the subnet. Firewall rules, hierarchical firewall policies, routes, DNS, and organization policy control which destinations the resulting packets may reach. The subnet must be in the same region as the Cloud Run resource.[6]

========================== SHARED VPC ==========================
|                                                               |
|  Tenant A subnet 10.42.16.0/22                                |
|      ^ subnet-scoped Network User                             |
|      | Cloud Run service agent for Tenant A service project   |
|                                                               |
|  -------- deny cross-tenant traffic by firewall policy -------|
|                                                               |
|  Tenant B subnet 10.42.20.0/22                                |
|      ^ subnet-scoped Network User                             |
|      | Cloud Run service agent for Tenant B service project   |
|                                                               |
=================================================================

5. Controlled Internet Egress, NAT, Proxies, and DLP

When a SaaS provider or security program needs a stable source address, route all Cloud Run egress through the VPC and configure Cloud NAT with a reserved external IP address.[7]

Critical egress setting: Configure Cloud Run egress as all-traffic. With private-ranges-only, public internet destinations do not traverse the VPC and therefore do not use its NAT or proxy path.[16][7]

+-------------------------+
| CLOUD RUN SERVICE       |
| Egress: all-traffic     |
+------------+------------+
             | ephemeral source from tenant subnet
             v
+-------------------------+
| VPC SUBNET / ROUTING    |
+------------+------------+
             |
       +-----+-----------------------------+
       |                                   |
       v                                   v
 Default internet route              Route / proxy policy
 + Cloud NAT SNAT                    to explicit proxy or SWG
       |                                   |
       v                                   v
 SaaS sees reserved                   DLP, URL filtering,
 NAT IP: 198.51.100.25                 TLS inspection if designed

Cloud NAT is not a packet-inspection appliance and is not a route next hop. Cloud Router and Cloud NAT provide control-plane configuration; traffic follows the VPC route and receives source NAT at the edge. Use an explicit proxy, secure web gateway, or network virtual appliance when inspection or content policy is required.[7]

6. PSA vs. PGA vs. PSC: Destination Plumbing

PSA, PGA, and PSC are not interchangeable. They solve different private-connectivity problems after Cloud Run has entered the VPC.

Private services access (PSA): A VPC Network Peering connection to a Google producer VPC. For Cloud SQL private IP, the instance receives an address from an allocated private services range and is reached over the peering connection.[9]
Private Google Access (PGA): A subnet setting used with DNS, routes, and firewall policy so workloads without external IP addresses can reach supported Google APIs through private.googleapis.com or restricted.googleapis.com VIPs.[8]
Private Service Connect (PSC): Consumer endpoints and service attachments that privately expose supported Google APIs or producer services. For a privately published Cloud Run application, an internal Application Load Balancer typically fronts the serverless NEG and is published through PSC.[3]

+-----------------------+
| CLOUD RUN SERVICE     |
+-----------+-----------+
            | Direct VPC egress into 10.42.16.0/22
            v
+-----------+-----------------------------------------------+
| SHARED VPC                                               |
|                                                           |
|  PSA peering ------------------> Cloud SQL 10.91.0.3:5432 |
|  PGA DNS/VIP ------------------> supported Google APIs     |
|  PSC endpoint/service path ----> privately exposed service|
+-----------------------------------------------------------+

Cloud SQL routing and authentication are separate. Cloud Run must have a network path to the VPC that contains the Cloud SQL private services connection. The application must also satisfy database authentication and, when using the Cloud SQL connector or Auth Proxy, grant the runtime service account the required Cloud SQL IAM role.[10]

7. VPC Service Controls Perimeter

VPC Service Controls adds a service perimeter around supported Google Cloud services to reduce data-exfiltration risk. For Cloud Run, both the default run.app URL and custom domains are subject to perimeter enforcement.[11]

Key configuration requirements and caveats:
- Put the relevant host and service projects inside the perimeter when using Shared VPC.
- Configure perimeter ingress policies or access levels for administrators and deployment workflows that originate outside the perimeter.
- Enable PGA on participating subnets and configure DNS for *.googleapis.com and *.run.app to use restricted.googleapis.com where required.
- Allow TCP 443 to 199.36.153.4/30 with a firewall rule that has higher precedence than the deny-all egress rule. In Google Cloud, a smaller numeric priority has higher precedence; the documented deny rule uses a priority numerically greater than 1000.
- Services intended to comply with the perimeter use internal ingress and send all egress through the VPC. Review existing services after perimeter changes because enforcement can differ until a resource is redeployed.[11]

Invocation-policy nuance: VPC Service Controls does not use the invoking client's Cloud Run IAM principal when evaluating perimeter ingress for Cloud Run invocation. Principal-specific ingress rules and access levels are therefore not supported for that invocation decision; follow the current Cloud Run VPC-SC documentation rather than assuming IAM identity is the perimeter signal.[11]

==================== VPC-SC SERVICE PERIMETER ====================
|                                                                  |
|  Admin / CI outside perimeter                                    |
|       | approved perimeter ingress policy                        |
|       v                                                          |
|  Cloud Run service: internal ingress                             |
|       | all egress through tenant subnet with PGA                |
|       +--> allow 199.36.153.4/30 tcp:443 (higher precedence)     |
|       +--> deny other egress (lower precedence)                  |
|                                                                  |
====================================================================

8. Internal Ingress: On-Premises to Cloud Run

Direct VPC egress does not create an inbound private IP for a Cloud Run service. On-premises clients need a supported private ingress path such as an internal Application Load Balancer, a PSC endpoint with private DNS, or a Cloud Run service published through PSC.[1][3]

+------------------------+       Cloud VPN / Interconnect       +----------------------------------+
| ON-PREMISES            |-------------------------------------->| GOOGLE CLOUD VPC                 |
| Client 172.20.14.12    |                                       |                                  |
| DNS: orders.int...     |                                       | Internal Application LB          |
+------------------------+                                       | VIP 10.42.8.20                   |
                                                                 |        |                         |
                                                                 |        v                         |
                                                                 | Serverless NEG                  |
                                                                 |        |                         |
                                                                 |        v                         |
                                                                 | Cloud Run orders-api            |
                                                                 | Ingress: internal + LB          |
                                                                 +----------------------------------+

Load-balancer behavior: Serverless NEG backends do not use standard health checks. Also, configure Cloud Run ingress so the default service URL cannot be used to bypass the intended load-balancer policy. For VPC-originated private requests, Cloud Run request logs may record a non-client value such as 0.0.0.0 for the remote IP; retain load-balancer and network logs when client attribution matters.[4][3]

9. Service-to-Service Patterns

Choose the simplest pattern that satisfies identity, naming, routing, observability, and policy requirements.

IAM/OIDC direct call: The calling service account receives roles/run.invoker on the target and sends a Google-signed ID token. The token audience is normally the receiving service's run.app URL or a configured custom audience. A custom domain is not automatically a valid audience.[5]
Internal Application Load Balancer + serverless NEG: The caller resolves private DNS to the internal VIP. This adds centralized Layer 7 routing and load-balancer policy, but it does not add backend health checks for serverless NEGs and it introduces per-service or shared-load-balancer management.[4]
Private Service Connect: Use an endpoint or published service when the consumer and producer need private connectivity across VPC, project, organization, or hybrid boundaries without broad network peering.[3]
Cloud Service Mesh: Use when advanced traffic management, global service routing, mesh observability, or centrally managed service policy justifies the added platform dependency. Cloud Run integration is currently Preview and has scenario-specific requirements.[12]

10. Cloud Service Mesh and Cloud Run

Status: Cloud Service Mesh integration for Cloud Run is a Pre-GA Preview feature as of the documentation reviewed for this deck. Treat support boundaries and architecture as subject to change.[12]

Documented Cloud Run capabilities:
- Cloud Run-to-Cloud Run traffic can use advanced traffic management, weighted routing, global load balancing, observability, and security policy through a fully managed data plane.[12]
- Cloud Run-to-GKE mesh routing is Preview, uses Istio APIs, and can inject a fully managed Envoy sidecar for the Cloud Run caller.[13]
- GKE mesh-to-Cloud Run routing is Preview; the Cloud Run target does not have to join the mesh, but the documented Preview requires it to be in the same project as the GKE mesh. Cloud Run IAM authorization still applies.[14]

+------------------------------------------------------------+
| CLOUD SERVICE MESH CONTROL PLANE                           |
| Routing policy | traffic splitting | telemetry | security  |
+-----------------------------+------------------------------+
                              | managed configuration
             +----------------+----------------+
             |                                 |
             v                                 v
+----------------------------+      +----------------------------+
| Cloud Run caller           |      | Cloud Run target           |
| managed data plane as      |----->| or supported GKE service   |
| documented for the pattern |      | IAM remains authoritative  |
+----------------------------+      +----------------------------+

Do not overgeneralize generic mesh claims. Cloud Service Mesh supports mTLS and other security capabilities in supported configurations, but the exact transport identity, encryption, proxy placement, and API model depend on the selected Cloud Run/GKE pattern. Do not draw two customer-managed Envoy sidecars or promise universal mTLS unless the implementation documentation explicitly supports that topology.[15][12]

11. Anti-Patterns and the Safer Design Move

Anti-Pattern	The Safer Design Move
Direct VPC diagram shows a connector in the data path	Show the selected subnet directly attached to the Cloud Run revision. Put connectors on a compatibility or alternatives slide.[1][2]
Internal ingress is drawn through the egress attachment	Use an internal Application Load Balancer, PSC endpoint, or published PSC service for private inbound access.[3]
Cloud NAT is drawn as a routed inspection appliance	Represent Cloud NAT as source NAT on the internet egress path. Add an explicit proxy, SWG, or NVA for inspection and DLP.[7]
Serverless NEG has a conventional health check	State that serverless NEG backends do not support health checks; use supported outlier detection only where appropriate.[4]
PSA is treated as authentication	Explain the producer VPC, allocated range, peering route, database port, Cloud SQL connector choice, IAM, and database authentication separately.[9][10]
Whole-VPC Network User grants for every tenant	Delegate the Cloud Run service agent to a dedicated subnet and enforce cross-tenant boundaries with firewall policy and routes.[6]
Cloud Service Mesh integration is presented as generally available and symmetric	Label it Preview and document the exact Cloud Run-to-Cloud Run, Cloud Run-to-GKE, or GKE-to-Cloud Run support conditions.[12][13][14]

12. Reference Packet Walks

Every flow has a caller, route, source identity, source IP at each hop, target, and control point. Proxies and NAT can change the address observed downstream.

Design-review questions:
1. What source IP is observed at each next hop, and where does it change?
2. Which IAM principal and credential authorize the application request?
3. Which logs prove the route, authorization decision, NAT/proxy action, and target response?
4. Can the intended control point be bypassed through another endpoint or route?

External API: 203.0.113.10 → edge/CDN → external Application Load Balancer → serverless NEG → Cloud Run. Validate forwarded-client headers only from trusted proxies, and restrict Cloud Run ingress to prevent direct endpoint bypass.[4]
On-premises internal ingress: 172.20.14.12 → Cloud VPN/Interconnect → internal Application Load Balancer 10.42.8.20 → serverless NEG → Cloud Run.[3]
Cloud Run to Cloud SQL: ephemeral address from 10.42.16.0/22 → Shared VPC → PSA peering → Cloud SQL private IP 10.91.0.3:5432. Network reachability does not replace Cloud SQL or database authentication.[9][10]
Stable internet egress: ephemeral address from 10.42.16.0/22 → VPC default internet route with Cloud NAT → SaaS sees reserved test address 198.51.100.25. Insert an explicit proxy or SWG before the internet when inspection is required.[7]

Evidence plan: Combine Cloud Run request/audit logs, load-balancer logs, VPC Flow Logs, Cloud NAT logs or proxy logs, Cloud SQL logs, and application correlation IDs. VPC Flow Logs alone do not identify the Cloud Run revision name for Direct VPC egress traffic.[1]

References

Official Google Cloud documentation, accessed 24 July 2026.

Direct VPC egress with Cloud Run. Address allocation, subnet sizing, ingress scope, quotas, and limitations.
https://docs.cloud.google.com/run/docs/configuring/vpc-direct-vpc ↩
Connect Cloud Run to a VPC network. Comparison of Direct VPC egress and Serverless VPC Access connectors.
https://docs.cloud.google.com/run/docs/configuring/connecting-vpc ↩
Private networking with Cloud Run. Internal load balancing, PSC, Shared VPC, on-premises access, and private ingress patterns.
https://docs.cloud.google.com/run/docs/securing/private-networking ↩
Serverless network endpoint groups overview. Load-balancer features, direct-URL bypass considerations, IAP, Cloud Armor, and absence of health checks.
https://docs.cloud.google.com/load-balancing/docs/negs/serverless-neg-concepts ↩
Authenticate service-to-service requests in Cloud Run. Invoker role, ID tokens, audiences, and custom-audience behavior.
https://docs.cloud.google.com/run/docs/authenticating/service-to-service ↩
Connect Cloud Run to a Shared VPC network with Direct VPC egress. Cloud Run service-agent IAM and subnet-scoped delegation.
https://docs.cloud.google.com/run/docs/configuring/shared-vpc-direct-vpc ↩
Static outbound IP address for Cloud Run. All-traffic VPC routing, reserved addresses, and Cloud NAT behavior.
https://docs.cloud.google.com/run/docs/configuring/static-outbound-ip ↩
Private Google Access. Subnet setting, supported Google APIs, VIPs, DNS, routes, and firewall requirements.
https://docs.cloud.google.com/vpc/docs/private-google-access ↩
Configure private services access for Cloud SQL for PostgreSQL. Producer VPC peering, allocated ranges, and private IP connectivity.
https://docs.cloud.google.com/sql/docs/postgres/configure-private-services-access ↩
Connect from Cloud Run to Cloud SQL for PostgreSQL. Private-IP routing, connector choices, service account permissions, and port usage.
https://docs.cloud.google.com/sql/docs/postgres/connect-run ↩
Use VPC Service Controls with Cloud Run. Perimeter behavior, ingress policies, PGA, restricted VIP, DNS, firewall priorities, and invocation limitations.
https://docs.cloud.google.com/run/docs/securing/using-vpc-service-controls ↩
Configure Cloud Service Mesh for Cloud Run. Preview status and Cloud Run-to-Cloud Run mesh capabilities.
https://docs.cloud.google.com/run/docs/configuring/cloud-service-mesh ↩
Route traffic from Cloud Run to a GKE Cloud Service Mesh. Preview, Istio APIs, managed Envoy, and configuration model.
https://docs.cloud.google.com/service-mesh/docs/route-from-cloud-run ↩
Route traffic from a GKE Cloud Service Mesh to Cloud Run. Preview requirements, project scope, and Cloud Run IAM authorization.
https://docs.cloud.google.com/service-mesh/docs/route-to-cloud-run ↩
Cloud Service Mesh overview. General service-mesh security, traffic-management, and supported-platform concepts.
https://docs.cloud.google.com/service-mesh/docs/overview ↩
Configure Serverless VPC Access connectors. all-traffic versus private-ranges-only egress behavior.
https://docs.cloud.google.com/run/docs/configuring/vpc-connectors ↩