GCP
Intermediate 14 min read GCP

Cloud Run and Cloud Functions

Serverless containers and event-driven functions

Cloud Run runs containers on-demand with per-request billing and VPC support; Cloud Functions is FaaS for events. Together they deliver serverless on GCP with autoscaling to zero when idle.

Cloud RunCloud FunctionsserverlesscontainerFaaSgen 2 functions
Prerequisites: GCP Service Catalog Serverless
Before we start

What you will learn

  • Deploy a container to Cloud Run
  • Choose Cloud Functions (1st/2nd gen) for events
  • Use scaling, concurrency and VPC features
In 60 seconds

Cloud Run executes HTTP-serving containers on Knative, scaling to zero and billing by request. Cloud Functions runs code triggered by events (Storage, Pub/Sub, HTTP). Use Run for containers + long-lived-ish services, Functions for short event handlers.

Introduction

What is this?

Cloud Run is Google's managed, Knative-based platform: give it a container image, an HTTP port and optional min/max instances — it scales automatically (including to zero), exposes a URL and TLS, and integrates with IAM, VPC connectors and secrets. Cloud Functions (1st gen — Node/Python/Go fast functions; 2nd gen — based on Cloud Run with more triggers) handles event-driven code: Storage events, Pub/Sub messages, HTTP calls. Both use per-request/per-computation billing and autoscale to zero.

Motivation

Why do you need it?

  • Cloud Run turns any Dockerized app into serverless instantly — the smoothest lift in GCP.
  • Scale-to-zero means idle cost is literally zero; spikes handled by burst.
  • Functions give native event triggers without writing a poller.
  • Both inherit IAM, Cloud Logging/Monitoring and VPC connectors.
Think about it

Mental model

Imagine

A takeout counter that scales staff per rush

Think of

Cloud Run

Nobody's paid at an empty counter; when the rush hits, staff appear automatically. Cloud Run runs your container only when requests exist, scaling workers to match — and you pay for the meal, not the kitchen.

Mechanics

How it works

  • Cloud Run: a revision runs from an image with a declared container concurrency; a Knative controller scales replicas (min/max).
  • Requests hit a stable URL; each revision/immutable config and a traffic split lets you do canary/green rollout.
  • Cloud Functions: triggers (HTTP, Pub/Sub, Cloud Storage, Firestore) invoke a handler; 2nd-gen is a Cloud Run service under the hood.
  • VPC connector gives access to private GCP resources; compute charges follow request volume and runtime seconds.
  • IAM governs invocation and permissions; Cloud Logging captures versions automatically.

Cloud Run and Functions placement.

HTTP / Event
Cloud Run
Functions
Autoscaler
Backends
Real world

In production

  • An API team runs every microservice as a Cloud Run service with min=1 for warm latency and traffic split for canaries.
  • A pipeline uses a Storage-triggered Function that parses uploaded CSVs into BigQuery.
  • A multi-tier app uses Cloud Run for the backend and a Function for resizing thumbnails on upload.
Guidelines

Best practices

  • Set min instances to keep cold-start-sensitive services warm; keep memory appropriate to the image.
  • Configure concurrency deliberately: low for heavy per-request work, higher for IO-light APIs.
  • Pin functions to zone-region triggers; scope IAM roles tightly; use VPC connector / secrets only when needed.
  • Enable graceful shutdown handling in your app for scale-down.
Watch out

Common mistakes

  • Cold-start surprises on a latency-critical user path — solve with min instances, not hope.
  • Overloading a single Cloud Run service with long jobs that hit request timeouts.
  • Exposing secrets in env vars instead of Secret Manager references.
  • Function per-request cost blowing up for a botnet — put IAM/authenticated triggers on public endpoints.
Root cause analysis

Common issues

Error
Cold start latency spikes on first requests
Root cause

Container image large or cold instances scaling from zero

Fix

Set min-instances, reduce image size, streamline local init.

Error
Function times out on heavy work
Root cause

Long workload in a short-lived handler

Fix

Extend function timeout limits or shift heavy work to Cloud Run/Workflows.

Error
Only first request works after a traffic split change
Root cause

New revision failed health, or dependencies not warmed

Fix

Check revision health status and inspect the failed request stack traces before splitting traffic.

When things break

Debugging tips

  • 503s: check instance scaling (min/max), CPU/memory limits and cold start latency.
  • Function failing silently: read Cloud Logging for the function — print stack traces to stderr.
  • Traffic split: verify revision health before moving percentages; use gradual rollout.
  • VPC access denied: check the connector's network and firewall routes.
Interviews

Interview checkpoint

Practice

Hands-on lab

Deploy a Container to Cloud Run
30 min · intermediate
In progress
Objectives
  • Build and push a sample image
  • Deploy to Cloud Run with a public URL
  • Split traffic between two revisions

Deploy a Container to Cloud Run

30 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

Which GCP service lets you run a containerized app that scales to zero?

Go deeper

Official documentation

GCP — Cloud Run overview
docs
GCP — Cloud Functions overview
docs
GCP — Choosing runtimes
docs