Service 03

Cloud Run

ServerlessContainersCompute

Cloud Run runs containerized workloads on demand, scaling from zero to thousands of instances based on incoming traffic. You provide a container image; Cloud Run handles request routing, TLS termination, autoscaling, and infrastructure. You pay only for CPU and memory consumed while instances are handling requests — nothing when idle at zero instances.

This economics model and the minimal operational surface have made Cloud Run the practical default for new HTTP services and APIs on Google Cloud.

Services vs Jobs

A Cloud Run service serves incoming HTTP or gRPC requests continuously, scaling based on concurrent request volume and maintaining its HTTPS endpoint indefinitely. A Cloud Run job executes a task to completion — data processing, report generation, database maintenance — on a schedule, on-demand, or triggered by events.

Concurrency and Scaling

Each container instance handles multiple concurrent requests simultaneously — the default is 80 concurrent requests per instance, configurable up to a maximum of 1000 — a key architectural difference from per-request FaaS platforms. You tune concurrency based on what your application can sustain without resource contention.

Minimum instances keep a configurable number always warm, eliminating cold starts for latency-sensitive services — at the cost of paying for idle capacity even at zero traffic. Maximum instances cap scale-out to prevent runaway cost. CPU allocation can be set to always-on between requests for background tasks.

Revisions and Traffic Splitting

Revision Acurrent

95% traffic

one endpoint URL

Stable version takes most traffic. Each deploy creates an immutable revision; the URL stays the same.

Revision Bcanary

5% traffic

same endpoint URL

New version gets a slice. Split by percentage — no DNS changes, no second load balancer. Promote or roll back by shifting the split.

Each deployment creates a new immutable revision. Traffic routes to revisions by percentage — send 5% to a new revision for canary testing, then gradually shift as confidence grows. Rolling back is instant: redirect all traffic back to the previous revision.

Networking

Cloud Run services get a managed HTTPS endpoint automatically. Route through an Application Load Balancer for WAF rules, CDN, and advanced routing. Set ingress to internal to restrict access to VPC-originating traffic. Configure Direct VPC Egress to reach private VPC resources (Cloud SQL, Memorystore, internal services).

Configuration and Secrets

Mount secrets from Secret Manager as environment variables or volume files. This avoids embedding secrets in container images, deployment configs, or Terraform state. Pinning a specific secret version makes deploys deterministic.

Cloud Run vs GKE vs Cloud Functions

Cloud Run — containerized HTTP services, jobs, event-driven workloads. Minimal ops. Right default for new services.

GKE — complex multi-service orchestration, stateful workloads, GPU requirements, existing Kubernetes expertise.

Cloud Functions — same Cloud Run infrastructure at gen 2, but accepts source code. Simpler for small, single-purpose functions.

Common Mistakes

Container images that are hundreds of megabytes — large images mean slow cold starts. Use multi-stage builds and distroless or alpine base images.
No minimum instance setting on latency-sensitive production services.
Storing state in the local container filesystem — instances are ephemeral, local writes disappear on replacement.
Not setting a maximum instance count — runaway scale generates unexpected billing.
Not using Secret Manager for secrets.

Best Practices

Build minimal container images with multi-stage builds and alpine or distroless bases.
Set minimum instances to 1 on any service with a latency SLO.
Set maximum instances to limit blast radius.
Use Secret Manager for all secrets, mounted as environment variables or volume files.
Configure Direct VPC Egress for services connecting to VPC resources.
Use traffic splitting for canary deployments.

Comparable services AWS App Runner, ECS Fargate Azure Azure Container Apps

Knowledge Check

By default, how many concurrent requests does a single Cloud Run instance handle?

1 — one request per instance, like a traditional FaaS platform
80
1,000 — this is the maximum you can configure, not the default
Unlimited — there is no configured maximum

What is the difference between a Cloud Run Service and a Cloud Run Job?

Services handle gRPC; Jobs handle HTTP requests
Services serve HTTP requests continuously; Jobs execute a task to completion and then stop
Jobs scale to zero between runs; Services require a minimum of one warm instance running at all times
Services are billed per request; Jobs are billed per hour

What is the trade-off of setting minimum instances to 1?

The service no longer autoscales beyond that one instance, capping concurrency at a single container
Cold starts are eliminated, but you pay for idle capacity even when traffic is zero
Maximum throughput is reduced to match a single instance
Secrets can no longer be mounted from Secret Manager

What is the purpose of traffic splitting between Cloud Run revisions?

Distributing load across multiple regions for lower latency
Routing a percentage of traffic to a new revision for canary testing before a full rollout
Separating inbound HTTP and gRPC traffic so each protocol routes to a different backend revision
Prioritizing traffic from paying customers

How should secrets be provided to a Cloud Run service?

Embedded in the container image at build time
As plaintext environment variables defined directly in the service deployment configuration block
Via Secret Manager, mounted as environment variables or volume files at runtime
Through a config file checked into the source repository

You got correct