Cloud Run vs Cloud Functions: Which to Use in GCP

Cloud Run vs Cloud Functions in simple terms

Cloud Functions is a single-purpose tool. You write one function, deploy it, and it runs when an event arrives: a Pub/Sub message, a file upload to Cloud Storage, or an HTTP request. You do not think about servers, containers, or infrastructure. Google handles all of it.

Cloud Run is a general-purpose platform. You build a container with any language, any framework, and any dependencies. That container can serve a full web application with multiple routes, background logic, and custom middleware. Google handles the scaling and infrastructure, but you control the runtime.

How this choice works

The decision comes down to six factors.

Abstraction level. Cloud Functions abstracts away the server entirely. You write a function signature, and the platform handles the HTTP framework, process management, and container build. Cloud Run gives you a container: more control, more responsibility.

Source deployment vs container deployment. Cloud Functions deploys source code with a dependency file. Cloud Run deploys a container image you build yourself. If your team already uses Docker, Cloud Run fits your workflow. If your team has no container experience, Cloud Functions removes that barrier.

Event-driven function vs full service. Cloud Functions is designed around triggers: an event fires, the function runs, and it finishes. Cloud Run is designed around services: a container starts, listens for requests, and handles them until it is stopped. Both can respond to HTTP and Eventarc events, but the mental model is different.

Single handler vs multiple routes. Each Cloud Functions deployment has one entry point. A Cloud Run service can have any number of routes handled by a full web framework. If you need /users, /orders, and /health in one deployment, Cloud Run is the natural fit.

Runtime and dependency control. Cloud Functions supports a fixed set of runtimes (Node.js, Python, Go, Java, Ruby, .NET, PHP) and does not allow OS-level package installation. Cloud Run supports any language and any dependency that fits in a container, including system libraries, compiled binaries, and custom base images.

Operational complexity. Cloud Functions is simpler to deploy and operate for small workloads. Cloud Run requires a Dockerfile and a container build step, but gives you a consistent local-to-production workflow and more options for CI/CD pipelines and observability.

Key differences

This table compares Cloud Functions 2nd generation (Cloud Run functions) with Cloud Run services. Cloud Functions 1st generation has stricter limits (9-minute timeout, fewer triggers, less memory) and should not be used for new projects.

When to use Cloud Functions

Cloud Functions is the right choice when the workload is a single-trigger, single-purpose handler and you want the simplest deployment model possible. These are the strongest use cases.

• Cloud Storage upload processing. A file lands in a bucket and you need to process it: resize an image, parse a CSV, or trigger a downstream pipeline. Cloud Functions handles this with a native event-driven trigger and no container setup.
• Pub/Sub event handler. Consuming messages from a Pub/Sub topic is one of the most common Cloud Functions patterns. The function processes the message and acknowledges it. No server to manage, no consumer group to configure.
• Firestore trigger. Reacting to document creates, updates, or deletes in Firestore. Cloud Functions has native Firestore triggers that fire on specific collection or document changes.
• Lightweight webhook. Receiving a webhook from a third-party service (Stripe, GitHub, Twilio) and writing the result to a database or queue. One function, one endpoint, no framework overhead.
• Simple scheduled automation. Running a cleanup script, sending a daily report, or refreshing a cache on a cron schedule using Cloud Scheduler. Cloud Functions keeps this simple. No container to maintain for a 5-second task.

When to use Cloud Run

Cloud Run is the right choice when you need a full service, custom dependencies, or a container-based workflow. These are the strongest use cases.

• REST API with multiple endpoints. An API with /users, /orders, /auth, and /health belongs in a single Cloud Run service with a real web framework, not four separate function deployments.
• Containerised web application. A Next.js frontend, a Django admin panel, or a Go web application with templates and static assets. Cloud Run serves these as a standard container with an HTTPS URL and automatic TLS.
• Service with custom OS packages. If your workload needs ImageMagick, FFmpeg, a machine learning library with native bindings, or a specific system library, you install it in your Dockerfile and deploy to Cloud Run.
• Background service with shared middleware. Authentication middleware, request logging, rate limiting, and database connection pooling shared across multiple routes. Cloud Run gives you a real server with full framework support.
• Container parity from local to production. The same Docker image runs on your laptop, in CI, and on Cloud Run. No environment differences, no “works on my machine” surprises. This matters for teams with a container-based CI/CD pipeline.
• Batch or long-running jobs. Cloud Run Jobs run containerised tasks for up to 24 hours per execution. Use them for data migrations, report generation, or any batch workload that exceeds the function timeout.

Real examples

Abstract comparisons only go so far. Here is how the choice plays out in common scenarios.

Image resize on upload. A user uploads a photo to Cloud Storage and you need to generate a thumbnail. This is a textbook Cloud Functions use case: a single Cloud Storage trigger, a single operation, and no need for a container. Deploy the function, configure the trigger, and it works.

Pub/Sub consumer that writes to BigQuery. A Pub/Sub topic receives analytics events and you need to batch-insert them into BigQuery. If the consumer does one thing (read the message and write the row), Cloud Functions is simpler. If the consumer needs to validate, transform, enrich, and route messages across multiple tables, a Cloud Run service with proper error handling and retry logic is easier to maintain.

Webhook endpoint for a payment provider. Stripe sends a webhook to your endpoint. You verify the signature, update the order in your database, and return 200. If this is the only endpoint, Cloud Functions is enough. If you also need /api/orders, /api/refunds, and /api/customers, put them all in one Cloud Run service.

API backend for a mobile app. A mobile app calls your API for authentication, user profiles, notifications, and data sync. This is a Cloud Run service: multiple routes, shared middleware, database connection pooling, and potentially WebSocket support. Building this as 15 separate Cloud Functions would be a maintenance headache.

Nightly data export job. Every night at 2am, you export data from Cloud SQL to Cloud Storage as a CSV. If the export takes under 60 minutes and needs no special packages, a scheduled Cloud Function works. If the export needs custom libraries, takes longer, or requires parallelism, use a Cloud Run Job.

Cloud Run vs Cloud Functions pricing

Both services charge for CPU time, memory time, and number of invocations. The per-unit rates are similar. The cost difference comes from how instances are used, not from the price list.

Concurrency drives the cost gap. Cloud Run defaults to 80 concurrent requests per instance. One instance serves 80 simultaneous users. Cloud Functions defaults to 1 concurrent request per instance. The same 80 simultaneous users require 80 function instances. More instances means more cold starts, more memory allocation, and higher cost at scale.

Instance count matters more than per-request price. At low traffic (a few requests per minute), both services cost about the same, often within the free tier. At moderate to high traffic, Cloud Run’s concurrency model usually results in fewer running instances and lower total cost. For Cloud Run cost optimisation at scale, tuning concurrency and minimum instances is the most effective lever.

Billing mode affects idle cost. Cloud Run offers two billing modes: request-based (CPU allocated only during request processing) and instance-based (CPU always allocated). Request-based billing means zero cost when idle. Instance-based billing is useful for workloads that do background processing between requests. Cloud Functions always uses request-based billing.

Do you need to migrate?

If your Cloud Functions work well, keep them. A function that handles a single trigger, runs within its timeout, and does not need custom OS packages has no reason to move to Cloud Run. Migration adds complexity without adding value in this case.

Migrate when you outgrow the function model. The clearest signals are: you need multiple routes in one deployment, you need OS-level packages that Cloud Functions does not support, you want a consistent container-based workflow across all services, or you need higher default concurrency without per-function tuning.

Migration is low-risk. Cloud Functions 2nd generation already runs on Cloud Run. To migrate, wrap your function logic in a web framework (Express, Flask, or equivalent), build a container image, and deploy to Cloud Run. Eventarc triggers work the same way on both. The underlying platform is identical, so networking, Serverless VPC Access, IAM, and security model carry over directly.