Direct VPC egress vs. Serverless VPC Access for Cloud Run

A Cloud Run service that only calls public APIs may not need VPC connectivity at all. A service that connects to a private database does. A service whose supplier requires a fixed public source IP needs a different setup again: VPC routing plus an outbound address provided through Cloud NAT. Establish which requirement you have before choosing a connection method.

For new Cloud Run services and jobs that need a VPC, we’d start with Direct VPC egress. It avoids maintaining a connector fleet between the application and the network. Google also recommends it over connectors where it meets the workload’s requirements in its Serverless VPC Access overview. A working connector isn’t an urgent migration, especially when outbound startup latency matters.

What disappears when you remove the connector

A Serverless VPC Access connector has its own instances, capacity settings, subnet range, and charges. It has a minimum of two instances and scales out under load, but it doesn’t automatically scale back in. Those properties can leave a small or intermittent application paying for network capacity even when its Cloud Run instances have stopped. Google’s connector configuration guide covers those settings and limits.

Direct VPC egress removes that fleet. The Cloud Run instances use addresses from your selected subnet, and you can apply network tags to the revision. You still own subnet capacity, routes, firewall policy, and any NAT configuration.

That usually makes Direct VPC egress easier to justify for a new private-database connection. For an existing connector, compare the avoidable cost and maintenance with the testing and rollout needed to replace it. Several quiet services sharing a connector may already be a reasonable arrangement.

Budget addresses for deployments, not just normal traffic

Direct VPC egress makes subnet capacity part of the application’s scaling limit. Google’s address allocation guidance describes allocation in blocks, a minimum /26 subnet, and service address consumption of roughly twice the instance count at steady state. Addresses can remain allocated for up to 20 minutes after instances scale down.

A deployment therefore needs room for more than the new revision’s intended steady state. As a planning example, 40 instances on the old revision and 40 on the new one represent about 160 addresses before accounting for allocation blocks, reserved addresses, other services, and additional headroom. Check the documented allocation rules against the rollout you actually permit.

Size the range using the services and revisions that can coexist, including rollback and burst scenarios. Several applications sharing a subnet can reach their peaks together. Cloud Run jobs also have their own address allocation and retention behavior; don’t apply the service multiplier to job executions without checking it.

Use subnet ranges or the supported network policy mechanisms for firewall rules, not individual instance IP addresses. Those addresses are ephemeral. A database allowlist copied from one successful test instance won’t survive routine scaling.

Choose which outbound traffic enters the VPC

Private database access and fixed public egress aren’t the same requirement. With private-ranges-only, qualifying private destinations use the VPC while other outbound traffic can use Cloud Run’s normal internet path. With all-traffic, outbound traffic is routed through the VPC and needs the corresponding routes and internet access configuration.

For a supplier that allowlists a public source IP, follow Google’s static outbound IP setup: route the relevant Cloud Run traffic through the VPC and Cloud NAT with a reserved address. Attaching a subnet alone doesn’t give the application a stable public IP. Test the address the supplier sees, rather than infer it from the deployment settings.

Direct VPC egress also doesn’t make the service’s inbound URL private. Ingress restrictions and caller authorization are separate settings, covered in internal-only Cloud Run.

Test the first connection after an idle period

Direct VPC egress has a startup caveat worth testing before migration. Google documents initial VPC connection delays and additional Cloud NAT allocation delays. Its current guidance recommends considering Serverless VPC Access for more predictable startup when the workload needs Cloud NAT. Those limitations are listed in the Direct VPC egress documentation from Google.

Measure a fresh instance making the real outbound call. A warm health check that never touches the database or supplier API tells you little about that path. Exercise scale from zero, a new revision, and a burst that starts additional instances. Check connection timeouts and retries, including whether the caller’s deadline expires before the first attempt can succeed.

A startup probe that checks a required dependency can keep an unready instance out of service, but it doesn’t remove the waiting time or create downstream capacity. Keep the check bounded and lightweight. Minimum instances can reduce how often users encounter startup, but new instances still appear during replacement and scale-out.

Migrate one service before moving the fleet

Create a revision using Direct VPC egress without immediately removing the old connector. Verify private DNS, database access, public egress, and every firewall rule that previously matched the connector’s source range. Then compare latency and failures under representative traffic.

Keep rollback available until the new path has survived a deployment and a realistic scaling event. Retire the connector only after no remaining revision or other workload needs it. Include address-release delays in any subnet cleanup.