Autoscaling & concurrency

Exam guide§2.1

Cloud Run adds and removes container instances for you as load changes - all the way down to zero. Two settings shape that behaviour: concurrency (how many requests one instance handles at once) and the min / max instance bounds. This page is the single owner of both; the runtime states an instance passes through are on Container lifecycle.

How autoscaling works

Each revision receiving requests is autoscaled independently. Cloud Run watches two signals and starts or stops instances to keep up:

• Request volume - more incoming requests than the running instances can handle triggers a scale-out.
• Concurrency - how many requests each instance is allowed to serve at once (see below). Lower concurrency means each instance absorbs fewer requests, so Cloud Run needs more instances for the same traffic.

When traffic drops, instances go idle and are removed; with no traffic the revision scales to zero and you pay nothing for compute.

⚠GotchaScale to zero means cold starts

When a revision is at zero instances, the next request must wait for an instance to start (a cold start). If that latency matters, keep instances warm with --min-instances.

Concurrency

Concurrency is the maximum number of requests a single container instance serves simultaneously. A single instance can serve many requests at once, so Cloud Run does not need one instance per request.

• Default is 80 concurrent requests per instance.
• Set it to 1 for CPU-bound work, so each request gets a dedicated instance.
• Higher concurrency serves more traffic per instance (cheaper) but risks overloading the container; lower concurrency isolates requests but needs more instances.

⚠GotchaConcurrency is a revision setting

Concurrency is captured in the revision, so changing it deploys a new revision - see Revisions & traffic.

Minimum and maximum instances

The instance bounds cap the autoscaler on both ends:

• --min-instances - keep this many instances always warm and ready, eliminating cold starts. You pay for them even while idle.
• --max-instances - the ceiling on instances for the revision. Use it to cap cost and to protect downstream systems (databases, third-party APIs) from being overwhelmed by too many concurrent connections.

CommandsSet concurrency and instance bounds

gcloud run deploy my-service --image my-image \

--concurrency=80 --min-instances=1 --max-instances=100

Recap

#NumbersAutoscaling numbers to remember

• Scales to 0 by default (pay per request / CPU-time only while handling requests).
• Rapidly scales out to 1000 container instances per service; idle instances are removed when demand drops.
• Concurrency default 80 requests per instance; set to 1 for CPU-bound work.
• Set --min-instances=1+ to eliminate cold starts (you then pay for idle warm instances).
• Use --max-instances to cap cost and protect downstream systems.

?DECISIONHow do I tune scaling?

Cut cost when idle→Leave min-instances at 0 (scale to zero)

Eliminate cold-start latency→--min-instances=1+ (keeps warm instances)

CPU-bound work, one request per instance→--concurrency=1

Serve more traffic per instance→Raise --concurrency (watch for overload)

Cap cost / protect a database→--max-instances

Pick this when: match the goal to the setting