Google Cloud Functions in 2025: What Teams Should Know

Introduction

If you’ve been searching for google cloud functions lately, you’ve probably noticed a new label across Google’s docs: Cloud Run functions. In August 2024, Google renamed Cloud Functions (2nd gen) to Cloud Run functions and folded it under the Cloud Run umbrella—same event-driven model, now with Cloud Run’s knobs for performance, scalability, and security.

This article provides a crisp Google Cloud Functions overview for 2025—how it works, pricing, differences from Cloud Run and AWS Lambda, security best practices, and when to choose each service.

What is Google Cloud Functions ?

Cloud Run functions is Google’s Functions-as-a-Service (FaaS): single-purpose code that runs on demand, triggered by HTTP or events, without servers to manage. Under the hood, it deploys to Cloud Run and uses Eventarc for event delivery. You get simple function signatures and language runtimes, plus Cloud Run’s controls (concurrency, CPU/memory, networking).

Supported runtimes include Node.js, Python, Go, Java, .NET, PHP, and Ruby, with lifecycle/support schedules clearly documented.

If you still have “1st gen” functions, Google keeps the docs available; but for new work, Cloud Run functions is the path forward. The official comparison page highlights the differences and migration considerations.

Architecture: How Execution, Scaling, And Triggers Work

At a high level:

• Triggering. Functions can be invoked over HTTP or via Eventarc triggers from many Google Cloud services (e.g., Cloud Storage, Pub/Sub, Cloud Audit Logs). Eventarc is the standardized event delivery plane for functions.
• Execution model. Your code runs in a managed container with a configurable runtime. Cloud Run’s platform handles provisioning, horizontal scaling, and scale-to-zero. You can also tune concurrency and vCPU/memory for 2nd-gen functions because they’re built on Cloud Run.
• Quotas & limits. Since Cloud Run functions rides on Cloud Run, you inherit Cloud Run-style limits. For example, Cloud Run supports up to 60-minute request timeouts; the product-specific quotas page details function limits across resource, time, rate, and networking categories.

Google Cloud Functions Pricing

Cloud Run functions pricing now follows Cloud Run pricing. You pay for:

• vCPU-seconds
• GiB-seconds (memory)
• Requests
• Networking (egress)

There’s also a free tier: for request-based billing in us-central1, Cloud Run lists 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests free per month (tiers vary by region and billing mode). Serverless VPC Access connectors (if you attach one) are billed separately.

Rule of thumb:

Example (illustrative): A function with 1 vCPU and 2 GiB that runs for 300 ms per request and serves 5 M requests in a month will accrue:

• vCPU-seconds: 0.3 × 1 × 5,000,000 = 1,500,000 vCPU-s
• GiB-seconds: 0.3 × 2 × 5,000,000 = 3,000,000 GiB-s
• Subtract the free tier (per your region & billing mode), then apply the per-unit rates from the Cloud Run pricing page. (Exact $/unit varies by region—always confirm on the official pricing page.)

Free tier recap (functions on request-based billing, us-central1 example):

• 180k vCPU-seconds, 360k GiB-seconds, 2M requests free per month.

Google Cloud Functions Security

Security for Cloud Run functions builds on Cloud Run’s model:

• Identity & access control. Use IAM to control who can deploy or invoke. Authenticated invocation requires the run.routes.invoke permission (granted by roles like roles/run.invoker).
• Perimeter & auth in front. Use Identity-Aware Proxy (IAP) to put Google-managed authentication in front of HTTP functions—handy when exposing internal tools without rolling your own auth.
• Secrets. Integrate Secret Manager to mount or inject secrets without baking them into configs or code. (Best practice: avoid raw env vars for sensitive secrets; reference Secret Manager instead.)
• Private access. If your function must call private resources in a VPC (Cloud SQL, Memorystore, internal services), attach a Serverless VPC Access connector—and remember it has its own pricing.
• Security design. For a complete model (isolation, service identities, ingress/egress, and supply chain controls), review Cloud Run’s security overview.

Cloud Run Services vs Cloud Run Functions(2025)

Both are serverless and charge per-use, but they target different levels of abstraction:

• Cloud Run functions (formerly Google Cloud Functions). You write a function with a framework-friendly signature. You get opinionated build tooling plus Cloud Run’s scaling knobs. It’s ideal for event-driven plumbing, webhooks, data transforms, and lightweight APIs.
• Cloud Run (services/jobs). You deploy containers (any language/runtime) and control more (Dockerfile, background processes, long timeouts, jobs, worker pools). It’s better for full services, custom runtimes, or workloads that outgrow the “single function” model. An official blog post outlines the mental model for choosing.

If you’re unsure, start with Cloud Run functions for event-driven glue code. If you need custom base images, non-standard runtimes, or more process control, switch to Cloud Run services. Google’s comparison page clarifies differences (concepts, config, deploy, triggers).

AWS Lambda vs Google Cloud Functions

A quick, doc-backed comparison (2025)

• Packaging & runtimes
  • Lambda: ZIP or container image; multiple managed runtimes.
  • Cloud Run functions: managed runtimes (Node.js, Python, Go, Java, .NET, PHP, Ruby) on the Cloud Run platform.
• Timeouts
  • Lambda: up to 15 minutes per invocation.
  • Cloud Run functions: built on Cloud Run—HTTP requests up to 60 minutes; Eventarc (event-driven) functions up to 9 minutes.
• Pricing & free tier
  • Lambda: pay per GB-second + requests; free tier 1M requests + 400k GB-seconds/month.
  • Cloud Run functions: pay per vCPU-second, GiB-second, requests, and egress; Cloud Run free tier (example us-central1) 2M requests + 180k vCPU-s + 360k GiB-s/month.
• Eventing
  • Lambda: native sources like S3, SNS, SQS, EventBridge. (AWS service docs)
  • Cloud Run functions: Eventarc delivers events from Cloud Storage, Pub/Sub, Audit Logs, etc., plus HTTP triggers.
• Networking
  • Lambda: VPC integration via ENIs. (AWS Lambda VPC docs)
  • Cloud Run functions: Serverless VPC Access connectors for private resources (billed separately).
• Cold starts & latency control
  • Lambda: Provisioned Concurrency keeps environments warm for predictable latency.
  • Cloud Run functions: minimum instances keeps a baseline of warm instances to reduce cold starts.
• Concurrency model
  • Lambda: one in-flight request per execution environment; overall scaling is by creating more environments (subject to concurrency limits).
  • Cloud Run functions: configurable request concurrency per instance (default 80, up to 1000).
• Observability (built-in)
  • Lambda: metrics & logs in Amazon CloudWatch by default.
  • Cloud Run functions: Cloud Logging & Cloud Monitoring (Google Cloud’s operations suite).
• Ephemeral storage (scratch space)
  • Lambda: configurable /tmp from 512 MB to 10 GB.
  • Cloud Run functions: ephemeral, in-memory volumes (tmpfs) via Cloud Run; data is discarded when the instance is torn down.

Bottom line: If your stack lives on GCP and you want event-driven “glue code” with Cloud Run’s knobs (concurrency, min instances, VPC, 60-min HTTP), Cloud Run functions is a natural fit. If you’re primarily on AWS or already standardized on its event sources, Lambda is the simpler choice. Both are mature FaaS options with clear controls for performance, security, and cost.

When Cloud Run Functions Shines

Great fits

• Event-driven processing: Cloud Storage image thumbnails, Pub/Sub ETL, Audit Log reactions.
• Webhooks & lightweight APIs: Fast HTTP endpoints with managed auth via IAM or IAP.
• Service glue: Orchestrating between GCP services without maintaining servers.

Consider Cloud Run services instead when you need:

• A custom base image or non-standard runtime.
• Long-running processing, background workers, or job orchestration.
• Finer control of concurrency/startup behavior beyond what functions expose. (You still get concurrency tuning on functions, but services provide the full surface.)

Getting Started

• Hello world & triggers: The official docs walk you through HTTP and Eventarc-based functions and the deployment flow.
• Know your limits: Skim the quotas/limits to avoid surprises during load tests.
• Plan security early: Decide IAM roles, IAP front-door, and Secret Manager wiring before you go live.
• Price check: Validate a month’s worth of expected requests and durations with the Cloud Run pricing page (rates vary by region and billing mode).

Conclusion

In 2025, Google Cloud Functions lives as Cloud Run functions: the familiar, event-driven model on the Cloud Run platform. You still write small handlers and attach them to HTTP or Eventarc, while inheriting Cloud Run’s controls—longer timeouts, configurable concurrency, IAM/IAP, Secret Manager, and private networking. Pricing remains per-use with a practical free tier. The decision is straightforward: choose Cloud Run functions for function-style glue and lightweight APIs, Cloud Run services when you need full containers or background work, and AWS Lambda if your ecosystem is centered on AWS.