Choosing CPU Allocation Mode for Google Cloud Run: Always vs. Request‑Only

Why CPU Allocation Mode Matters

Google Cloud Run containers can run with either Always Allocated or Only During Request CPU modes. The choice directly affects billing (vCPU‑seconds) and request latency, especially for bursty or latency‑sensitive workloads. When planning a deployment, you must balance cost against performance.

Decision Context & Constraints

• Maximum request timeout: 60 minutes.
• Concurrency: up to 80 requests per instance.
• Billing: vCPU‑seconds are charged for the entire runtime of a container instance.
• Autoscaling: unaffected by CPU mode, but instance limits apply.

Mode Comparison

Mode	Billing	Cold Start Impact	Typical Use Case
Always Allocated	Pay for vCPU while the instance is running, regardless of traffic.	Lower latency; CPU is pre‑warmed.	CPU‑bound, latency‑critical services (e.g., real‑time analytics).
Only During Request	Pay only while the container processes requests.	Higher latency on the first request after a period of idleness.	I/O‑bound or sporadic traffic (e.g., background jobs, API gateways).

Trade‑Off Analysis

• Latency: Always Allocated guarantees immediate CPU availability, reducing tail latency by a few milliseconds. Only During Request may add 5–20 ms on the first request after idle time.
• Cost: With Always Allocated you pay for idle CPU, potentially doubling cost for low‑traffic services. Only During Request saves money during idle periods but may increase cost if traffic spikes frequently.
• Resource Utilization: Always Allocated can lead to higher CPU usage even when no requests are processed, which can affect autoscaling decisions.
• Cold Starts: The CPU warm‑up delay is typically <10 ms, negligible for most workloads but noticeable in high‑frequency microservices.

Implementation Steps

Using gcloud CLI

# Set mode to ALWAYS
gcloud run services update MY_SERVICE \
  --region us-central1 \
  --cpu-allocation=ALWAYS

# Set mode to ONLY_FOR_REQUEST
gcloud run services update MY_SERVICE \
  --region us-central1 \
  --cpu-allocation=ONLY_FOR_REQUEST

Replace MY_SERVICE and us-central1 with your service name and region. You need the run.services.update permission, typically granted to roles/run.admin.

Using YAML Definition

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    spec:
      containers:
      - image: gcr.io/my-project/my-image
        resources:
          limits:
            cpu: "1"
      cpuAllocation: ALWAYS   # or ONLY_FOR_REQUEST

Deploy with kubectl apply -f service.yaml or via Cloud Build. The cpuAllocation field is part of the Knative spec.

Verification

1. Check current mode:

   gcloud run services describe MY_SERVICE \
     --region us-central1 \
     --format='value(spec.template.spec.cpuAllocation)'
   

2. Deploy a lightweight test container that logs start time and CPU usage. Use a load generator (e.g., hey or wrk) to send concurrent requests and capture latency statistics.

   hey -n 1000 -c 80 http://MY_SERVICE_URL
   

3. Review Cloud Billing reports: navigate to Cloud Console → Billing → Reports → vCPU‑seconds for your project. Compare the cost before and after changing the CPU mode.

Practical Checklist Before Switching

• Confirm traffic pattern: steady vs. bursty.
• Estimate idle time: if >10 % of the day, consider Only During Request.
• Run a cost simulation using Cloud Console’s cost estimator.
• Set up alerts for unexpected spikes in vCPU‑seconds.
• Document the change in your deployment notes.

Limitations & Caveats

• Changing CPU allocation does not alter the maximum number of instances; autoscaling still depends on request concurrency.
• Always Allocated mode may trigger higher instance counts during traffic spikes, potentially increasing overall cost.
• Latency differences are workload‑specific; always test with real traffic patterns.
• Billing granularity is per second, so small latency improvements may not translate into noticeable cost savings.

Conclusion

For latency‑critical, CPU‑bound services, Always Allocated is the safer choice despite higher cost. For I/O‑bound or sporadic traffic, Only During Request saves money with a modest latency trade‑off. Use the provided commands to switch modes, verify with gcloud run services describe, and monitor both latency and billing to confirm the expected outcome.