FinOps Inform

Cloud function invocation cost explained for engineers

Discover how to manage cloud function invocation costs effectively. Learn about charges, billing components, and avoid unexpected expenses.

Kori August 16, 2026 · 14 min read

Every time a Google Cloud Function executes, you pay a flat per-invocation charge of $0.0000004 (that is, a per-invocation charge applied after the first 2 million free invocations) per billing account each month. But invocations are rarely the largest line item on your bill. The total cost of cloud function calls is determined by four components working together:

Invocations — a standard charge per million invocations after the free tier
Compute — billed as GB-seconds (memory × time) and GHz-seconds (CPU × time), rounded up to the nearest 100 ms
Network egress — charged per GB of outbound data, with a free allowance
Ancillary costs — Cloud Build minutes, Artifact Registry storage, and log ingestion

Understanding how these interact is what separates a predictable serverless bill from a monthly surprise.

Key takeaways

Google Cloud Function costs are driven primarily by compute (GB-seconds and GHz-seconds), with invocations, egress, and ancillary charges compounding at scale, and the free tier covering only the first 2 million invocations and 400,000 GB-seconds per billing account per month.

Point	Details
Free tier scope	2 million invocations, 400,000 GB-seconds, and 5 GB egress per billing account monthly.
Invocation rate	$0.0000004 per invocation beyond the free tier; retries and failures count equally.
Compute dominates	GB-seconds and GHz-seconds, rounded to 100 ms, typically exceed invocation charges at scale.
Quick wins first	Fix verbose logging and retry configuration before any architectural changes.
Koritsu AI	Provides free assessment and success-fee FinOps support to identify and fix the functions driving unnecessary spend.

How cloud function invocation costs break down

The cloud function pricing breakdown follows a layered model. Each layer is independent, but they compound quickly at scale. The table below shows the four components, their billing units, free-tier allowances, and where regional pricing differences apply.

Diagram of cloud function pricing components and free tiers

Free-tier allowances are aggregated across all projects under a single billing account, not per project. That matters if you run multiple functions across several GCP projects, the combined usage draws from one shared pool.

For most API-style workloads, compute (memory and CPU) is the dominant cost driver once you exceed the free tier. Invocations become significant only at very high request volumes or when individual function runtimes are extremely short. Egress can overtake both for functions that return large payloads or call external APIs that return substantial data. Ancillary costs (builds, logs, storage) are often overlooked entirely, which is where surprise charges tend to appear.

How invocation charges actually work

The per-invocation charge is the simplest component to understand, but it has edge cases that catch teams off guard.

The first 2 million invocations per month are free, applied at the billing account level. Beyond that, every invocation costs $0.0000004, regardless of whether the function succeeded, failed, or timed out. Retries count. Fan-out counts. A function that triggers three downstream functions counts as four invocations total.

What constitutes an invocation:

An HTTP request hitting an HTTP-triggered function
A background event (Pub/Sub message, Cloud Storage event, Firestore trigger)
A retry of a failed invocation (automatic retries in event-driven functions)
A function called by another function (each call is billed separately)
A deployment-triggered test invocation (rare, but possible)

The per-invocation formula is straightforward:

Calculate total monthly invocations (N)
Subtract the free tier: billable invocations = max(0, N − 2,000,000)
Multiply: invocation cost = billable invocations × $0.0000004

Three quick examples to make this concrete:

10,000 invocations/month — entirely within the free tier. Invocation cost: $0.00
1,000,000 invocations/month — still within the free tier. Invocation cost: $0.00
10,000,000 invocations/month — 8 million are billable. Cost: 8,000,000 × $0.0000004 = $3.20

The invocation charge alone is rarely alarming. At 10 million calls per month, you pay $3.20 in invocation fees. The compute bill for those same calls is almost always larger.

Compute billing: GB-seconds, GHz-seconds, and generation differences

Compute is where the real money goes. Google Cloud Functions bills memory and CPU separately, both rounded up to the nearest 100 milliseconds per invocation.

First-gen (Cloud Run functions 1st gen)

First-gen functions bill on two dimensions simultaneously:

GB-seconds = (memory allocated in GB) × (execution time in seconds)
GHz-seconds = (CPU speed in GHz, fixed per memory tier) × (execution time in seconds)

Memory and CPU are coupled in first-gen: allocating more memory automatically increases the CPU allocation. A 256 MB function gets 0.167 vCPU; a 2,048 MB function gets 1 vCPU. You cannot set them independently.

Second-gen (Cloud Run functions / Cloud Run)

Second-gen functions, backed by Cloud Run, decouple CPU from memory. You specify vCPU count and memory independently. Billing uses vCPU-seconds and GB-seconds, and Cloud Run rounds to the nearest 100 ms. Second-gen also supports CPU allocation during idle time (when configured), which changes the cost profile for functions with sustained concurrency.

Representative first-gen compute pricing applies per 100 ms, mapped to memory tier, in Tier 1 regions (us-central1, europe-west1, asia-east1).

Tier 2 regions (most others outside the three Tier 1 zones) carry higher per-unit rates. If your functions run in a Tier 2 region, your compute bill will be materially higher for identical workloads.

The 100 ms rounding rule has a disproportionate effect on short functions. A function that completes in 20 ms is billed as if it ran for 100 ms, a 5× overcharge on the compute dimension. Packing more work into each invocation, or reducing cold-start overhead, directly reduces this rounding tax.

What egress, Cloud Build, and logging add to your bill

Compute and invocations are not the whole picture. Three categories of ancillary cost regularly appear on GCP bills and are often missed during cost modelling.

Network egress is charged per GB of data leaving Google's network. The free tier includes 5 GB of internet egress per month, but beyond that, egress pricing varies by destination and network tier. A function serving a media API that returns 500 KB per response at 1 million calls per month generates roughly 500 GB of egress, well beyond the free allowance and potentially more expensive than the compute bill. Functions that call external APIs and return large JSON payloads face the same exposure.

Cloud Build and Artifact Registry costs appear every time you deploy a function. Cloud Build and Artifact Registry are billed separately from Cloud Run runtime charges. Frequent deployments in a CI/CD pipeline, say, 50 deployments per day across a team, can generate non-trivial Cloud Build minutes. Artifact Registry storage accumulates container images with each build. See the cloud deployment cost checklist for a structured approach to auditing these.

Log ingestion is charged by Cloud Logging once you exceed the free ingestion allowance. Functions that log verbosely, request bodies, full stack traces, debug output left in production, can generate gigabytes of log data per day at scale. This is one of the most common sources of unexpected charges on serverless bills.

Egress: model separately for any function returning payloads above ~10 KB
Build costs: audit CI/CD pipeline frequency and image retention policies
Logging: set log severity filters and sampling rates in production

Billing corner cases that show up on invoices

Several billing behaviours are technically documented but routinely missed until they appear on a bill.

Retries and failures count as invocations. Event-driven functions with automatic retries enabled will re-invoke on every failure. During an incident with sustained failures, retry storms can generate thousands of additional billable invocations within minutes. Tracking retry and fan-out multipliers is a standard part of cost modelling.

Cold starts add billed time. A cold start extends the execution duration, which increases GB-seconds and GHz-seconds billed. For functions with 100 ms rounding, a cold start that adds 80 ms of initialisation time effectively doubles the billed compute for that invocation.

Regional tier differences are silent. Deploying to a Tier 2 region without checking the pricing tier is a common oversight. The function works identically, but the per-unit compute cost is higher. There is no billing alert for this by default.

Free tier is per billing account, not per project. Teams running functions across multiple GCP projects under one billing account share a single free-tier pool. A project that appears to be "within the free tier" may actually be consuming allowance that another project already exhausted.

Rounding effects on sub-100 ms functions. Any function completing in under 100 ms is billed for a full 100 ms. At high invocation volumes, this is a material overcharge on compute. Batching small operations into fewer, slightly longer invocations can reduce total billed time.

Pro Tip: When an unexpected charge appears on a monthly bill, check three things first: the invocation count for retry spikes, the log ingestion volume for verbose logging, and the Cloud Build history for deployment frequency. These three sources account for the majority of surprise charges on serverless bills.

Billing corner cases that show up on invoices — overview diagram

Step-by-step worked calculations

The AgentCalc serverless cost estimator uses a clean three-step formula that mirrors how GCP calculates charges. Here it is applied to three realistic scenarios.

Formulas:

Billable requests = max(0, N − 2,000,000)
Total GB-seconds = N × (memory MB / 1,024) × (avg runtime ms / 1,000)
Billable GB-seconds = max(0, Total GB-seconds − 400,000)
Invocation cost = Billable requests × $0.0000004
Compute cost = Billable GB-seconds × $0.0000231 (Tier 1 GB-second rate)

Scenario A: short API call

N = 5,000,000 invocations/month; memory = 256 MB; avg runtime = 80 ms
Billable requests = 5,000,000 − 2,000,000 = 3,000,000
Invocation cost = 3,000,000 × $0.0000004 = $1.20
Total GB-seconds = 5,000,000 × 0.25 × 0.08 = 100,000
Billable GB-seconds = max(0, 100,000 − 400,000) = 0 (within free tier)
Compute cost = $0.00
Monthly total (compute + invocations, excluding egress/logs) = $1.20

Scenario B: medium processing job

N = 2,000,000 invocations/month; memory = 1,024 MB; avg runtime = 800 ms
Billable requests = 0 (within free tier)
Invocation cost = $0.00
Total GB-seconds = 2,000,000 × 1.0 × 0.8 = 1,600,000
Billable GB-seconds = 1,600,000 − 400,000 = 1,200,000
Compute cost = 1,200,000 × $0.0000231 = $27.72
Monthly total = $27.72

Scenario C: high-volume microservice

N = 20,000,000 invocations/month; memory = 512 MB; avg runtime = 200 ms
Billable requests = 18,000,000; invocation cost = 18,000,000 × $0.0000004 = $7.20
Total GB-seconds = 20,000,000 × 0.5 × 0.2 = 2,000,000
Billable GB-seconds = 2,000,000 − 400,000 = 1,600,000
Compute cost = 1,600,000 × $0.0000231 = $36.96
Monthly total = $44.16

Scenario	Invocations/month	Memory	Avg runtime	Invocation cost	Compute cost	Monthly total
A: short API	5,000,000	256 MB	80 ms	$1.20	$0.00	$1.20
B: processing job	2,000,000	1,024 MB	800 ms	$0.00	$27.72	$27.72
C: high-volume	20,000,000	512 MB	200 ms	$7.20	$36.96	$44.16

Sensitivity check: in Scenario C, halving average runtime from 200 ms to 100 ms cuts compute cost from $36.96 to $18.48. Reducing memory from 512 MB to 256 MB halves GB-seconds again.

Practical tactics to reduce invocation-driven costs

These are ordered by implementation effort and typical impact. Start with the quick wins.

Reduce average runtime. Profile p50 and p95 durations. Eliminate synchronous waits, unnecessary external calls, and redundant computation. Even shaving 50 ms off a 200 ms function cuts compute cost by 25% before any other change. Developer choices that drive cloud bills covers the most common runtime anti-patterns.
Cap verbose logging in production. Set minimum log severity to WARNING or ERROR for production functions. Debug and info logs at scale generate gigabytes of ingestion charges. Use structured logging with sampling for high-volume functions.
Batch small invocations. If a Pub/Sub topic triggers a function per message, consider batching messages before publishing. Fewer invocations with more work per call reduces both the per-invocation charge and the rounding tax on short functions.
Cache responses where possible. Functions that repeatedly fetch the same data from a database or external API can cache results in memory (for warm instances) or in Cloud Memorystore. Fewer downstream calls means lower egress and shorter runtimes. The cache strategy guide covers the trade-offs.
Right-size memory allocation. Allocating 2,048 MB to a function that uses 300 MB wastes money on both GB-seconds and GHz-seconds. Profile actual memory usage under load and set allocation to peak usage plus a 20% headroom.
Disable automatic retries for non-idempotent functions. If a function is not idempotent, automatic retries on failure can double or triple invocation counts during incidents. Disable retries and handle failures explicitly.
Move sustained workloads off functions. Functions are cost-effective for spiky, short-duration work. A function that runs continuously at high concurrency is often cheaper on Cloud Run with minimum instances, or on a small GKE node pool. Application refactoring for cloud savings gives a framework for making that call.

Pro Tip: Measure fan-out before optimising invocation count. Fix the fan-out multiplier first.

Pro Tip: Sample p95 runtime separately from p50. The tail is where the money goes.

When does Cloud Run cost less than first-gen functions?

The choice between first-gen Cloud Functions and second-gen (Cloud Run-backed) functions is not purely architectural. It has direct cost implications depending on your workload shape.

First-gen functions suit:

Spiky, short-duration workloads that benefit from the invocation free tier
Functions with runtimes under 500 ms where per-100 ms billing is the primary cost driver
Low-to-medium volume workloads where the free compute allowances cover most usage

Cloud Run (second-gen) suits:

Functions with sustained concurrency, where a single instance handles multiple requests simultaneously, reducing per-request compute cost
Workloads requiring more than 8 GB memory or specific CPU configurations not available in first-gen
Long-running jobs (minutes rather than seconds) where Cloud Run's 60-minute timeout and CPU-always-on option provide more control
Scenarios where you need to minimise cold starts via minimum instances, and the cost of idle instances is offset by reduced cold-start compute

The key cost trade-off: Cloud Run with minimum instances set above zero incurs idle instance charges even when no requests arrive. For a function that receives 10 requests per day, minimum instances are expensive. For a function handling 1,000 requests per minute, minimum instances eliminate cold-start billed time and may reduce total compute cost. The software design choices that drive cloud costs article covers the architectural patterns that determine which model fits.

Koritsu's methodology for modelling function costs

Accurate cost modelling requires instrumentation, not estimation. Here is the checklist Koritsu AI uses when auditing serverless spend for engineering teams.

Instrument invocation counts by function and trigger type. Separate HTTP-triggered from event-driven invocations. Event-driven functions with retries enabled need a retry rate tracked separately.
Capture p50 and p95 runtime from Cloud Monitoring. Do not rely on average duration. The p95 tail, especially during incidents or under load, is where unexpected charges originate.
Measure fan-out and retry multipliers. For every upstream event, count how many downstream function invocations it generates. A fan-out ratio above 3× means upstream volume reduction has limited impact on total invocation cost.
Sample payload and egress sizes. For functions returning data to clients or calling external APIs, measure response sizes at p50 and p95. Multiply by invocation volume to project monthly egress.
Measure log bytes per invocation. Pull log ingestion metrics from Cloud Monitoring. Functions logging more than 1 KB per invocation at high volume generate significant Cloud Logging charges.
Correlate cost spikes with deployments and incidents. When costs rise unexpectedly, check Cloud Build history for deployment frequency, and check Cloud Monitoring for retry rate spikes coinciding with the cost increase.

When costs rise suddenly, the debugging sequence is: check invocation count first (retry storm?), then p95 runtime (cold start regression?), then log ingestion volume (new verbose logging?), then Cloud Build history (deployment spike?). Most surprise charges trace back to one of these four sources.

Koritsu AI applies this methodology as part of its free cloud cost assessment, surfacing the specific functions and patterns driving unnecessary spend. The common cloud API cost mistakes guide documents the anti-patterns we find most frequently.

Where teams should focus first

Most engineering teams approach serverless cost optimisation in the wrong order. They reach for architectural changes, refactoring, migrating to Cloud Run, adding caching layers, before fixing the low-effort, high-impact issues sitting right in front of them.

In practice, logging and retries are the two fastest wins. Verbose logging left over from development is almost always present in production functions, and it costs real money at scale. Disabling automatic retries on non-idempotent functions, or adding proper deduplication, eliminates a category of cost that compounds during every incident.

Prioritisation rules of thumb for engineering teams:

Fix logging verbosity before touching architecture
Audit retry configuration before profiling runtime
Measure fan-out before reducing upstream invocation rate
Right-size memory before considering provisioned instances
Move workloads off functions only after exhausting runtime and memory tuning

The temptation to over-engineer the solution is real. A 30-minute logging audit and a retry configuration review will often deliver more savings than a week of architectural refactoring. Start there.

How Koritsu AI helps you reduce serverless spend

Most teams running Google Cloud Functions are paying more than they need to. The charges are real, but the causes are usually fixable without a major rewrite.

Koritsu AI combines a continuous cost monitoring platform with hands-on FinOps expertise. Kori, our AI agent, surfaces exactly which functions are driving spend and why, whether that is retry storms, cold-start overhead, verbose logging, or egress from oversized payloads. We start with a free assessment, and we only charge when we find savings you can act on. For a concrete example of what that looks like in practice, see the UK bidding platform case study, where we delivered a 52% reduction in cloud costs. If your serverless bill is growing faster than your traffic, that is the right place to start.

Sources

The figures and formulas in this article are drawn from the following primary references. Verify current rates and region-specific pricing directly with these sources before committing to cost models.