Cloud Run and Cloud SQL Auth Proxy: Cost Implications of CPU Always Allocated for Low‑Traffic Workloads

Short answer

For a service receiving less than one request per minute, CPU allocated only during request processing is almost certainly cheaper than CPU always allocated — the latency benefit of an always-warm instance does not offset continuous vCPU billing at that traffic level. The real question is not cost but reliability: the Cloud SQL Auth Proxy performs background work between requests, and CPU throttling in request-only mode can interfere with it. Pricing and throttling behavior change over time, so verify against the current Cloud Run documentation and pricing calculator before committing.

What is confirmed vs. likely

Confirmed behavior (well-established):

• With CPU always allocated, you are billed for vCPU and memory for the entire lifetime of every running instance, including idle time. With request-only allocation, billing accrues only while the instance handles requests (plus a small startup/shutdown window).
• With request-only allocation, CPU is throttled to near zero between requests. Any background thread — including the proxy's connection maintenance — effectively pauses.
• Cloud Run's free tier is measured in vCPU-seconds, GB-seconds, and requests. Continuous allocation consumes vCPU-seconds around the clock, which exhausts free-tier allowances far faster than bursty request-only usage.

Likely, but verify for your setup:

• The proxy's secure tunnel may be dropped or become stale during throttled idle periods, surfacing as connection errors on the first request after idle. Some deployments run fine because the proxy reconnects on demand; others see intermittent failures. This is version- and configuration-dependent.
• Cold-start latency is cumulative: container start + application init + proxy tunnel establishment. Expect the proxy to add a noticeable but usually sub-second-to-few-seconds increment, depending on region and database distance.

Answering your three questions

1. Does always-allocated CPU negate the latency benefit at sub-minute traffic?

Yes, in cost terms. At under one request per minute, instances sit idle the overwhelming majority of the time. Always-allocated billing charges you for that idle time continuously, and one warm instance is not even a guarantee — Cloud Run may still scale to zero or start new instances under revision rollouts, so you pay the premium without fully eliminating cold starts. For occasional users, a few extra seconds of cold start a handful of times per day is usually acceptable.

2. Can the proxy run reliably on the smallest instance without always-allocated CPU?

Note that Cloud Run instance sizes are its own CPU/memory tiers — f1-micro is a Compute Engine class and does not apply here. The proxy itself is lightweight and fits comfortably in the smallest Cloud Run memory tier alongside a modest application. The reliability risk is not memory; it is CPU throttling pausing the proxy between requests. Mitigations:

• Run the proxy as a sidecar container (supported natively by Cloud Run) rather than an in-process wrapper, so its lifecycle is managed independently.
• Have the application retry the initial database connection on cold start rather than failing the request.
• Consider the Cloud Run built-in Cloud SQL connection (via the --add-cloudsql-instances flag / Unix socket), which uses the same proxy machinery but is managed by the platform and is the better-tested path for request-only services.

3. Expected cold-start impact with CPU allocation off

There is no universal number — it depends on your container image size, application init time, and region. Measure it rather than estimate it:

# After 15+ minutes idle, time a cold request
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://YOUR_SERVICE_URL

Compare against a warm request immediately after. The delta is your true cold-start penalty, including proxy tunnel setup.

Recommendation

1. Keep request-only CPU allocation for this traffic level.
2. Prefer the platform-managed Cloud SQL connection over a hand-run proxy sidecar.
3. Watch Cloud Run logs for connection-reset or timeout errors after idle periods; if they appear, that is the point where always-allocated CPU (or a scheduled keep-alive request) becomes worth the cost.

One diagnostic detail that would change this recommendation: whether your users are interactive (cold starts directly felt) or asynchronous (retries hide them). If interactive and latency-sensitive, a scheduled warm-up request every few minutes is a cheaper middle ground than always-allocated CPU.