Managing Cloud Run resources

Study guide for Associate Cloud Engineer, Unit 4 · Topic 3. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Managing Cloud Run resources. Considerations include:

1. Deploying new versions of an application
2. Adjusting application traffic splitting parameters
3. Setting scaling parameters for autoscaling instances

Managing Cloud Run resources

Day two: new versions, traffic, and how far it scales

New versions — what a deploy pins, how to check a change first, and the revisions left behind. Traffic — splits across several revisions, tags with their own address, and the split that outlives your next deploy. Scaling — minimum and maximum instances, concurrency, and when an instance gets its processor.

Unit 3 put a service on Cloud Run. This topic is what you do to it afterwards, and the guide lists three considerations: deploying new versions of an application, adjusting application traffic splitting parameters, and setting scaling parameters for autoscaling instances. The first deploy and the basic gradual rollout were taught in Unit 3, so this deck does not repeat them. It goes one level deeper on each: what exactly a new version pins, how traffic behaves across more than two revisions and across later deployments, and the four settings that decide how many instances you get and when they run. Each one ends in a command you would actually type, quoted from Google's page for it.

Deploying new versions of an application

A new version is a new revision, pinned to one image digest

• Same command as the first deploy: gcloud run deploy SERVICE --image IMAGE_URL
• An image tag is resolved to a digest; the revision always serves that digest
• Name the revision yourself with --revision-suffix
• Check a change first with the --dry-run flag, which creates nothing

Worked example (synthetic). A team pushes a fixed image under the same :latest tag and wonders why production still runs the old code. Nothing was deployed: the running revision serves the digest it was resolved to, and only a new deploy creates a revision that points at the new one.

A new version of a Cloud Run application is simply a new revision, and it is created the same way as the first one: gcloud run deploy, the service name, and the image address. Google says you can deploy a new revision using the console, the gcloud command line, or a YAML configuration file, and that when you deploy to a service or change its configuration, an immutable revision is created. The detail that catches people is what the revision points at. You can specify an image with a tag, but if you deploy from a tag, it will be resolved to a digest, and the revision will always serve that particular digest. So pushing a newer image under the same tag changes nothing that is running; only a new deploy does. Two flags make new versions easier to manage. The revision suffix is assigned automatically, but you can use your own with the gcloud parameter revision-suffix, which makes a release easy to find later. And before you deploy at all, you can validate your service configuration without deploying it or persisting changes, using the dry-run flag. To do any of this you need the Cloud Run Developer role on the service, granted through Identity and Access Management (IAM).

The revisions a new version leaves behind

Old revisions cost nothing idle — and a thousand is the ceiling

Worked example (synthetic). An auditor asks why a service has four hundred revisions and whether they cost money. They do not, unless minimum instances were set on them; the ones to delete are the ones nobody should ever route to again.

Every new version leaves the previous revision behind, and the exam likes to ask what that costs. Google's answer: revisions that are not receiving requests don't consume any resources and are not billed — with one exception, which is that if a revision has minimum instances configured, there are billing considerations to keep in mind. You do not have to clean up, either. There is a maximum of one thousand revisions per service, and if you exceed it, older revisions are automatically deleted. You can still delete one on purpose, and Google gives the reason you would: to make sure a particular revision won't be accidentally used. To see what you have, gcloud run revisions list with the service and region names them all, and gcloud run revisions describe shows one in detail. If a non-current revision shows the status RETIRED, Cloud Run has retired the infrastructure that revision needed.

Releasing a new version behind a tag

Test it at its own address before it serves anyone

Figure: A four-step flow: deploy the new revision with no traffic and the tag green; test it at the tag's own address, which starts with green followed by three hyphens and the service address; move traffic to the tag with update-traffic and the to-tags flag; and remove the tag with update-traffic and the remove-tags flag.

Worked example (synthetic). A payments team deploys a release tagged green, runs its checks against the green address in production, then moves traffic onto it — no real customer reached the new code until the checks passed.

Unit 3 showed a gradual rollout with no traffic and then small steps. A tag adds one thing to that release: an address of its own. Deploy with no-traffic and a tag — gcloud run deploy, the service, the image, no-traffic, and tag followed by a lowercase name. Google says the tag lets you directly test the new revision at a specific URL, without serving traffic, and gives the shape of that uniform resource locator: with the tag green on the service myservice, you would test the tagged revision at green, three hyphens, then the service's own address. That is what makes Google's recommended pattern possible: deploy it to production, without serving traffic, and test against a tagged revision in production. When it passes, update-traffic with to-tags moves traffic onto the tag, and update-traffic with remove-tags removes the tag afterwards.

Adjusting traffic splitting parameters

A weight per revision, adding up to one hundred

• Several revisions at once: --to-revisions A=50,B=25,C=25
• The weights must add up to one hundred
• LATEST names whichever revision is newest
• Changes are not instantaneous; in-flight requests still finish

Worked example (synthetic). A retailer runs three versions of its recommendation service side by side and wants the newest to get half the traffic. One update-traffic command with three name-and-weight pairs does it, and the weights must total one hundred.

Traffic splitting is where the guide's second consideration lives. Google describes the feature this way: Cloud Run lets you specify which revisions should receive traffic and the share each one receives. For more than two revisions, give update-traffic a comma-delimited list: gcloud run services update-traffic, the service, then to-revisions followed by the list. Google's own example splits three revisions twenty-five, twenty-five and fifty. Two rules keep the list valid. The shares must add up to one hundred. And instead of typing the newest revision's generated name, you can write LATEST, which always means the most recent revision. Two behaviours are worth knowing before you change anything in production. Traffic routing adjustments are not instantaneous. And in-flight requests won't be dropped: during the transition they may be served by either the new or the previous revision, so for a short while both are live.

The split that outlives your next deploy

Once you split, new revisions stop taking all traffic

Figure. Two cards and a band. What people expect: a new deploy takes every request. What Cloud Run does: after a split or a rollback, later deploys keep that split pattern. The way back: update-traffic with the to-latest flag sends all traffic to the newest revision and overrides the split.

Worked example (synthetic). A team rolled back to an older revision last month. Today's release deploys cleanly but gets no requests, because the rollback's traffic assignment is still in force; --to-latest restores the normal behaviour.

This is the traffic behaviour most likely to surprise an engineer, and Google states it plainly: if you split traffic between multiple revisions, or assigned traffic to a previous revision, all subsequent deployments use that traffic split pattern going forward. That second clause matters, because a rollback is exactly that kind of assignment. So after a rollback or a canary split, a routine deploy creates a new revision that receives nothing, and the service keeps serving the old one. The way back is also documented: to return to just using the latest revision without traffic splitting, send all traffic to the latest revision. The command is gcloud run services update-traffic with the to-latest flag, and Google says it overrides any existing traffic splitting, with the new revision serving all of the traffic. In the console the same choice is the box labelled Serve this revision immediately.

Every traffic flag, and what it moves

One command, update-traffic, and four ways to aim it

Worked example (synthetic). Asked to "send a little traffic to the tagged release", the graded command is --to-tags; asked to "stop splitting and just run the newest", it is --to-latest.

All of traffic management is one command, gcloud run services update-traffic, aimed with a different flag. To-revisions takes a list of revision names and shares, and the shares must add up to one hundred. Inside that list, the word LATEST stands for the most recent revision. To-latest, on its own, sends all traffic to the most recent revision and overrides any split. To-tags gives a share to whichever revision carries a tag, so you never have to copy a generated revision name. And remove-tags takes a tag off when you are done with it. Exam items usually describe the intent in words, so read them for which of these five the scenario is asking for.

Setting scaling parameters for autoscaling instances

Autoscaling is automatic; its floor, ceiling and packing are yours

• By default a revision scales to what it needs, and to zero when idle
• Minimum instances (--min): kept warm against slow starts, and billed
• Maximum instances (--max): a cap on cost and on connections
• Concurrency (--concurrency): requests one instance takes at once

Worked example (synthetic). An internal tool is used in bursts and nobody minds a slow first request, so it keeps the defaults. A checkout service cannot afford a slow first request, so it sets a minimum; its database takes limited connections, so it also sets a maximum.

Cloud Run scales for you. By default, each revision is automatically scaled to the number of instances needed to handle incoming requests, events, or central processing unit (CPU) utilization, and when a revision receives no traffic it is scaled to zero. The guide's third consideration is the parameters you set on top of that, and there are three to learn first. Minimum instances is the floor: Google says you can set a minimum number of instances to avoid slow container start times and reduce service latency, and Cloud Run then keeps at least that many running even when they are not processing requests. Those instances do incur billing costs, and they are a best-effort target rather than a guarantee. Maximum instances is the ceiling: it limits scaling in response to incoming requests, which Google says you can use to control your costs or to limit the number of connections to a backing service such as a database. The default is one hundred instances per revision, and the cap can be exceeded briefly during traffic spikes. Concurrency sets how many requests one instance processes simultaneously. The service-level commands are gcloud run services update with min, max, or concurrency.

Four settings, and what each one trades

Every scaling knob buys one thing and costs another

Worked example (synthetic). A legacy image-processing library is not thread-safe, so the team sets --concurrency 1. It works, and the next traffic spike starts many more instances than before — exactly the cost Google warns about.

Read the four settings as trades. Minimum instances buys a fast first request and costs you the idle instances, which are billed. Maximum instances buys a ceiling on cost and on connections to whatever sits behind the service, and Google recommends setting it at the service level unless you have a specific reason to limit a single revision. Concurrency is the subtle one. A higher concurrency setting lets fewer instances handle the same request volume, which can reduce costs — but when concurrency is enabled, Cloud Run does not provide isolation between concurrent requests processed by the same instance, so the code must be safe to run concurrently. By default, instances deployed with the gcloud command line have a maximum concurrency of eighty times their number of virtual processors. At the other extreme, if your code cannot process parallel requests, Google says to set concurrency to one — and warns that a concurrency of one is likely to hurt scaling, because many instances have to start up to handle a spike.

Service level or revision level, and when the processor runs

Two flags that look alike, and a billing choice that sets CPU

Figure. Four cards. Service level: the min and max flags apply to the whole service and are recommended. Revision level: min-instances and max-instances apply per revision and are only for services that already used them. Request-based billing, the default, set with cpu-throttling: the processor runs only while handling a request; suits sporadic traffic. Instance-based billing, set with no-cpu-throttling: the processor runs for the instance's whole life so background work can continue after a response; suits steady traffic.

Worked example (synthetic). A service must flush analytics after it has already answered each request, and the flushes keep disappearing. Under request-based billing the processor stops with the response; --no-cpu-throttling switches to instance-based billing and the background work completes.

Two details finish the objective. First, the flags. The service-level commands are min and max. Google also documents min-instances and max-instances, which set the same limits per revision, but it recommends applying minimum instances at the service level and not combining the two, and says revision-level scaling is only available for services that previously had the feature configured. Revision-level minimums also start whenever a revision has a traffic tag, which is how tagged revisions quietly run up a bill. Second, when the processor runs, which Google now calls the billing setting. Request-based billing is the default: instances are only charged when they process requests, start and shut down, and the central processing unit (CPU) is only allocated during request processing — the setting was previously called CPU only allocated during request processing. Instance-based billing charges for the whole lifecycle, allocates the processor for the whole lifecycle too, and lets you run short-lived background tasks after returning responses; it was previously called CPU always allocated. Google recommends request-based for sporadic, bursty traffic and instance-based for steady traffic. The flags are cpu-throttling for request-based and no-cpu-throttling for instance-based. One more consequence: scaling from zero can only be triggered by a request, so a service that is not processing requests cannot scale up from zero on its own.

What this topic actually tests

Three objectives, four traps

A pushed tag is not a deploy — revisions pin a digest. A split outlives the next deploy — --to-latest ends it. --min is warm and billed; --max caps cost and connections. CPU after the response needs instance-based billing — --no-cpu-throttling.

Close on the four traps this topic sets. First, a new version exists only when you deploy it: a revision serves the digest its tag was resolved to, so pushing a new image under the same tag changes nothing that is running. Second, a traffic split — or a rollback to an older revision — survives later deployments, and update-traffic with to-latest is how you end it. Third, the scaling floor and ceiling: minimum instances keep instances warm against slow starts and are billed while they wait, and maximum instances cap both cost and the connections your service opens to a database, set at the service level with min and max. Fourth, background work after a response needs the processor to keep running, which is instance-based billing, set with no-cpu-throttling. Unit 4 continues with the same day-two view for storage, networking and monitoring.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 4
• Deploying container images to Cloud Run
• Manage revisions
• Rollbacks, gradual rollouts, and traffic migration
• About instance autoscaling in Cloud Run services
• Set minimum instances for services
• Set maximum instances for services
• Maximum concurrent requests per instance
• Set maximum concurrent requests per instance
• Billing settings for services