Cloud Functions vs Cloud Run cost: why concurrency tips it

Quick answer

Cloud Functions (2nd gen) runs on Cloud Run, so per-request and per-resource-second rates are similar and both scale to zero. Cloud Run is usually cheaper for request-heavy workloads because concurrency lets one instance serve many requests at once, spreading the cost. Use Cloud Functions for simple event handlers, Cloud Run for HTTP services, higher concurrency, and custom containers.

On GCP the line between "function" and "container service" has blurred — Cloud Functions 2nd gen is built on Cloud Run — so the cost comparison is less about rates and more about how each model uses instance-time. The lever that actually separates them is concurrency.

Shared mechanics

Both bill the same shape: a per-request charge plus vCPU-seconds and GiB-seconds of allocated resources while handling requests, with a free tier, and both scale to zero when idle. Because 2nd-gen Functions sit on Cloud Run, the underlying rates converge.

Concurrency is the cost lever

Cloud Run lets you set concurrency — how many simultaneous requests one instance handles. At concurrency 80, a single instance serves up to 80 requests at once, so you pay for one instance's resource-seconds instead of 80. Traditional Cloud Functions handle one request per instance, so request-heavy traffic spins up more instances and more billable instance-time. For anything with meaningful concurrent traffic, this makes Cloud Run cheaper.

Choose by developer model, not just price

Cloud Functions: deploy a function and a trigger (Pub/Sub, storage event, HTTP). Simplest for single-purpose event handlers; no container to build.
Cloud Run: deploy a container and a service. More control — concurrency, custom runtimes, longer requests, sidecars — and the cost edge on request-heavy workloads. See the Cloud Run pricing page.

The same scale-to-zero rules apply

Both cost near nothing when idle if min-instances is zero. Setting a warm floor to avoid cold starts turns either into an always-on bill — the same trap covered in Cloud Run vs GKE. If you need several warm instances continuously, the serverless cost advantage shrinks and a node-based option may be worth comparing.

FAQ

Is Cloud Functions or Cloud Run cheaper?

They're close, because Cloud Functions (2nd gen) runs on Cloud Run underneath, so the per-request and per-resource-second rates are similar. Cloud Run tends to be cheaper for sustained or higher-concurrency workloads because one container instance can handle many concurrent requests, spreading the resource cost across them. Cloud Functions is simpler for single-purpose event handlers.

How is each priced?

Both bill per request plus vCPU-second and GiB-second of allocated resources while handling requests, with a free tier, and both scale to zero. Cloud Run's concurrency setting lets one instance serve many requests at once; Cloud Functions traditionally handles one request per instance, which can mean more instance-time for the same traffic.

When should I use Cloud Run over Cloud Functions?

Use Cloud Run for HTTP services, higher concurrency, custom containers, longer requests, or anything needing more control over the runtime. Use Cloud Functions for simple event-driven handlers (a Pub/Sub message, a storage trigger, an HTTP endpoint) where you want to deploy a function, not build a container.

Does concurrency affect cost?

Significantly on Cloud Run. With concurrency set above 1, a single instance handles multiple simultaneous requests, so you pay for far less instance-time than running one instance per request. This is the main reason Cloud Run can be cheaper than Cloud Functions for request-heavy workloads.

Are Cloud Functions 2nd gen and Cloud Run the same thing?

Cloud Functions 2nd gen is built on Cloud Run and Eventarc, so they share infrastructure and pricing mechanics. The difference is the developer experience: Functions gives you a function-and-trigger model, Cloud Run gives you a container-and-service model with more control. Cost-wise they converge.

How does C3X estimate these?

C3X prices a google_cloudfunctions_function and a google_cloud_run_v2_service from their resource allocation and treats request/invocation volume as usage-driven, so you can compare the two for your expected traffic.

What to do next

For most new services the question is Functions-vs-Run developer experience, with cost a near-tie until concurrency tips it toward Run. C3X prices a google_cloudfunctions_function and a google_cloud_run_v2_service from their resource allocation, so you can compare them for your traffic. The quickstart runs it in minutes.