Choosing the Right CPU Allocation for Cloud Run: A Decision Guide

Problem Statement

When deploying a stateless HTTP service on Cloud Run you must decide how much CPU to expose to each request. The cpu field accepts three values: none, 1 and 2. Picking the wrong value can lead to either wasted spend or throttled performance.

Decision Criteria

• Workload Pattern – bursty, low‑latency or CPU‑heavy?
• Cost Sensitivity – per‑second billing increases linearly with CPU.
• Concurrency Limits – default 80 requests; higher concurrency may require more CPU.
• Cold Start Latency – none can delay the first request after idling.
• Operational Visibility – metrics available to confirm the chosen setting works.

Supported CPU Options (Compact Table)

CPU Setting	Typical Use‑Case	Cost Impact	Cold‑Start Behavior
none	Event‑driven, infrequent requests that can tolerate a short startup delay.	Lowest – billed only while a request is actively handled.	Potentially higher latency for the first request after idle.
1	Moderate throughput, balanced CPU/latency for most web services.	Moderate – one CPU per container instance billed per second.	Consistent with minimal cold‑start penalty.
2	CPU‑intensive workloads or high concurrency that benefit from parallelism.	Higher – double the per‑second rate of 1.	Cold‑start latency similar to 1, but overall throughput increases.

Trade‑offs

• Cost vs. Performance – none saves money but can hit latency thresholds for latency‑sensitive APIs.
• Throughput vs. Concurrency – 2 allows more simultaneous requests before hitting the 80‑request limit.
• Cold‑Start vs. Predictability – none introduces variability; 1 or 2 provide more stable response times.

Implementation Guide

1. Inspect Current Configuration

gcloud run services describe SERVICE_NAME \
  --region=REGION \
  --format='value(spec.template.spec.containers[0].resources.limits.cpu)'

Replace SERVICE_NAME and REGION with your service’s name and region. The command returns none, 1 or 2.

2. Update CPU Allocation

# Example: set CPU to 1
# Requires: Cloud Run Admin role and billing enabled

gcloud run services update SERVICE_NAME \
  --region=REGION \
  --cpu=1

Use --cpu=none or --cpu=2 as needed. The update triggers a new revision; the old revision remains available until traffic is shifted.

3. Verify Revision Deployment

gcloud run services describe SERVICE_NAME \
  --region=REGION \
  --format='value(status.latestReadyRevisionName)'

Confirm the new revision name matches the one you expect. Then shift traffic if you want the new revision to receive all requests.

4. Monitor CPU Utilization and Cold Starts

Cloud Monitoring automatically exposes metrics. Use the following metric selectors:

• CPU Utilization: run.googleapis.com/instance/cpu/utilization
• CPU Usage Time: run.googleapis.com/instance/cpu/usage_time
• Cold Start Latency: run.googleapis.com/instance/cold_start_latency

Example query in Cloud Monitoring:

run.googleapis.com/instance/cpu/utilization{service_name="SERVICE_NAME"}

5. Validate Cost Impact

In the Cloud Billing console, filter by the Cloud Run service and review the CPU cost line. Compare the cost before and after the change to confirm the expected savings or increase.

Practical Validation Example

Assume a lightweight API that receives GET /status requests every 30 seconds. The service currently uses cpu=none. You notice occasional 200‑ms latency spikes during the first request after a 5‑minute idle period.

1. Update to cpu=1 using the command above.
2. Send a burst of 20 concurrent requests with wrk or ab to simulate load.
3. Check run.googleapis.com/instance/cpu/utilization – expect a steady ~0.2 utilization.
4. Verify cold_start_latency drops to ~20ms for the first request.
5. Review billing – the per‑second cost should increase by roughly 0.5× the none rate.

Limitations and Caveats

• Cold‑Start Variability – Even with 1 CPU, the first request after idle can still be slower than subsequent ones.
• Memory‑CPU Coupling – Higher CPU may require proportionally more memory; monitor run.googleapis.com/instance/memory/utilization to avoid OOM.
• Concurrency Limits – If you need >80 concurrent requests, consider --concurrency adjustment or multiple revisions.
• Billing Granularity – Cloud Run bills per second; short bursts may not show significant cost differences.

Summary

Choosing none, 1 or 2 CPUs for Cloud Run is a clear cost‑performance trade‑off. Use the decision table to map your workload profile to a setting, update via gcloud run services update, and validate with Cloud Monitoring and billing dashboards. Balancing CPU allocation with concurrency and memory ensures you pay only for the compute you truly need while keeping latency within acceptable bounds.