Google Cloud Functions is now Cloud Run functions: what it is, and what it really costs

In April 2026, a Google Cloud customer went to bed with a $7 billing budget and a $1,400 spending cap. They woke up owing Google more than $18,000.

The culprit was mundane: an API key accidentally left in a published project. An attacker found it and fired off 60,000+ requests, and the serverless machinery did exactly what it’s designed to do. It scaled. The budget sent alerts. The cap did not cap. As Tom’s Hardware put it in its coverage, the safety measures were all turned off by default.

That one night is the whole thesis of serverless: Google Cloud Functions and its siblings are genuinely brilliant infrastructure that meters everything, hides nothing on purpose, and shows you the receipt later. A GCP budget is a notification, not a brake. And per-request billing scales your mistakes, and your attackers, exactly as efficiently as it scales your product.

This guide covers what the product is, why it has a new name, exactly how the pricing works, and how AI just raised the stakes on all of it.

What is Google Cloud Functions?

Google Cloud Functions is Google’s serverless compute product for running event-driven code without managing servers. You write a function, connect it to a trigger (an HTTP request, a file landing in a storage bucket, a Pub/Sub message), and Google handles provisioning, scaling, and patching. You pay only when the function runs.

First things first, because the live search results are genuinely confusing: Cloud Run functions is the current name. Google renamed Cloud Functions in August 2024 and made it part of the Cloud Run platform. If you searched “google cloud functions” and landed on pages about Cloud Run, nothing is broken. Same product, new home, and the move was more than a rebrand, as we’ll get to.

Think of it as GCP’s answer to AWS Lambda. In fact, “GCP’s Lambda equivalent” is exactly how most AWS-fluent engineers first meet it. The mental model transfers cleanly: small units of code, triggered by events, billed by consumption, scaled by someone else’s robots.

GCP cloud functions shine at the connective tissue of a system: resizing images on upload, processing webhook payloads, syncing databases, firing notifications, gluing SaaS tools together. The event-driven pattern is the same economics we covered in EventBridge pricing on the AWS side: individually tiny charges that only become visible in aggregate.

Which raises the obvious question: if the product works fine, why did Google rename it?

What changed when Cloud Functions became Cloud Run functions?

In August 2024, Google announced that Cloud Functions was becoming Cloud Run functions. The short version: second-generation functions were already running on Cloud Run infrastructure under the hood, and Google decided to stop pretending otherwise.

The practical changes matter more than the name:

So the name tells you where the money goes. Which means understanding google cloud functions pricing now means understanding Cloud Run’s meter.

How does Google Cloud Functions pricing work?

Cloud Run functions pricing has three main dials, plus networking. All figures below are Tier 1 region rates for request-based billing, verified against Google’s Cloud Run pricing page; reverify before you commit, because rates vary by region and billing mode:

First-gen functions price differently: $0.40 per million invocations after the first 2 million free, plus compute measured in GHz-seconds and GB-seconds billed in 100ms increments, plus egress. If you’re still on 1st gen, Google’s dedicated 1st gen pricing page is your source of truth.

Three fine-print items that separate the calm bills from the postmortem-blog bills. Deploys cost money even inside the free tier, because deploying builds a container through Cloud Build and stores it in Artifact Registry. Charges accrue whether the function succeeds or fails, so a retry storm bills like a feature launch. And the free tier aggregates across your whole billing account, not per function, so twenty small services share one allowance.

And the big one, worth repeating because it decides incidents: a GCP budget notifies, it does not cap. Spend control on cloud functions cost is architecture and configuration (max instances, concurrency, timeouts), not a settings toggle. We go deeper on how GCP billing data actually flows in our GCP billing guide.

The next decision every GCP team hits is choosing between the two shapes on the platform.

Cloud Run functions vs Cloud Run services: which do you need?

Since the merge, cloud run vs cloud functions is less “which product” and more “which shape of the same product.” The honest decision table:

The cost nuance worth a highlight: concurrency is a pricing feature disguised as a performance feature. One Cloud Run instance handling 80 requests simultaneously bills one set of vCPU-seconds, not 80. It’s the serverless version of the horizontal versus vertical scaling trade-off. Just remember the dial turns both ways: pair high concurrency with runaway max instances and you’ve built a bill multiplier.

For full cloud run pricing beyond functions, the same vCPU-second and GiB-second meters apply, with committed use discounts once your baseline is predictable. Total Cloud Run cost also picks up adjacent line items worth watching: Artifact Registry storage, minimum-instance idle time if you disable scale to zero, and VPC connectors.

Our Google VPS pricing guide covers the always-on side of that comparison.

Of course, most teams aren’t choosing between GCP shapes in a vacuum. They’re comparing cloud service providers wholesale, and plenty run more than one cloud at once.

How does it compare to AWS Lambda and Azure Functions?

The google cloud functions vs aws lambda question is the highest-volume comparison in this cluster, and the three platforms rhyme while metering differently. The differences compound at volume:

Two honest takeaways, whether you frame it as Cloud Functions vs Lambda or the full three-way. At hobby scale, this comparison barely matters: around 100,000 requests a month, all three platforms typically land in free-tier territory. At production scale, the metering model is the architecture decision: Lambda’s bundled GB-seconds are simpler to predict, Google’s separate CPU and memory dials are cheaper to tune, and Lambda’s API Gateway line item surprises teams who priced only the function.

The full platform picture, beyond serverless, lives in our AWS vs GCP comparison, and if you’re weighing Google Cloud Functions alternatives wholesale, from Lambda to smaller platforms, our Google Cloud alternatives guide covers the field.

That GPU row in the table is not a typo, and it’s where this product’s story just changed completely.

How is AI changing Google Cloud Functions?

For its first decade, serverless meant small, CPU-bound, stateless functions. Then AI workloads arrived, and Google made Cloud Run the serverless front door for them.

The receipts, all from Google’s own announcements: NVIDIA L4 GPU support came to Cloud Run in August 2024 for real-time inference on open models like Gemma and Llama.

By February 2026, Google added NVIDIA RTX PRO 6000 Blackwell GPUs (in preview), which means you can serve 70B+ parameter models with scale-to-zero and no cluster management.

At Next ’26, Google reported more new customers and apps came to Cloud Run in 2025 than in its first six years combined, and paired Cloud Run with the Gemini Enterprise Agent Platform and a fully managed remote MCP server for deploying AI agents.

Translated out of launch-blog dialect: the thing you knew as a webhook runner is now Google’s preferred way to ship AI inference and agents without touching Kubernetes. That changes the workloads, and the workloads change the bills.

As noted by one of CloudZero’s engineers, “Serverless was never cheap or expensive. It’s precise. AI just raised the stakes.”

Which brings us to the question that decides whether serverless saves you money or just itemizes your regret.

What does serverless actually cost at scale?

Run the worked example, because the free tier distorts intuition. Take a function with 1 vCPU, 256 MiB of memory, and a 200ms average runtime, in a Tier 1 region on request-based billing (illustrative math; check Google cloud pricing calculator for your shape):

Read that again: 100x the traffic, roughly 1,000x the bill. Not because Google cheats, but because the free tier absorbs your first workload almost entirely and then never grows.

Serverless bills are convex, and every scaling story lives somewhere on that curve. The trap isn’t the rates, which are perfectly public. The trap is that per-invocation pricing turns cost into a high-frequency data stream while most companies still review spend monthly.

April’s $18,000 customer met that gap as a headline. Most teams meet it as a quieter version: the retry storm nobody noticed for a week, the agent loop that tripled invocations, the leaked key, the dev project with production-grade defaults.

GCP bill-shock postmortems are practically a literary genre at this point, and every entry shares one plot: the meter knew immediately, the humans found out later. In CloudZero’s 2026 AI ROI survey of 260 finance leaders, 30% said they still reconcile spend manually. Against infrastructure that bills by the tenth of a second and by the million, a spreadsheet is a rearview mirror on a highway.

The defensive playbook is real and worth running: set max instances deliberately, cap concurrency to what your downstream services survive, budget alerts everywhere despite their lag, and revisit the broader GCP cost optimization levers regularly. Serverless design patterns for cost efficiency deserve their own read. But configuration limits blast radius; it doesn’t create visibility. For that, you need to see the meters move.

How CloudZero brings Cloud Run functions spend into focus

Everything above lands on one problem: Cloud Run functions generate cost data faster and finer than humans review it. Millions of invocations, vCPU-seconds, GPU-seconds, and token calls, and a CFO who asks a question none of those units answer: what did this feature cost us, and what did it return?

That translation is what CloudZero’s GCP integration does. CloudZero ingests your Google Cloud spend and attributes every dollar, Cloud Run functions to Vertex AI to Gemini API calls, to the team, product, customer, or feature behind it. Labels are optional, which matters because serverless resources are exactly the ones nobody labels consistently. CostFormation handles the mapping logic, so shared projects and multi-team billing accounts get split fairly instead of dumped into “unallocated.”

The leaked-key, runaway-loop failure mode gets a specific answer: anomaly detection watches every GCP service, including AI workloads, and alerts the responsible engineers through Slack, email, or Jira with hour-level context, not day-late billing exports. The bill stops being where you find out.

And for the AI wing, CloudZero combines GCP spend with telemetry to produce unit economics per customer, per product, and per AI feature, the numbers that tell you whether that agent feature is a margin story or a subsidy. It’s how teams managing billions in combined cloud and AI spend keep per-invocation infrastructure tied to actual outcomes.

If your Cloud Run bill is a mystery novel, get a demo and we’ll show you the ending early. Prefer solo exploration? Take the self-guided tour. Or start with a free cloud cost assessment and find out what your functions really cost per unit of value.

Google Cloud Functions FAQs

Keep reading

More from the CloudZero library:

Author Spotlight

Lyne Carolyne

Lyne Carolyne has several years of experience in AI and cloud economics and brings that understanding into the content she creates. Outside work, she's an avid explorer.