Serverless Networking: Cloud Run, Functions & App Engine

Serverless computing promises that you never think about servers. You write code, deploy it, and it scales automatically. But the network does not disappear just because the compute is abstracted—it becomes harder to see and easier to misconfigure. How does a Cloud Run service connect to a Cloud SQL instance on a private IP? How does a Cloud Function reach an on-premises API through a VPN? How does App Engine handle ingress from specific IP ranges? These are the networking questions that serverless introduces, and the PCNE exam tests them directly.

The fundamental challenge of serverless networking is that your code runs in a Google-managed environment that is outside your VPC by default. Your Cloud Run container does not have an IP address in your subnet. It lives in Google’s infrastructure, isolated from your private network. Bridging that gap is the core problem.

Connecting Serverless to Your VPC
Serverless VPC Access Connector

The traditional approach. You deploy a small fleet of managed VMs (a “connector”) in a specific subnet. Your Cloud Run or Cloud Function routes internal traffic through these VMs into your VPC.

  1. Connector sizes: f1-microe2-microe2-standard-4 (affects throughput).
  2. You specify which traffic goes through the connector: “All traffic” or “Only private ranges.”
  3. Limitation: The connector VMs are a bottleneck at scale and consume IP addresses from your subnet.
Direct VPC Egress (Cloud Run Only)

The modern replacement. Cloud Run instances are placed directly in your VPC subnet with their own IP addresses. No connector VMs needed.

  1. The Cloud Run instance appears as a native VPC citizen.
  2. Existing firewall rules apply to it directly.
  3. If the exam presents a scenario where “the Serverless VPC Access Connector is a bottleneck,” the answer is Direct VPC Egress.
Ingress Controls
Cloud Run Ingress Settings
  1. All: Anyone on the internet can call the service.
  2. Internal: Only traffic from within the same VPC (or from a VPC-SC perimeter) can reach the service.
  3. Internal and Cloud Load Balancing: The service accepts traffic from your VPC and from a Google Cloud Load Balancer (which can be internet-facing).
App Engine Firewall

App Engine has its own firewall, separate from VPC firewalls. You can set rules like “Allow only IPs from 203.0.113.0/24” or “Deny all except internal load balancer.”

Egress Controls: What Can Serverless Access?

By default, a Cloud Function or Cloud Run service can reach the public internet freely. But if you need it to access private resources:

  1. Configure the VPC connector or Direct VPC Egress.
  2. Ensure the Cloud NAT gateway in the target region can handle the additional outbound connections.
  3. If accessing on-premises resources, the VPN or Interconnect must be in the same region as the connector or Direct VPC Egress subnet.
Putting it Together: A Pro-Engineer View

Imagine you are building a document processing pipeline. Users upload files to Cloud Storage, which triggers a Cloud Function. The function calls a private Cloud SQL instance for metadata lookup, then sends the document to a Cloud Run service for OCR processing. The Cloud Run service uses Direct VPC Egress to connect to the SQL instance—no connector bottleneck. Ingress is set to “Internal and Cloud Load Balancing” so the service is accessible from your global LB but not directly from the internet. Cloud NAT handles any outbound calls the Cloud Run service makes to third-party OCR APIs. The serverless compute scales to zero when idle. The network is always ready.