Cloud Run to VPC Resources: Serverless VPC Access Connector versus Direct VPC Egress Interoperability

Designing outbound connectivity from a Cloud Run service to VPC-internal resources such as Cloud SQL or Memorystore requires choosing between two supported integration paths. The decision affects throughput, IP consumption, and egress cost, and is intended to be made before application-level optimization.

Serverless VPC Access uses a managed connector deployed in a /28 subnet. Throughput scales with the connector machine type and instance count, and the connector provides a fixed pool of IPs for traffic to private ranges. Direct VPC egress attaches the service to a VPC subnet without a connector, removing the connector hop and its bandwidth ceiling but consuming IPs from the chosen subnet and applying a different set of firewall and routing rules. Egress routing mode, private ranges only versus all traffic, changes whether public destinations go through Cloud NAT and how latency and NAT cost are incurred.

The interoperability boundary between Cloud Run and VPC is not settled by a single default. The unresolved design decision is which path governs bandwidth, cost, and IP exhaustion for a specific workload.

Which integration path is the governing constraint on throughput for a given Cloud Run service configuration? How do connector sizing and Direct VPC egress subnet IP consumption interact with Cloud NAT usage when egress is set to all traffic? Is the choice between connector-based access and Direct VPC egress deterministic per workload or region-dependent?