GCP Cloud Functions 2nd gen cost: what changed and how to optimize

Quick answer

Cloud Functions 2nd gen is built on Cloud Run and Eventarc, so it inherits Cloud Run's billing: CPU at roughly 0.000024 dollars per vCPU-second, memory at roughly 0.0000025 dollars per GiB-second, and requests at about 0.40 dollars per million, with a monthly free tier. The big change from 1st gen is concurrency: a 2nd gen instance can handle multiple concurrent requests, so one instance serves many requests instead of one per instance, which can cut cost sharply for concurrent workloads. The optimization levers are raising concurrency so fewer instances handle the same load, right-sizing CPU and memory, and setting minimum instances only when cold starts genuinely hurt.

Cloud Functions 2nd gen is a significant re-platforming: instead of the original functions runtime, it runs on Cloud Run and Eventarc. That gives it Cloud Run's scaling, concurrency, and longer request timeouts, and it also changes the cost model. If you are moving from 1st gen or choosing between the two, understanding the new billing and the concurrency change is where the savings are.

How 2nd gen bills

Component	Approximate rate
CPU	About 0.000024 dollars per vCPU-second
Memory	About 0.0000025 dollars per GiB-second
Requests	About 0.40 dollars per million
Free tier	Monthly free requests, vCPU-seconds, and GiB-seconds

Because 2nd gen sits on Cloud Run, its charges are Cloud Run charges: CPU and memory billed per second while an instance runs, plus a per-request fee, with a monthly free tier that covers low-volume use. This is different from 1st gen, which billed invocations, GB-seconds, and GHz-seconds separately. The practical effect is that 2nd gen cost tracks how long instances run and how much CPU and memory they use, so the same optimization levers as Cloud Run apply.

The concurrency change

The most important cost difference is concurrency. In 1st gen, each instance handled one request at a time, so 100 simultaneous requests meant 100 instances. In 2nd gen, an instance can handle multiple concurrent requests, up to a configurable limit, so those 100 requests might be served by a handful of instances. Since you pay for instance time, packing more requests per instance means fewer instance-seconds for the same load, which can cut cost substantially for workloads with many lightweight concurrent requests.

When concurrency helps and when it does not

Higher concurrency helps for I/O-bound functions that spend time waiting, on network calls or database queries, since one instance can interleave many waiting requests cheaply. It helps less for CPU-bound functions, where each concurrent request competes for the same cores and you may need more CPU per instance anyway. Set concurrency to the level your function's workload profile supports without degrading latency, then let fewer instances absorb the load. This is the same reasoning behind choosing between Cloud Functions and Cloud Run.

Keeping function cost low

Right-size the CPU and memory allocated to each function to what it actually needs, raise concurrency for I/O-bound work so fewer instances handle the same traffic, and use minimum instances only where cold starts genuinely hurt, since idle warm instances bill continuously. Stay within the monthly free tier for low-volume functions. Because 2nd gen inherits Cloud Run economics, treat it as a Cloud Run service for cost purposes. Price your functions against the resource catalog so the concurrency and allocation choices are costed before deploy.

FAQ

How is Cloud Functions 2nd gen priced?

It runs on Cloud Run and Eventarc, so it inherits Cloud Run billing: CPU at roughly 0.000024 dollars per vCPU-second, memory at roughly 0.0000025 dollars per GiB-second, and requests at about 0.40 dollars per million, with a monthly free tier. Cost tracks how long instances run and how much CPU and memory they use, unlike 1st gen which billed invocations, GB-seconds, and GHz-seconds separately.

What is the main cost difference between Cloud Functions 1st and 2nd gen?

Concurrency. In 1st gen each instance handled one request at a time, so 100 simultaneous requests meant 100 instances. In 2nd gen an instance can handle multiple concurrent requests, so those 100 might be served by a handful of instances. Since you pay for instance time, packing more requests per instance cuts cost substantially for concurrent workloads.

When does raising concurrency reduce Cloud Functions cost?

For I/O-bound functions that spend time waiting on network calls or database queries, since one instance can interleave many waiting requests cheaply, so fewer instances handle the same load. It helps less for CPU-bound functions, where concurrent requests compete for the same cores and you may need more CPU per instance anyway. Set concurrency to the level your workload supports without hurting latency.

Should I use minimum instances on Cloud Functions 2nd gen?

Only where cold starts genuinely hurt, such as latency-sensitive interactive functions. Minimum instances keep instances warm to avoid cold starts, but idle warm instances bill continuously at the reduced idle rate. For background or low-traffic functions, scaling to zero and accepting occasional cold starts is cheaper. Use the smallest minimum that keeps latency acceptable.

How does C3X help with Cloud Functions 2nd gen cost?

C3X prices your Cloud Functions 2nd gen configuration from Terraform before you deploy, translating CPU, memory, concurrency, and minimum-instance settings into cost in the pull request. That lets you see the effect of raising concurrency or right-sizing memory at design time, so the function runs on the cheapest workable configuration rather than an over-allocated one discovered on the bill.

What to do next

Cost your function settings before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.