Google Cloud Run Functions (formerly Cloud Functions)

• Cloud Run functions (formerly Cloud Functions) is a serverless execution environment for building and connecting cloud services.
• Cloud Run functions provide scalable pay-as-you-go functions as a service (FaaS) to run code with zero server management.
• Cloud Run functions are attached to events emitted from cloud services and infrastructure and are triggered when an event being watched is fired.
• Cloud Run functions supports multiple language runtimes including Node.js, Python, Go, Java, .NET, Ruby, and PHP.
• Cloud Run functions features include
  • Zero server management
    • No servers to provision, manage, or upgrade
    • Google Cloud handles the operational infrastructure including managing servers, configuring software, updating frameworks, and patching operating systems
    • Provisioning of resources happens automatically in response to events
  • Automatically scale based on the load
    • Cloud Run functions can scale from a few invocations a day to many millions of invocations without any work from you.
  • Integrated monitoring, logging, and debugging capability
  • Built-in security at role and per function level based on the principle of least privilege
    • Cloud Run functions uses Google Service Account credentials to seamlessly authenticate with the majority of Google Cloud services
    • Supports Secret Manager integration for securely accessing API keys and credentials
    • Supports Customer-Managed Encryption Keys (CMEK) for encrypting function source code and container images
  • Key networking capabilities for hybrid and multi-cloud scenarios
    • Direct VPC egress support for connecting to VPC networks
    • Shared VPC support
    • Static outbound IP address configuration

Cloud Run Functions Versions

• There are two versions of Cloud Run functions:
  • Cloud Run functions (formerly Cloud Functions 2nd gen) — the latest version, deployed as a service on Cloud Run
    • Can be created using the Cloud Run Admin API (recommended) or the Cloud Functions v2 API
    • Built on Cloud Run infrastructure for better performance, scalability, and configurability
    • Uses run.app URL endpoint
  • Cloud Run functions (1st gen) (formerly Cloud Functions 1st gen) — the original version with limited event triggers, runtimes, and configurability
    • Uses cloudfunctions.net URL endpoint
    • Google plans to continue supporting 1st gen but recommends 2nd gen for new functions
• Key differences between versions:
  

  Feature	Cloud Run functions (Latest)	Cloud Run functions (1st gen)
  Request Timeout	Up to 60 minutes (HTTP), 9 minutes (event-driven via v2 API)	Up to 9 minutes
  Instance Size	Up to 16 GiB RAM with 4 vCPU	Up to 8 GB RAM with 2 vCPU
  Concurrency	Up to 1000 concurrent requests per instance	1 concurrent request per instance
  Traffic Splitting	Supported	Not supported
  Event Types	90+ event sources via Eventarc	7 direct event sources
  Minimum Instances	Supported (reduces cold starts)	Supported
  Infrastructure	Cloud Run	Google internal

Cloud Run Functions Execution Environment

• Cloud Run functions handles incoming requests by assigning them to instances of the function and based on the volume or existing functions, it can assign it to an existing one or spawn a new instance.
• Cloud Run functions (latest) supports up to 1000 concurrent requests per instance, allowing a single instance to handle multiple requests simultaneously, reducing costs and cold starts.
• Cloud Run functions (1st gen) handles only one concurrent request at a time per instance.
• Cloud Run functions may start multiple new instances to handle requests, thus providing auto-scaling and parallelism.
• Cloud Run functions must be stateless i.e. one function invocation should not rely on an in-memory state set by a previous invocation, to allow Google to automatically manage and scale the functions.
• Every deployed function is isolated from all other functions — even those deployed from the same source file. In particular, they don’t share memory, global variables, file systems, or other state.
• Cloud Run functions allows you to set a limit on the total number of function instances that can co-exist at any given time (maximum instances).
• Minimum instances can be configured to keep instances warm and reduce cold starts.
• Cloud Function instance is created when it’s deployed or the function needs to be scaled.
• Cloud Run functions can have a Cold Start, which is the time involved in loading the runtime and the code.
• Function execution time is limited by the timeout duration:
  • Cloud Run functions (latest): Up to 60 minutes for HTTP-triggered functions, up to 9 minutes for event-driven functions (via v2 API)
  • Cloud Run functions (1st gen): Default 1 minute, maximum 9 minutes
• Cloud Run functions provides a writable filesystem i.e. /tmp directory only, which can be used to store temporary files in a function instance. The rest of the file system is read-only and accessible to the function.
• Cloud Run functions has 2 scopes
  • Global Scope
    • contains the function definition
    • is executed on every cold start, but not if the instance has already been initialized
    • can be used for initialization like database connections etc.
  • Function Scope
    • only the body of the function declared as the entry point
    • is executed for each request and should include the actual logic
• Cloud Run Functions Execution Guarantees
  • Functions are typically invoked once for each incoming event. However, Cloud Run functions does not guarantee a single invocation in all cases.
  • HTTP functions are invoked at most once as they are synchronous and the execution is not retried in an event of a failure.
  • Event-driven functions are invoked at least once as they are asynchronous and can be retried.

Cloud Run Functions Events and Triggers

• Events are things that happen within the cloud environment that you might want to take action on.
• Trigger is creating a response to that event. Trigger type determines how and when the function executes.
• Cloud Run functions (latest) uses Eventarc for event routing, supporting any event type supported by Eventarc, including 90+ event sources through Cloud Audit Logs and using the standard CloudEvents format.
• Cloud Run functions supports the following trigger mechanisms:
  • HTTP Triggers
    • Cloud Run functions can be invoked with an HTTP request using the POST, PUT, GET, DELETE, and OPTIONS HTTP methods.
    • HTTP invocations are synchronous and the result of the function execution will be returned in the response to the HTTP request.
  • Eventarc Triggers (Cloud Run functions – latest)
    • Eventarc is Google Cloud’s universal event routing service that delivers events from 90+ sources to Cloud Run functions.
    • Supports Cloud Audit Logs events from virtually any Google Cloud service.
    • Uses the standard CloudEvents format in all language runtimes.
    • Supports dead-letter topics for failed event delivery.
  • Cloud Pub/Sub Triggers
    • Cloud Run functions can be triggered by messages published to Pub/Sub topics in the same Cloud project as the function.
    • Pub/Sub is a globally distributed message bus that automatically scales as needed and provides a foundation for building robust, global services.
  • Cloud Storage Triggers
    • Cloud Run functions can respond to change notifications emerging from Google Cloud Storage.
    • Notifications can be configured to trigger in response to various events inside a bucket — object creation, deletion, archiving, and metadata updates.
  • Cloud Firestore Triggers
    • Cloud Run functions can handle events in Cloud Firestore in the same Cloud project as the function.
    • Cloud Firestore can be read or updated in response to these events using the Firestore APIs and client libraries.
  • Firebase Triggers
    • Analytics for Firebase
    • Firebase Realtime Database
    • Firebase Authentication — Can be triggered by events from Firebase Authentication in the same Cloud project.
  • Direct Triggers
    • Cloud Run functions provides a call command in the CLI and testing functionality in the Cloud Console UI to support quick iteration and debugging.
    • Function can be directly invoked to ensure it is behaving as expected.
• Cloud Run functions can also be integrated with any other Google service that supports Cloud Pub/Sub (e.g., Cloud Scheduler) or any service that provides HTTP callbacks (webhooks).
• Google Cloud Logging events can be exported to a Cloud Pub/Sub topic from which they can then be consumed by Cloud Run functions.

Cloud Run Functions Networking

• Direct VPC Egress — allows functions to send traffic directly to a VPC network without a Serverless VPC Access connector, reducing latency and cost.
• VPC Service Controls — supports VPC SC for data exfiltration protection.
• Ingress Controls — restrict incoming traffic to internal-only, internal-and-cloud-load-balancing, or all traffic.
• Static Outbound IP — configure a static IP for outbound traffic when connecting to external services that require IP allowlisting.
• Shared VPC — supports deploying functions that connect to resources in a Shared VPC network.

Cloud Run Functions Security

• IAM-based Access Control — fine-grained permissions using IAM roles (Cloud Run Source Developer, Service Usage Consumer, Service Account User).
• Secret Manager Integration — securely access API keys, database credentials, and other secrets without hardcoding them. Secrets can be mounted as volumes or exposed as environment variables.
• Customer-Managed Encryption Keys (CMEK) — encrypt function source code and container images with your own keys from Cloud KMS.
• Binary Authorization — enforce deploy-time security policies to ensure only trusted container images are deployed.
• Cloud Armor — protect functions from DDoS attacks and apply WAF rules.
• Identity-Aware Proxy (IAP) — add authentication layer for functions.

Cloud Run Functions Best Practices

• Write Idempotent functions — produce same results when invoked multiple times with the same parameters.
• Do not start background activities i.e. activity after function has terminated. Any code run after graceful termination cannot access the CPU and will not make any progress.
• Always delete temporary files — As files can persist between invocations, failing to delete files may lead to memory issues.
• Use dependencies wisely — Import only what is required as it would affect the cold starts due to invocation latency.
• Use global variables to reuse objects in future invocations, e.g., database connections.
• Do lazy initialization of global variables.
• Use retry to handle only transient and retryable errors, with the handling being idempotent.
• Configure minimum instances to reduce cold starts for latency-sensitive workloads.
• Use concurrency (latest version) to handle multiple requests per instance, reducing costs for high-traffic functions.
• Use Secret Manager instead of environment variables for sensitive configuration data.
• Configure dead-letter topics for event-driven functions to capture failed events for later processing.

GCP Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. A company needs a serverless function that processes large files from Cloud Storage and may take up to 30 minutes. Which version should they use?
   1. Cloud Run functions (1st gen) with HTTP trigger
   2. Cloud Run functions (latest) with HTTP trigger
   3. Cloud Run functions (1st gen) with Cloud Storage trigger
   4. Cloud Run functions (latest) with Cloud Storage event trigger via Eventarc
   Show Answer

   Answer: b – Only the latest version supports up to 60 minutes timeout for HTTP-triggered functions. 1st gen is limited to 9 minutes.

2. What is the maximum number of concurrent requests a single Cloud Run functions (latest) instance can handle?
   1. 1
   2. 100
   3. 1000
   4. Unlimited

   Answer: c — Cloud Run functions (latest) supports up to 1000 concurrent requests per function instance.
3. Which event routing service does Cloud Run functions (latest) use to support 90+ event sources?
   1. Cloud Pub/Sub directly
   2. Eventarc
   3. Cloud Scheduler
   4. Cloud Tasks

   Answer: b — Cloud Run functions (latest) uses Eventarc for event routing, supporting 90+ event sources through Cloud Audit Logs.

4. Which feature helps reduce cold starts in Cloud Run functions?
   1. Maximum instances
   2. Minimum instances
   3. Concurrency
   4. Traffic splitting

   Answer: b — Configuring minimum instances keeps pre-warmed instances ready to serve requests, reducing cold starts.

5. A team needs to gradually roll out a new version of their function with 10% of traffic first. Which feature should they use?
   1. Cloud Run functions (1st gen) with multiple deployments
   2. Cloud Run functions (latest) with traffic splitting
   3. Cloud Pub/Sub with message filtering
   4. Cloud Load Balancer with URL maps

   Answer: b — Cloud Run functions (latest) supports traffic splitting between revisions, allowing gradual rollouts. 1st gen does not support this feature.
6. What was the rebranding change announced for Cloud Functions in August 2024?
   1. Cloud Functions was deprecated and replaced by Cloud Run
   2. Cloud Functions (2nd gen) was renamed to Cloud Run functions
   3. Cloud Functions was merged with App Engine
   4. Cloud Functions was moved to Firebase only

   Answer: b — In August 2024, Google renamed Cloud Functions (2nd gen) to Cloud Run functions and folded it under the Cloud Run umbrella.

See also: Google Cloud Compute Services Cheat Sheet

References

• Cloud Run functions
• Compare Cloud Run functions versions
• Google Cloud Functions is now Cloud Run functions (Aug 2024)
• Cloud Run functions Concurrency
• Cloud Run function triggers