Direct VPC egress vs Serverless VPC Access for Cloud Run: our default

Use Direct VPC egress for new Cloud Run services and jobs unless a documented limitation requires a Serverless VPC Access connector.

Google now recommends the direct path, and the operational reason is stronger than the product endorsement: the workload attaches to a network and subnet without another fleet-shaped resource to size, patch into diagrams, and pay for while idle.

The connector remains a compatibility option. It isn’t the neutral default anymore.

What Direct VPC egress removes

A Serverless VPC Access connector has its own subnet or address range, machine configuration, scaling behavior, throughput, IAM, monitoring, and cost. Those concerns may be manageable, but they exist beside the Cloud Run workload rather than as part of it.

Direct VPC egress follows the service or job lifecycle. Network cost can scale to zero with the workload. Revision- or execution-level network tags can identify egress traffic in firewall rules. The deployed resource names the VPC, subnet, and egress mode directly.

That gives an operator a shorter path from “this revision can’t reach Postgres” to the settings and firewall policy that own the traffic.

The subnet becomes runtime capacity

Direct VPC egress allocates addresses from the selected subnet. Address planning therefore affects whether new service instances, job tasks, or overlapping revisions can start.

Size for more than steady-state instances. Include deployment overlap, jobs sharing the subnet, delayed address release, and other Cloud Run resources using the range. Monitor free addresses and treat exhaustion as a scaling failure, not an obscure network event discovered during a rollout.

Use a dedicated subnet when it creates a useful ownership or firewall boundary. Don’t create one per service by reflex. Address fragmentation is still complexity.

Choose the egress mode explicitly

private-ranges-only sends private destinations through the VPC while public traffic uses Cloud Run’s normal path. all-traffic routes all outbound traffic through the VPC and makes NAT, firewall, inspection, and external reachability part of the service contract.

Use all-traffic only when policy or routing requires it. It expands the failure surface and can add Cloud NAT or other infrastructure that the simpler mode avoids.

Document which destinations depend on the VPC. Changing a service from private-only to all-traffic changes more than one deployment flag.

Design for the direct path’s limits

Direct VPC egress has per-instance throughput limits, quotas on configured instances, and possible connection resets during networking maintenance. Clients should reconnect with bounded backoff and database pools should validate stale connections.

Services and jobs use Direct VPC for egress, not direct ingress. Private callers still reach a Cloud Run service through Cloud Run’s ingress model, Private Google Access, Private Service Connect, or an internal Application Load Balancer. Worker pools have a different direct-ingress capability.

These distinctions belong in the design. “Attached to the VPC” doesn’t mean every packet enters and leaves through one symmetric interface.

When a connector still fits

Use Serverless VPC Access when Direct VPC egress is unavailable for the required product, region, organization constraint, or network shape, or when an existing connector provides a deliberate shared boundary that is expensive to migrate without operational benefit.

Compare actual limitations rather than inherited habit. A connector’s known throughput and address model may already fit an estate that operates it well. “This Terraform module already creates one” is merely archaeology.

When migrating, test startup, DNS, firewall policy, database reconnects, subnet capacity, and rollout overlap under production-like scale. Removing a connector simplifies the steady state, but the network path still deserves a controlled change.

Apply the default

Direct VPC egress keeps Cloud Run networking attached to the resource that creates the traffic. Use it by default, size the subnet as runtime capacity, and make the egress mode part of the service contract.

Break the default for a concrete limitation or a better-owned existing boundary. A connector should solve a problem that still exists, not survive because nobody reopened the decision.