Cloud Functions charges on three meters: the number of invocations, the compute time your function runs measured in resource seconds, and the memory and CPU you allocate to it, plus any networking it generates. The trap in serverless is believing it is automatically cheap. Because there is no idle server to spot, an overprovisioned function quietly overpays on every single invocation, and a function called millions of times multiplies any per call waste into a large bill. The levers are the inverse of those costs: provision less memory, finish faster, run more requests per instance where you can, and reserve warm capacity only where latency demands it. None of these require leaving serverless; they make serverless behave the way its pricing rewards.
This sits in the GCP compute cluster with Compute Engine rightsizing that sticks and spot VMs and preemptible economics on GCP. Read those for rightsizing the VM side and for moving tolerant batch work onto cheaper capacity.
What are you actually paying for?
Three things. Invocations are billed per call beyond a free monthly allowance, so high frequency triggers drive this line. Compute time is billed as resource seconds, the product of how long your function runs and how much CPU and memory it holds while running, so both slow code and overallocated functions cost more. Memory and CPU allocation set the rate per second, because on Cloud Functions CPU scales with the memory tier you choose. The compounding effect is the important part: allocating double the memory a function needs doubles the resource second rate on every invocation, and at millions of calls that doubling is the whole bill.
How do you size memory without slowing the function?
Memory allocation does two things at once: it sets the memory ceiling and, because CPU scales with it, the processing power. So sizing down too far can make a function run longer, and a longer run at a lower rate sometimes costs more than a shorter run at a higher rate. The right method is to measure. Observe peak memory use and execution time across the memory tiers, and pick the tier where the function comfortably fits its memory and runs fast enough that resource seconds are minimized. The cheapest tier is not always the lowest one; it is the one that finishes quickly without wasting allocated headroom. Profile, do not guess.
When does concurrency cut the bill?
Newer Cloud Functions, built on the same platform as Cloud Run, can handle more than one request per instance. Raising concurrency means a single warm instance serves several simultaneous requests, so for input or output bound functions that spend much of their time waiting on a database or an external call, you pay for one instance rather than many during a burst. This does not suit CPU bound functions, where concurrent requests would contend for the same processor, but for the common case of a function gated on network latency, concurrency turns a fleet of idle waiting instances into a few busy ones and cuts compute time materially.
Are minimum instances worth it?
Minimum instances keep a set number of function instances warm so requests skip the cold start, and they bill for that reserved idle capacity even when no request arrives. That is the tradeoff: you pay for warmth to remove latency. Reserve minimum instances only for user facing, latency sensitive functions where a cold start would hurt the experience, and leave purely asynchronous or batch functions to scale from zero. Setting a blanket minimum across all functions is a common and expensive mistake, because you pay around the clock to keep warm code that nobody would have noticed starting cold.
A worked example
An indicative European SaaS company ran a large fleet of Cloud Functions and treated serverless as free until the line grew. Three issues drove it: most functions were allocated far more memory than they used, every function had a blanket minimum instance setting inherited from a template, and several high volume input or output bound functions ran one request per instance. They profiled memory and dropped each function to its measured tier, removed minimum instances from everything except the handful of latency sensitive endpoints, and raised concurrency on the network bound functions. Serverless spend fell sharply with no degradation in user facing latency. Figures are verified against billing data and anonymised.
Frequently asked questions
How does GCP Cloud Functions charge?
Does allocating less memory always save money?
Should I set minimum instances on Cloud Functions?
Where this fits the cost review
Serverless looks free until invocation volume and overprovisioned memory add up, so the same rightsizing discipline you apply to VMs belongs here too. We run that review as an independent buyer side advisory across AWS, Azure, GCP, and OCI, with zero provider commissions and a guarantee: we reduce your cloud spend or we reimburse our service fee.
For monthly buyer side analysis delivered to your inbox, subscribe to The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.