Cloud Functions pricing (GCP): invocations, duration, egress, and log volume

The best Cloud Functions estimate is "unit economics": per-invocation drivers multiplied by monthly volume. Keep compute, transfer, and logs as separate lines so you can see what actually dominates as traffic grows.

0) Identify what triggers invocations (choose the right driver)

HTTP: driver is requests/month.
Event-driven: driver is events/messages/month (Pub/Sub, storage events).
Scheduler: driver is runs/day (plus any fan-out).
Fan-out: one trigger may create N downstream invocations (hidden multiplier).

Tool: RPS to monthly requests (for rate-based drivers).

1) Invocations (per month)

Convert your driver into monthly invocations. Keep baseline and peak periods separate (batch jobs, incidents, marketing spikes).

Include retries: a retry rate of 50% increases invocations by 1.5×.
Include background traffic: health checks, bots, cron pings.

2) Duration (the compute multiplier)

Duration turns invocations into compute. Model at least two percentiles (p50 and p95) to capture slow-path behavior. Slow paths are usually caused by upstream latency (DB/APIs), cold starts, and throttling.

Track dependency time: external calls dominate duration for many functions.
Keep a peak scenario: incidents increase duration and retries at the same time.

3) Outbound transfer (egress can dominate)

Outbound transfer becomes material when functions return large payloads or call external APIs. Estimate response size separately from compute so you can see what is driving the bill.

Tools: Response transfer, Egress.

Split destinations: same-region vs cross-region vs internet have different billing behavior.
If one endpoint returns large payloads, model it separately (heavy tail).

4) Logs (ingestion + retention + scan)

Logging scales with volume. If each invocation logs a few KB and you have millions of invocations, log ingestion can exceed compute. Model ingestion and retention explicitly.

Tools: Log ingestion, Tiered log storage, Scan/search.

Worked estimate template (copy/paste)

Invocations/month = baseline + peak (include retries and fan-out)
Duration = p50 + p95 scenario (seconds)
Egress GB/month = invocations/month × avg response size (GB) + external API egress
Log GB/month = invocations/month × avg log bytes/invocation (sample real payloads)

Common pitfalls

Ignoring retries/timeouts (multipliers on invocations, duration, and transfer).
Using one average duration instead of modeling the slow path (p95 matters).
Returning large payloads without modeling egress separately.
Verbose logs per invocation (log ingestion dominates at scale).
Not separating baseline vs peak months (incidents create a different cost profile).

How to validate

Measure invocations and duration over a representative window (baseline + peak).
Validate retry rates and timeout behavior during incident windows.
Sample real log payload size and multiply by invocation volume.
Validate response sizes/top endpoints by bytes (avoid blended averages).