Google Cloud Functions

What Google Cloud Functions actually is

Google Cloud Functions is the functions-as-a-service product on Google Cloud — you deploy a single function, and Google runs it, scales it, and bills you per invocation and per 100 milliseconds of execution time. Since August 2024 it has been officially named Cloud Run functions, which is more than a rebrand: 2nd generation functions now run on the Cloud Run infrastructure and inherit Cloud Run features, while the 1st generation platform remains available and billed on its own pricing page.

The timeline matters when you evaluate it. The public beta was announced at Google Cloud Next in March 2017, general availability followed on July 24, 2018, and the 2nd generation reached GA on August 9, 2022. Second gen fixed most of the complaints that dogged the original: it runs on Cloud Run's infrastructure with Eventarc wiring, supports over 125 Google and third-party SaaS event sources, allows longer request timeouts, more memory and CPU, concurrency (multiple requests per instance), and traffic splitting for rollouts. The practical effect is that the "cold start platform" criticism now applies mainly to remaining 1st gen workloads.

The programming model is the familiar one: HTTP-triggered functions or event-driven functions, deployed from source or container, in Node.js, Python, Go, Java, Ruby, PHP, and .NET runtimes. Integration is the reason people choose it over Lambda or standalone FaaS: Firebase Cloud Functions for mobile and web backends, Cloud Storage and Pub/Sub triggers without glue code, Cloud Build CI deployments, Secret Manager for configuration, and IAM that lines up with the rest of your GCP project. If your organization already lives in Google Cloud, this is the shortest path from "event happened" to "code ran".

We think of it as infrastructure plumbing of the good kind: unglamorous, dependable, and cheap enough that cost control is mostly a matter of not leaving runaway loops behind.

Pricing: what you really pay

The pricing model is usage-based with a real free tier, not a trial. Every billing account gets the first 2 million invocations per month free, permanently, and invocations beyond that are $0.40 per million ($0.0000004 each). A valid billing account is required even for free tier use, which trips up some first-time users.

Beyond invocations you pay for what the function actually consumes: execution time metered to the nearest 100 milliseconds and the memory/CPU you provision. First gen meters compute in GHz-seconds and GB-seconds; second gen is billed on the Cloud Run pricing model of vCPU-seconds and GiB-seconds. Either way the shape of the bill is the same — you pay for the milliseconds your code runs and nothing when it idles. Outbound data transfer adds standard Google Cloud egress fees.

Two cost details deserve attention. First, deploying a function stores a container image — historically in Container Registry (now shut down for writes) and now in Artifact Registry — and that storage is billed separately, even when your function usage sits inside the free tier. Second, because invocations are billed regardless of outcome, a misbehaving retry loop or a bot hitting your HTTP endpoint costs real money even though every request fails. Google's own cost guidance is to watch invocation counts as closely as execution time.

In practice, small and mid-size workloads are cheap: a typical webhook or event-processing function with a few million invocations per month lands in single-digit dollars, and hobby-scale usage is free. There is no minimum commitment and no per-seat pricing. New accounts also get Google Cloud's standard $300 credit.

Performance & infrastructure

The defining infrastructure fact is the 99.95% monthly uptime SLA that Google publishes for Cloud Run functions — measured per active function per project, with "downtime" defined as an error rate above 10% on valid invocations. Financial credits are 10% of the monthly bill at 99% to below 99.95% uptime, 25% at 95% to below 99%, and 50% below 95%, capped at 50%, and you must request them within 30 days with log evidence. This is a real, enforceable SLA with teeth, and it is one of the stronger ones in the FaaS category.

Underneath, functions deploy into Google Cloud regions across North and South America, Europe, Asia, the Middle East, and Australia — you pick a region per function, and latency to your datastores is the main reason to think about placement. Second gen functions inherit Cloud Run capabilities: concurrency per instance, minimum instances to suppress cold starts, maximum instances to cap blast radius, and access to newer Cloud Run features including NVIDIA L4 GPUs for inference workloads. Cold starts still exist — every FaaS platform has them — but minimum instances plus concurrency make them a solved problem when they matter, at the cost of paying for warm capacity.

Support is Google Cloud's tiered model: documentation and community support free, paid support plans with response-time commitments on top of your usage bill. The documentation is among the best in the category — runtimes, limits, migration guides between generations, and pricing are all documented in detail, and the release notes are maintained properly.

Where it falls short

GCP lock-in is the structural limitation. Event sources, IAM, and the deployment pipeline are Google Cloud objects; the function model is portable in principle and Google-attached in practice. Multi-cloud teams will feel it immediately, and if you ever want to move workloads, the realistic destination is Cloud Run or another FaaS service — not a generic container host without rework.

The generation split is the second problem. First gen and second gen have different pricing pages, different capabilities, different cold-start behavior, and an upgrade tool (currently in preview) for migrating. Plenty of long-lived projects still run 1st gen functions, and being on the old generation means living with the old constraints: no concurrency, lower maximum duration, and the harsher cold-start profile the platform is known for. When we hear complaints about "Cloud Functions being slow", the first question we ask is which generation the project runs, because the answer is almost always 1st gen with default settings.

Third, the pay-per-invocation model has a failure mode: costs scale with abuse and bugs, not just with business value. An unauthenticated HTTP function under bot traffic bills for every request, successful or not. There is no built-in spend circuit breaker per function. And while the free tier is generous, image storage in Artifact Registry is a separate metered product that quietly outlives the free allowance as project counts grow.

Who should pick this

Our pick for GCP and Firebase developers who want event-driven compute without operating anything. The Firebase integration is the standout case — mobile and web backends reacting to Firestore, Auth, and Storage events with one deployment path — and for existing GCP shops, the Eventarc trigger catalog removes most of the glue code you would otherwise maintain. Teams with spiky, unpredictable traffic also do well here: scale-to-zero plus per-100ms billing beats provisioned containers on cost at low utilization.

We would not pick it for portable, multi-cloud architectures — look at Knative-based platforms or a container platform you control. Workloads with heavy sustained CPU at high concurrency may be cheaper on Cloud Run directly or on plain VMs; FaaS pricing is optimized for intermittent work. And teams allergic to per-request billing exposure on public endpoints should put Cloud Armor or an API gateway in front, budgeted in from day one. For comparisons against other serverless and container platforms, see /category/serverless-platforms and our /benchmarks pages.

Second gen also widens the window for request handling and background work, which matters for tasks that the original 15-minute cap made awkward. For anything latency-sensitive, budget for a minimum instance. That one setting is the difference between a platform that feels slow and one that feels instant.

Key takeaways

• Cloud Functions is now Cloud Run functions (renamed August 2024); 2nd gen runs on Cloud Run infrastructure and reached GA on August 9, 2022.
• The first 2 million invocations per month are permanently free per billing account; beyond that, $0.40 per million invocations, plus execution time metered to the nearest 100 milliseconds.
• Google publishes a 99.95% monthly uptime SLA with 10/25/50% financial credits — one of the stronger SLAs in the FaaS category.
• Second gen fixes most legacy complaints: concurrency, Eventarc with 125+ event sources, longer timeouts, traffic splitting, and access to Cloud Run features including NVIDIA GPUs.
• Two pricing meters apply: function usage and separate container-image storage in Artifact Registry, which bills even inside the free tier.
• Best for GCP and Firebase teams; multi-cloud shops and sustained high-CPU workloads should compare Cloud Run, containers, or VMs first.

Sources

• https://cloud.google.com/functions/sla
• https://cloud.google.com/functions/pricing-1stgen
• https://cloud.google.com/free
• https://cloud.google.com/blog/products/gcp/google-cloud-functions-a-serverless-environment-to-build-and-connect-cloud-services_13
• https://cloud.google.com/blog/products/serverless/cloud-functions-2nd-generation-now-generally-available
• https://cloud.google.com/blog/products/serverless/google-cloud-functions-is-now-cloud-run-functions
• https://cloud.google.com/functions/docs/release-notes
• https://docs.cloud.google.com/docs/geography-and-regions