Topic 3 of 10
Revisions, traffic, and scaling in Cloud Run
Three items in the exam guide: deploying new versions of a Cloud Run application, adjusting traffic splitting (on Cloud Run, Cloud Run functions, and GKE), and configuring autoscaling for a Cloud Run application. Traffic splitting on GKE with Gateway API is in the GKE operations article.
Contents
Revisions
Every deployment or configuration change to a service creates an immutable revision. The service decides which revisions receive traffic and in what percentage, which lets you roll back, roll out gradually, and split traffic among several.
- Traffic changes aren't instantaneous: in-flight requests complete and aren't dropped.
- If you split traffic or assign it to an older revision, that pattern persists in later deployments. To go back to using only the latest revision, send all traffic to it.
- The service's Revision history tab lists revisions and lets you manage traffic.
Deploying a new version
gcloud run deploy myservice --image us-docker.pkg.dev/PROJECT/repo/app:2.0 --region us-central1
By default, the new revision gets 100% of traffic once it is ready. Roles to manage services deployed from an image:
- Cloud Run Developer (
roles/run.developer) on the service. - Service Account User on the service identity.
- Artifact Registry Reader on the image repository, if applicable.
- From source: Cloud Run Source Developer and Service Usage Consumer on the project, plus the Cloud Run Builder role for the Cloud Build service account.
Rolling back to a previous revision
gcloud run services update-traffic myservice --to-revisions myservice-00004-abc=100
In the console: Revision history → revision menu → Manage traffic → Send all traffic to one revision. You can also edit the traffic block of the service YAML and apply it with gcloud run services replace.
Watch out
When you roll traffic back to a revision, Cloud Run updates routing immediately without re-running deployment health checks or verifying external dependencies.
Gradual rollouts and traffic splitting
Deploy without traffic: gcloud run deploy myservice --image IMAGE --no-traffic
Send a small percentage: gcloud run services update-traffic myservice --to-revisions NEW=10,OLD=90
Raise it while watching metrics: NEW=50, then NEW=100
Go back to "always the latest": gcloud run services update-traffic myservice --to-latest
For the latest revision you can use the LATEST alias, for example LATEST=5. With session affinity enabled, splitting behaves differently; the docs cover it separately.
Cloud Run functions
Functions are deployed as Cloud Run services, so they share the same revisions, traffic splitting, and autoscaling. You manage them with the same gcloud run commands.
How Cloud Run autoscales
Each revision scales automatically to the number of instances needed for requests, events, or CPU usage. With no traffic, it scales to zero.
CPU utilization
Average CPU usage over the last minute, divided by CPUs per instance and by the target.
Request concurrency
Average concurrent requests (1 and 10 minutes), divided by maximum concurrency and by the target.
- It takes the larger instance count requested by either driver.
- Default target: 60% CPU and concurrency. It keeps the count while usage stays within ±10% of the target (54% to 66%) and rounds up.
- It doesn't scale on memory.
- Instances can stay idle for a while after handling requests (up to 15 minutes, 10 with GPUs).
- Alternative: manual scaling with a fixed instance count.
Concurrency
Maximum concurrency is how many simultaneous requests an instance handles. With gcloud or Terraform, the default is 80 per vCPU. It strongly affects how the service scales: if your app can't handle several requests at once, lower it.
gcloud run services update myservice --concurrency=1
Minimum and maximum instances
Minimum
- 0 by default. Keeps instances warm to avoid cold starts.
- A best-effort target, not a guarantee.
- They cost money: with request-based billing, idle instances are charged at a lower rate; with instance-based billing, at the default rate. Google suggests CUDs because the cost is predictable.
- If the service uses CPU even without requests, Google recommends at least 1.
Maximum
- 100 instances per revision by default; it can be raised.
- Useful to control costs or avoid overloading downstream systems, such as a database.
# Service level (recommended): no new revision needed gcloud run services update myservice --min 2 --max 50 # Revision level: takes effect on deployment gcloud run services update myservice --min-instances 2 --max-instances 50
Google recommends setting them at the service level and not combining service-level and revision-level settings.
Exam scenarios
| Situation | Answer | Why |
|---|---|---|
| The newly deployed version throws errors | gcloud run services update-traffic SERVICE --to-revisions PREVIOUS_REV=100 | Changes routing immediately. |
| Deploy a version without sending it traffic yet | gcloud run deploy --no-traffic --tag green | The revision is reachable only by its tag URL. |
| Send 10% of traffic to the new version | update-traffic --to-revisions NEW=10,OLD=90 | Percentage split across revisions. |
| Send everything back to the latest revision after a split | update-traffic --to-latest | Splits persist across later deployments. |
| Avoid cold starts on a low-latency API | Service-level minimum instances | Keeps instances warm, at a cost. |
| Protect a database from too many connections | Limit maximum instances | Caps how many instances can be created. |
| A single-threaded service struggles with several requests at once | Lower maximum concurrency | Fewer simultaneous requests per instance. |
Common exam traps
❓ Does Cloud Run scale on memory?
No. It scales on CPU utilization and request concurrency.
❓ What is a revision's default maximum instance count?
100. It can be raised.
❓ Are minimum instances free?
No. Kept instances are billed, though with request-based billing idle time is charged at a lower rate.
❓ After a 90/10 split, does the next deployment get 100%?
No. The split pattern persists; use --to-latest to send everything to the latest again.
❓ What does --no-traffic do?
Deploys the revision without sending it traffic. With --tag it is reachable at its tag URL.
❓ What is the default maximum concurrency with gcloud?
80 per vCPU of the instance.
Did you get this topic?
Test what you just learned
A team wants to test version 2 of its Cloud Run service with internal users before giving it real traffic, and then move 20% of traffic to it. What should it do?
Ready to test "Revisions, traffic, and scaling in Cloud Run"?
Original questions, each with a full explanation.
Start a mock exam