Cloud Run max concurrency configuration for outbound connection pool safety

The goal is to configure a Cloud Run service so that its outbound connection pool never exceeds the per‑instance socket limit (approximately 1000 sockets) while still allowing the requested level of concurrency. Cloud Run’s max concurrency setting controls how many request instances can run simultaneously inside a container, but it does not constrain how many outbound sockets each instance may open. When a connection pool library is sized for a dedicated VM, the product of max concurrency and pool size can approach or exceed the hidden socket limit, causing intermittent 502 errors or latency spikes that are hard to attribute directly to socket exhaustion.

What is the recommended method to size the connection pool relative to the max concurrency setting to stay safely below the socket limit? Should operators rely on application‑level metrics or external observability tools to detect approaching socket exhaustion? Is there a way to enforce a per‑instance socket ceiling via container resource limits or Cloud Run configuration?