Google Cloud Run Functions Pricing 2026: Full Cost Breakdown (Formerly Cloud Functions)

Google Cloud Run functions can be extremely cheap at low traffic — often free — but the pricing gets complicated fast once you start accounting for CPU, memory, requests, networking, billing mode, and the difference between 1st-gen and current-generation functions.

This guide breaks down how Cloud Run functions pricing works in 2026, including the free tier, current per-unit rates, common sources of surprise costs, and worked examples at different traffic levels. It also covers when serverless starts losing its cost advantage and which settings have the biggest impact on your bill.

Cloud Run Functions Pricing at a Glance (2026)

In August 2024, Google folded Cloud Functions into the Cloud Run platform and renamed it Cloud Run functions. That change didn't erase the old pricing model — it just means “Cloud Run functions pricing” can refer to two different rate cards depending on which generation you're running. Here's the shape of both before we get into the line-item detail.

*Free tier shown is for request-based billing in us-central1; both the free tier and the per-unit rates vary by region and billing mode.

The short version: the current generation prices CPU and memory independently and lets multiple requests share a single instance, which is usually cheaper at real traffic volumes than the older generation's fixed CPU-to-memory ratio and one-request-per-instance model.  

Cloud Functions, Cloud Run Functions, Cloud Run Services: What Changed?

The rename and what it means for existing functions

Google announced the change on its Cloud blog in August 2024: Cloud Functions (1st gen) became Cloud Run functions (1st gen), and Cloud Functions (2nd gen) became simply Cloud Run functions — the “2nd gen” label was retired along with the name, since it's now the only forward-looking version. This was more than a rebrand. Google merged the Cloud Functions infrastructure into Cloud Run itself, and any function built on the v2 API was automatically converted to run natively on Cloud Run.

If you already had 2nd-gen functions deployed, nothing broke: existing APIs, gcloud commands, and Terraform modules kept working without a redeploy. What did change is that those functions picked up Cloud Run capabilities they didn't have before, including:

• NVIDIA GPU support (L4, and RTX PRO 6000 in preview) for AI inference workloads
• Direct VPC egress for lower-latency networking
• Mounting Cloud Storage volumes directly
• Multi-event trigger management
• Managed Prometheus and OpenTelemetry support via sidecar containers

Functions still on 1st gen didn't get any of this — they kept their original infrastructure and pricing model, which is why the two generations now need to be priced separately.

1st gen vs 2nd gen pricing differences

The two generations don't just have different rates — they meter usage in different units entirely. 1st gen bills in GB-seconds and GHz-seconds, with a fixed CPU-to-memory ratio and one request per instance. Current-gen functions bill in vCPU-seconds and GiB-seconds, size CPU and memory independently, and support concurrency. Here's the full rate comparison:

*Idle refers to billable time for instances kept warm using a minimum-instances setting.

The practical impact: because current-gen functions can pack multiple concurrent requests onto a single billed instance, they're usually cheaper than 1st gen at real traffic volumes, even before accounting for the free-tier differences covered above. Both generations still store their container images through Cloud Build and Artifact Registry, which bill separately and can add small charges even when you're inside the compute free tier.

Cloud Run functions vs Cloud Run services — when each applies

Once a function is on the current generation, it's billed under the exact same Cloud Run rate card as a full Cloud Run service. That means price isn't what decides which one to use — the deployment model is:

As a rule of thumb: reach for a function for lightweight, event-driven glue code — webhook handlers, file-triggered processing, small API endpoints. Move to a full Cloud Run service once you need a custom runtime or base image, more than one process in a container, or a workload that doesn't fit neatly into a single request/response or event handler.

How You Are Actually Billed

CPU and memory (per vCPU-second and GB-second)

Current-generation Cloud Run functions actually come with a choice most people don't realize they're making: request-based billing or instance-based billing. The rate you pay for CPU and memory depends on which one your service is using.

Request-based billing only charges the active rate while your instance is handling a request (plus a lower idle rate if you've set minimum instances); instance-based billing charges the flat rate for an instance's entire lifetime, whether or not it's doing anything, and doesn't add a separate per-request fee on top. Most functions — short, bursty, triggered by an event — are cheaper on request-based billing, which is also the default. Instance-based billing tends to win out for services that are busy close to 100% of the time, where the lower flat rate outweighs not having idle periods to avoid paying for. 1st gen doesn't offer this choice at all; it only has the flat GB-second/GHz-second model already covered in the previous section.

Requests and invocations

On request-based billing, requests are metered separately from compute: $0.40 per million beyond the 2 million free per month, whether the request came in over HTTP or was forwarded by Eventarc. Only requests that reach your container after successfully authenticating are billed — anything IAM denies before it gets there is free. On instance-based billing, there's no separate request charge at all; you're already paying for the instance's full uptime.

1st gen invocations work on the same headline rate — $0.40 per million beyond 2 million free — but with none of the nuance: every invocation is charged at a flat rate regardless of source (HTTP, background/CloudEvent triggers, or the call API), and regardless of whether the function succeeds, fails, or times out.

Networking egress

Inbound data is always free, and so is outbound traffic to other Google APIs in the same region. Beyond that, the two generations handle egress very differently. Current-generation functions use the Premium Network Service Tier by default, with 1 GiB of free outbound data transfer per month, but only within North America; anything beyond that free tier, or destined elsewhere, bills at standard Google Cloud networking rates, which vary by destination. Traffic sent to a VPC is billed separately as data transfer from a VM at VPC rates, and a Serverless VPC Access connector adds its own compute charge on top.

1st gen egress is simpler and less generous per-GB but has a bigger free allowance: 5 GiB free per month, flat rate, to any destination, then $0.12/GB beyond that — no Premium/Standard tier distinction to think about. One regional quirk: 1st-gen functions deployed from Australia incur an additional charge for the source code egress that happens during deployment itself, billed at standard network egress rates.

Container image storage in Artifact Registry

Every function or service you deploy from source gets built into a container by Cloud Build and stored in Artifact Registry — Container Registry is no longer an option; Google shut it down completely on March 18, 2025. Both of these are billed separately from Cloud Run itself, and neither has anything to do with your compute free tier:

In practice this shows up as a small, easy-to-miss line item: a team that redeploys often, or keeps several old image versions around, can accumulate Artifact Registry storage charges and Cloud Build minutes well before their actual Cloud Run functions usage costs anything at all.

Billing granularity and rounding

Both generations round compute time up to the nearest 100 milliseconds — a function that runs for 260ms is billed as 300ms. For request-based billing, billable instance time starts with the first request an instance picks up and ends when the last one finishes (plus any time spent starting up or gracefully shutting down); if you've set minimum instances, the idle rate applies outside of that window. Instance-based billing, by contrast, charges for the instance's entire lifetime from start to termination, with a 1-minute minimum — the same rule Cloud Run jobs use, since jobs are always billed at the instance-based rate.

The Free Tier and What It Really Covers

Monthly allowances for invocations, compute and egress

Between the two function generations and the two services that quietly sit underneath every deployment, there are four separate free tiers to keep straight:

How the free tier applies across projects

None of these allowances are per project or per function — they're pooled at the billing account level. Every function, service, Cloud Build job, and Artifact Registry repository tied to the same billing account draws from the same shared monthly allowance, and it resets on a calendar-month basis. For current-generation functions, the free tier is applied as a spending-based discount calculated at Tier 1 pricing; you get the same dollar-equivalent allowance no matter which regions you actually run in, but how much of that allowance a given month's usage consumes depends on whether it ran in a Tier 1 or Tier 2 region.

Cloud Build and Artifact Registry work the same way: their free tiers are also aggregated across every project attached to the billing account, not granted separately to each one.

Where teams accidentally fall out of it

• Running several low-traffic functions under one billing account: each one looks trivial alone, but they're all drawing from the same pooled allowance, so together they can exceed it faster than expected.
• Egress-heavy workloads: the current-generation networking allowance is a comparatively small 1 GiB, and only covers Premium Tier traffic within North America — anything outside that region or tier isn't covered at all.
• Frequent redeploys: every deployment consumes Cloud Build minutes and adds to Artifact Registry storage, both billed independently of whether your Cloud Run functions usage itself is still free.
• Minimum instances or instance-based billing: idle time and full-lifetime instance billing aren't part of the request-based free tier, so turning either on can introduce charges a team wasn't expecting.
• Mixing generations: 1st gen and current-gen functions each draw from their own separate free tier — running both doesn't combine or double the allowance.

Why Is Cloud Run So Expensive?

Cloud Run functions and Cloud Run get a reputation for surprise bills, but the pattern behind most of them isn't a pricing trick — it's a handful of settings that trade cost for convenience, left on by default or copied from service to service without being revisited. Check out our Cloud Run Optimization guide for the full list of tips.

Minimum instances kept warm around the clock

Setting a minimum instance count keeps that many instances running at all times, even with zero traffic, so the next request never hits a cold start. On request-based billing, those idle instances are billed at the lower idle rate rather than the active rate — but idle isn't free. A single 1 vCPU / 512 MiB instance kept warm around the clock for a 30-day month runs about $9.72 at the idle rate alone (2,592,000 seconds × $0.0000025/vCPU-second, plus 2,592,000 × 0.5 GiB × $0.0000025/GiB-second), before the free tier, request charges, or regional pricing are factored in.

That's a small number for one instance. The problem is that minimum instances are set per revision, and teams tend to apply the same “just in case” setting across an entire fleet of low-traffic functions, and across every environment — staging, per-branch previews, every region — that got cloned from a template. What looks like a one-time convenience decision quietly becomes a recurring line item that scales with however many places it was copied to, not with how much traffic any of them actually see.

CPU always-allocated vs. CPU allocated only during requests

This is the same request-based vs. instance-based billing choice covered earlier, under an older name Google's own docs and CLI output still use in places:

The mistake is leaving CPU always allocated (instance-based billing) switched on for a service that no longer needs it. It's the right call when a service genuinely does background work between requests — connection pooling, cache warming, a background thread pulling off a queue — but once it's on, it charges the flat rate for the instance's entire lifecycle, not just the moments it's actually busy. Google's Recommender can flag services where observed traffic suggests request-based billing would now be cheaper, which is worth checking on anything switched to always-allocated a while ago and never revisited.

Concurrency set too low, so more instances spin up than needed

Concurrency controls how many requests a single instance can process at the same time. Services created in the console default to 80; those created via the CLI or Terraform default to 80 times the number of configured vCPUs, up to a maximum of 1,000. Set it to 1, and every instance handles exactly one request at a time — the simplest model, and also the most expensive one, since Cloud Run has to spin up a separate billed instance for every concurrent request instead of packing many requests onto compute that's already running.

Concurrency of 1 is sometimes the right call — CPU-intensive or non-thread-safe applications genuinely can't share an instance safely. But it's just as often left at 1, or at whatever default the CLI assigned, simply because nobody went back and tested whether the application could safely handle more than one request per instance. Raising it, where the workload allows it, is one of the more direct levers for cutting the number of billed instances without changing anything else about the service.

Over-provisioned memory on short-running functions

Because current-generation billing charges per GiB-second and per vCPU-second rather than a flat per-invocation fee, oversized memory and CPU allocations inflate the bill directly and proportionally — a function that finishes in 200ms but is provisioned with 4 GiB of memory “just in case” pays for 4 GiB for that entire 200ms, whether it ever uses a fraction of that memory or not.

1st gen didn't give you this rope to hang yourself with, in a sense: memory tier and CPU speed are locked together, so choosing more memory automatically bought more CPU whether the workload needed it or not, and over-provisioning was baked into the tier choice itself. Current-generation functions let you size CPU and memory independently, which makes it possible to right-size precisely — but only if someone actually goes back and tunes the defaults down to match real usage, instead of leaving whatever was set at first deploy, often copied from a template or a heavier service.

Cold-start mitigation that quietly costs more than the cold starts

The instinct when cold starts show up in latency metrics is to reach for minimum instances, which eliminates them entirely by keeping instances warm around the clock — at the ongoing idle cost covered above. There's a narrower, usually cheaper fix for the same complaint: startup CPU boost, which temporarily allocates roughly double the configured CPU only during the container's startup window, then drops back to normal for the rest of the instance's life. Because the extra charge only applies for those few seconds of startup, it's a fraction of what keeping an instance warm 24/7 costs, and it addresses the slow-initialization problem that's actually behind a lot of cold-start complaints — JVM warmup, large dependency imports, connection pool setup.

The costly pattern is reaching straight for minimum instances the moment cold starts come up, without first trying startup CPU boost or a higher concurrency setting, and ending up paying continuously to solve a problem that a few extra vCPU-seconds at startup would have handled for pennies.

Egress and dependent-service charges people forget to count

A meaningful share of “Cloud Run” spend never shows up as a Cloud Run line item at all. Cloud Build minutes and Artifact Registry storage accrue on every deployment, as covered earlier. Eventarc's own event-delivery fee is $0 per million events for standard sources, but the Pub/Sub transport layer underneath every event trigger isn't free past its first 10 GiB of data per month — and for high-volume or large-payload event sources, that Pub/Sub data volume, not Eventarc itself, is usually the real cost driver. Audit-log-based triggers add Cloud Logging ingestion charges on top of that. And any egress beyond the free tier, or traffic routed to a VPC — billed as data transfer from a VM, plus the Serverless VPC Access connector's own compute cost — shows up as its own separate item.

The practical upshot: when a serverless bill runs higher than the Cloud Run rate card alone would suggest, the gap is usually sitting in one of these adjacent services, not in a miscalculation of vCPU-seconds or GiB-seconds.

Worked Pricing Examples

All three examples use current-generation, request-based billing at Tier 1 (us-central1) rates, with no minimum instances.

A low-traffic webhook

500,000 requests/month, averaging 200ms each on 0.25 vCPU / 256 MiB.

This workload never leaves the free tier — compute, memory, and requests all land comfortably under the monthly allowance.

A medium-volume API

20 million requests/month, averaging 300ms each on 1 vCPU / 512 MiB.

Compute time, not request volume, drives most of this bill.

A high-throughput event pipeline

200 million invocations/month, averaging 100ms each on 0.5 vCPU / 256 MiB.

At this volume the per-request fee starts to matter more: request charges here are over 10x the medium-volume example, even though compute only roughly doubled, because request count grew tenfold while compute per request shrank.

These are simplified estimates — they assume no minimum instances, idle time, or concurrency-driven sharing across instances, and actual bills vary by region. Google's own Pricing Calculator is the best way to model a specific workload precisely.

When Serverless Stops Being the Cheap Option

The request-volume crossover vs. Cloud Run services, GKE, and Compute Engine

There's a natural ladder above a pure, scale-to-zero Cloud Run function: a Cloud Run service with minimum instances or instance-based billing (paying for idle time so requests never queue), GKE Autopilot (per-pod billing plus a $0.10-per-hour, per-cluster management fee — waived for a billing account's first cluster via a $74.40/month credit), and finally a standing Compute Engine VM or GKE Standard node pool, where you pay a flat rate no matter how busy it is.

The crossover point against that last option is a straightforward calculation. Take a function running 1 vCPU / 512 MiB at 200ms per request: compute plus the per-request fee works out to about $0.00000545 per request at Tier 1 rates. An always-on e2-standard-2 VM (2 vCPU / 8 GiB) runs $0.06701142/hour, or about $48.92/month, in us-central1. Dividing one into the other puts the crossover at roughly 9 million requests a month — past that point, on this resource profile, a single persistent VM running the same workload continuously would cost less than paying per request.

Sustained load vs. spiky traffic

That crossover point isn't fixed — it depends entirely on how evenly the traffic is spread out. A standing VM or GKE node pool charges the same flat rate whether it's saturated or sitting idle, while Cloud Run functions only charge for compute actually used. Traffic that's genuinely bursty, with real idle periods between spikes, keeps serverless cheaper well past the volume where the raw math above would suggest switching. Traffic that's closer to a constant, 24/7 hum pushes the crossover the other way, sometimes arriving at a fraction of that request count.

The simplest gut check: at this traffic level, would a persistent server sit mostly idle, or mostly busy? Mostly idle favors staying serverless regardless of total request count; mostly busy favors owning the capacity outright.

How to model the switch before you hit it

Pull actual request volume, average duration, and the resource profile from monitoring, then run that through Google's Pricing Calculator against both the current serverless configuration and an equivalent VM or GKE Autopilot setup — remembering GKE's $0.10-per-hour cluster management fee (waived for a billing account's first cluster) on top of per-pod or per-node compute. nOps' GKE cost optimization guide covers right-sizing node pools and Autopilot pod requests once a workload has actually made the move.

How to Reduce Cloud Run Functions Costs

Right-size memory and CPU to actual execution profiles

Pull actual utilization from Cloud Monitoring before touching any settings — the container/cpu/utilizations and container/memory/utilizations metrics report per-instance usage as a percentage of what's currently allocated. Set memory and CPU to match observed peak usage (a p95 over a representative traffic window is a reasonable baseline) plus a safety margin of 20–30%, rather than leaving whatever was set at first deploy or copied from a heavier service.

Because current-generation functions size CPU and memory independently, this can be tuned one dimension at a time — a function that's CPU-light but memory-heavy, or vice versa, doesn't have to carry excess of the other the way it would under 1st gen's fixed ratio. Re-check after any dependency or runtime change, since memory footprint shifts as code changes even when traffic doesn't.

Tune concurrency before adding instances

Before raising max instances or reaching for minimum instances to handle more load, raise concurrency first, if the application can safely share an instance across simultaneous requests — no unsafe shared mutable state, and request handling that's thread-safe or properly async. Load-test at a few candidate settings (say, 10, 40, and 80) to find where latency or error rate actually starts to degrade, then set concurrency just below that ceiling instead of defaulting to 1 or leaving whatever the CLI assigned.

Higher concurrency directly cuts the number of billed instances needed to serve the same request volume, and compounds with right-sized memory and CPU: an instance that's both correctly sized and handling more requests at once does more work per vCPU-second and GiB-second billed.

Review minimum-instance settings

Set minimum instances to cover only the baseline traffic floor — the request rate that's present nearly all the time — and let autoscaling handle everything above it. Pull actual request-per-hour patterns from Cloud Monitoring to find that floor rather than guessing, and revisit the setting on a regular cadence, since a minimum-instance count set to survive a launch-day traffic spike routinely outlives the spike that justified it.

Non-production environments are worth a specific check: staging, per-branch previews, and dev copies of a service rarely need any minimum instances at all, and a production setting copied wholesale into those environments is one of the more common places this cost hides in plain sight.

Reduce execution time and cold-start overhead

Because the bill is duration multiplied by resources, cutting actual execution time reduces cost directly, not just latency. Lazy-load expensive dependencies and connections so a request path only initializes what it actually needs, trim unused dependencies out of the container image, and use a minimal base image that starts faster. Keep request handling asynchronous where the runtime supports it, so billed instance time ends as soon as the work is actually done rather than blocking on synchronous I/O.

Reach for startup CPU boost before minimum instances when the actual goal is faster initialization — it charges only for the brief startup window at roughly double the configured CPU, which is a fraction of paying the idle rate around the clock for the same result.

Clean up unused functions and old container images

Set Artifact Registry cleanup policies on every repository behind a Cloud Run functions deployment: a delete policy (for example, remove images older than 30 days) paired with a keep policy (retain the 5 most recent versions) removes stale build artifacts automatically instead of letting them accumulate storage charges indefinitely. Google's own guidance on Artifact Registry cleanup policies and the GCP orphaned-resources checklist both cover the setup in more depth.

Periodically audit for functions and services that were deployed for a one-off test, a deprecated feature, or an abandoned branch and never torn down. These keep accruing minimum-instance and image-storage charges long after anyone's using them, and they're easy to miss precisely because they don't surface in day-to-day monitoring unless someone goes looking for them.

Tracking Serverless Spend Across Your GCP Bill

Everything covered above assumes you can actually see where the spend is coming from, which is the part that trips up most teams — a single “Cloud Run” or “Cloud Functions” line on the bill rolls every deployed function and service into one number by default.

• Per-service and per-function cost attribution — getting spend broken out by individual function or service means either labeling resources consistently and filtering the billing export by label, or using a tool that maps cost to services automatically instead of digging through billing export tables by hand.
• Spotting runaway invocation counts before month-end — $0.40 per million requests is small per unit but scales linearly, so a retry storm or an accidentally public endpoint getting hit by a crawler can run up request charges fast; near-real-time alerting on invocation counts or spend anomalies catches that while it's happening, rather than at invoice time.
• Serverless spend in the same view as compute, storage, and network — Cloud Build, Artifact Registry, Eventarc's Pub/Sub transport, and egress all bill separately from Cloud Run itself, so understanding the true cost of a serverless workload means viewing all of them together, not just the Cloud Run or Cloud Run functions SKU in isolation.

Understanding the pricing model is only half the job. Cloud Run functions costs can also show up across Cloud Build, Artifact Registry, networking, and event-driven services, which makes it harder to see the true cost of a workload in one place.

nOps gives teams unified visibility across AWS, GCP, Azure, AI, and SaaS spend, with cost allocation by application, customer, team, or business unit. That makes it easier to see what’s driving serverless spend, catch unusual cost changes, and understand Cloud Run costs alongside the rest of your cloud environment.

If you want to see where you could reduce cloud spend, nOps offers a free savings analysis.

nOps manages $5B+ in cloud spend and was recently rated #1 in G2's Cloud Cost Management category.

FAQ