Before diving deep, we need a clear picture of what this service is, what problem it solves, and what its name means today.

The problem it solves

Traditionally, running even a tiny piece of logic meant renting a server, installing an operating system, installing a language runtime, opening network ports, applying security patches, and watching the machine around the clock. If the logic only needed to run when a file was uploaded or a message arrived, the server sat idle most of the time and you still paid for it. Cloud Functions removes that burden. You supply only the logic. Google supplies and manages the rest.

This style is called serverless computing. The word is a little misleading, because servers absolutely exist. The point is that you never see them, never log into them, and never decide how many there should be. You think in terms of events and code, not machines.

A note on naming

Google has been merging the identity of Cloud Functions with its container platform. The newer generation of the product is now presented in Google Cloud documentation under the name Cloud Run functions, and the older generation is described as Cloud Run functions (1st gen). Many engineers still say “Cloud Functions” out of habit, and the tooling, the console, and a great deal of existing material still use that name. In this guide we say Cloud Functions and note the generation whenever the difference matters. If you meet either name in documentation, you are looking at the same family of ideas.

What a function actually is

A function is a single-purpose unit of code with an entry point. Google Cloud calls that entry point when something happens. The something might be a web request, a new message on a queue, a file landing in storage, or a scheduled tick of a clock. The function receives information about what happened, does its work, and finishes. It is meant to be short-lived, stateless, and focused on one job.

Every new field has its own words. Here are the ones you will hear constantly, each explained from scratch.

Why these words matter

Each term above describes a decision you will make or a behavior you will observe. A trigger decides how work reaches you. An instance and its concurrency decide how much work one copy of your code can juggle. A cold start decides how snappy the first request feels. A service account decides what your code is allowed to touch. Idempotency decides whether a retry quietly heals a failure or quietly corrupts your data. Learn these eight words well and the rest of the service becomes a matter of combining them sensibly.

Cloud Functions exists in two generations. Knowing how they differ is the single most useful architectural fact about the service.

First generation

The first generation was the original design. It used its own purpose-built infrastructure, its own event system for background triggers, and a simple model in which each instance handled exactly one request at a time. It is straightforward and well understood, but it carries tighter limits on memory, request size, and duration, and it cannot do things like handle several requests in one instance.

Second generation

The second generation is a rebuild on top of two other Google Cloud products. Your code is packaged into a container and executed by Cloud Run, which provides the serving, scaling, and networking engine. Event triggers are delivered by Eventarc, which provides a single, standardized way to route events from many sources to a destination. Because it sits on these foundations, the second generation inherits larger limits, better concurrency, and a much wider set of event sources.

flowchart TD
    A["Your function source code"] --> B["Cloud Build"]
    B --> C["Container image"]
    C --> D["Artifact Registry"]
    D --> E["Cloud Run service (serving engine)"]
    F["Eventarc (event routing)"] --> E
    G["HTTP clients"] --> E
    E --> H["Function instances"]
        

Comparing the generations

The main moving parts

What happens between the moment you click deploy and the moment your code answers its first request?

The build pipeline

When you deploy, the platform takes your source and detects the language and its dependency list. It then uses buildpacks, which are standard recipes that know how to assemble a clean, minimal container for a given language. Your dependencies are downloaded, your code is combined with a small framework that knows how to call your entry point, and the result is sealed into an image. Because this runs on managed build infrastructure, the build uses its own identity and its own permissions, and build failures show up as deployment errors rather than runtime errors.

This is an important distinction. A function can fail in two completely different phases: at build time, where the problem is usually a missing dependency or a permission on the build identity, and at run time, where the problem is usually your own logic or a missing permission on the function identity. Learning to ask “which phase failed?” saves hours of confusion.

The framework inside the container

Your code does not run alone. Inside the container, Google supplies a small framework for each supported language. That framework starts a tiny web server, listens on the expected port, translates incoming requests or events into the shape your function expects, calls your entry point, and then translates your return value back into a response. This is why you can write very little code and still get a fully working web service. It is also why a function must be careful about what it does after returning, a topic we return to in the chapter on common mistakes.

Starting an instance

Why global code is powerful

Because step four runs once per instance, anything expensive that you set up there is reused by every later request that lands on the same instance. Database connections, API clients, and loaded configuration are classic examples. This is the main tool you have for making functions fast. The flip side is that this reuse is a convenience, not a promise. Instances can disappear at any time, so you may use them as a cache but never as a source of truth.

Sandboxing and isolation

Your function runs inside a hardened sandbox. The sandbox restricts what the code can do on the host: it limits system calls, isolates the file system, and keeps neighboring workloads from seeing each other. For you this means two practical facts. First, the writable file system is temporary and is held in memory, so writing files consumes the memory you pay for. Second, you cannot count on any particular host-level behavior, because the platform deliberately hides it.

A function sleeps until something wakes it. The kind of trigger you pick shapes almost everything about how the function behaves.

The two big families

Triggers fall into two families. The first is HTTP, where a caller sends a web request and waits for a response. The second is event-driven, where something happens elsewhere in the cloud and a message is delivered to your function in the background, with nobody waiting for an answer. The two families have different timeouts, different retry behavior, and different expectations about what a “successful” run means.

CloudEvents: one shape for every event

In the second generation, events arrive in a standard envelope called CloudEvents. Instead of each source inventing its own message layout, every event carries the same kind of header fields: what type of event it is, where it came from, when it happened, and a unique identifier, followed by a data payload specific to the source. This consistency means you can write generic handling and logging once and reuse it across many triggers.

Choosing the right trigger

Follow one piece of work from the outside world all the way through your function and back.

The HTTP path

A client sends a request to the function address. The request first reaches Google’s front end, which terminates the secure connection, checks whether the caller is allowed to invoke the function, and applies ingress rules. The request is then routed to an instance that has room. If no instance has room, a new one starts, which is the cold start described earlier. The framework hands the request to your code, your code responds, and the response travels back to the client.

sequenceDiagram
    participant C as Client
    participant F as Google front end
    participant R as Serving engine
    participant I as Function instance
    C->>F: Send request
    F->>F: Check identity and ingress rules
    F->>R: Forward allowed request
    R->>I: Route to instance with free capacity
    I->>I: Run function logic
    I-->>R: Return response
    R-->>C: Deliver response
        

The event path

For event-driven functions, there is no client waiting. A source such as Pub/Sub or Cloud Storage produces an event. Eventarc picks it up, wraps it as a CloudEvent, and delivers it to the function using an internal HTTP call. From the function’s point of view, the event simply arrives like a request, and a success signal tells the router that the work is done. A failure signal tells the router that it may need to try again, depending on how retries are configured.

flowchart LR
    S["Event source (storage, topic, database)"] --> E["Eventarc router"]
    E --> T["Internal delivery with identity"]
    T --> F["Function instance"]
    F -->|"Success"| D["Event marked done"]
    F -->|"Failure"| R["Retry or give up"]
    R --> T
        

The lifecycle of an instance

The thing people love most about serverless is automatic scaling. Understanding how it decides what to do lets you tune it instead of fearing it.

How automatic scaling decides

The platform watches how much work is arriving and how much capacity exists. When requests pile up faster than current instances can serve them, it starts more instances. When demand falls, it retires instances, down to zero if there is no traffic at all. Several factors influence how fast and how far this can go: your minimum and maximum instance settings, your concurrency setting, how long your function takes to finish, how long it takes to start cold, your error rate, and the regional capacity that happens to be available at that moment.

HTTP functions generally scale up very quickly. Background functions fed by event sources tend to scale more gradually, because the event system ramps delivery in a measured way to avoid overwhelming your code. This means a sudden flood of events may be processed with a short, smooth ramp instead of an instant jump.

Concurrency: the biggest second-generation advantage

In the first generation, one instance handled exactly one request at a time, so a thousand simultaneous requests needed a thousand instances. In the second generation, one instance can handle many requests at once. The default is high when the instance has at least one full CPU, and the upper bound is much higher still. The effect is dramatic: the same traffic can be served by far fewer instances, which means fewer cold starts and a lower bill.

There is a catch. When one instance handles several requests together, those requests share the same memory and the same global variables. There is no isolation between them. If your code keeps request-specific data in a shared global variable, two requests can overwrite each other’s data and produce bugs that appear only under load. Concurrency is therefore a trade between efficiency and the discipline of writing code that is safe to run in parallel.

The four dials you control

Understanding cold starts

A cold start is the sum of the startup steps described in the internal working chapter: finding capacity, fetching the image, booting the runtime, and running global code. Several things make it longer: large container images, heavy dependencies, languages with slower startup, and global code that does a lot of work such as opening many connections. Several things make it shorter: lean dependencies, lazy loading of rarely used modules, generous CPU, and keeping a few minimum instances warm.

flowchart TD
    A["Request arrives"] --> B{"Warm instance with free capacity?"}
    B -->|"Yes"| C["Handle immediately"]
    B -->|"No"| D["Start new instance"]
    D --> E["Fetch image and boot runtime"]
    E --> F["Run global code"]
    F --> C
    C --> G["Return response"]
        

Protecting what lies behind your function

Automatic scaling is wonderful until your function scales faster than the database behind it. A thousand instances each opening ten connections can overwhelm a database that was designed for a few hundred. The maximum instance setting, sensible connection reuse, connection pooling at a managed layer, and queues placed in front of fragile systems are the standard protections. Scaling the front is easy; scaling the whole chain safely is the real design task.

Networking has two directions. Ingress is traffic coming in to your function. Egress is traffic going out from it.

Ingress control

By default an HTTP function has a public address on the internet. You can tighten this. Ingress settings let you allow all traffic, allow only traffic that comes from inside your own project or private network and certain Google services, or allow only internal traffic combined with a load balancer. Choosing a stricter setting is the first step toward making a function private. Even a public address does not mean a public function, though, because the caller must also pass the identity check described in the security chapter.

Egress and private resources

By default your function reaches the internet and public Google services directly. Many real systems, however, keep databases, caches, and internal services inside a private network with no public address. To reach those, a function needs a path into the private network. Google Cloud offers a managed connector for this purpose, and newer direct options that attach the function’s traffic to a network without a separate connector resource. You also choose whether all outbound traffic goes through that private path or only traffic bound for private addresses.

Fixed outbound addresses

Some partners only accept calls from known, fixed addresses. Functions normally use a wide pool of changing addresses, so they cannot satisfy such a rule on their own. The standard solution is to route outbound traffic through a managed network address translation service that owns a reserved static address. All function traffic then appears to come from that single, stable address, which the partner can safely allow.

flowchart LR
    U["Internet caller"] --> LB["Load balancer or public address"]
    LB --> FN["Function instance"]
    FN --> VPC["Private network path"]
    VPC --> DB["Private database"]
    VPC --> NAT["Managed NAT with static address"]
    NAT --> P["Partner service"]
        

Connections and limits

Every instance has limits on how many outbound connections it can open and how fast. Creating a new connection for every request wastes time and can hit these limits. Reusing a connection created in global scope is the healthy habit. Closing connections carelessly or leaking them across thousands of instances leads to exhaustion errors that are confusing to diagnose.

Serverless does not mean security-free. Google secures the machines, but you remain responsible for who can call your code, what your code can touch, and how it handles secrets.

Two directions of identity

Security in Cloud Functions has two directions, and mixing them up is a classic mistake. The first is who may invoke your function. The second is what your function may do once it is running.

For invocation, the key concept is the invoker permission. A function that requires authentication will reject callers who cannot prove their identity and who lack permission to invoke it. A function can be deliberately made public, but that should be a conscious, reviewed decision, not an accident. For service-to-service calls, the calling service presents a signed identity token, and the function verifies it before running any logic.

For runtime behavior, the function runs as a service account. That identity is what other Google Cloud services see when your function calls them. If the function reads a storage bucket, the service account needs read permission on that bucket, and nothing more.

Least privilege in practice

The default runtime identity for a project is often broad, because it exists for convenience. Leaving a function on a broad default identity means a vulnerability in that one function could expose much more than it ever needed. The healthier habit is to create a dedicated service account per function, or per closely related group of functions, and grant only the specific roles required on only the specific resources needed.

Handling secrets

Never place passwords, tokens, or keys inside source code or plain configuration text, because source code is copied, reviewed, and stored in many places. Use a dedicated secret manager. The function can be configured so that a secret appears either as an environment value or as a mounted file at start time, and the platform fetches it using the function’s own identity. This also makes rotation easier, because you update the secret in one place instead of redeploying every consumer.

Supply chain and input safety

Your function depends on libraries written by others. Keep dependencies minimal, pin their versions, scan them for known problems, and update them regularly. Also treat every input as untrusted. Whether a request comes from the internet or an event comes from a bucket someone else can write to, validate its shape and size before acting. An attacker can often influence event contents indirectly, for example by choosing the name of an uploaded file.

Distributed systems fail in small, strange ways all the time. A reliable function is one designed with that expectation.

How retries work

For HTTP functions, retrying is the caller’s job. If the call times out or returns an error, the client decides whether to try again. For event-driven functions, retrying is configurable. You may leave retries off, in which case a failed event is dropped after the first attempt, or turn retries on, in which case the event system keeps trying with growing delays for a limited period. Choosing between these is a business decision about whether losing an event is worse than seeing it more than once.

Idempotency: your safety net

Because the same event can arrive more than once, the function should produce the same final result whether it runs once or three times. This property is called idempotency. A function that adds a record, charges a card, or sends an email is not naturally idempotent. It must be made so.

The usual approach is to use the unique identifier carried by each event, or a key supplied by the caller. Before doing the sensitive work, the function checks a durable store to see whether that identifier has already been processed. If it has, the function skips the work and returns success. If not, it does the work and records the identifier, ideally in a single atomic step so that two parallel attempts cannot both pass the check.

Poison messages and dead letters

Some events can never succeed, for example a malformed message that always makes your code crash. With retries enabled, such a message would be retried again and again, wasting resources and hiding real problems. The cure is a dead-letter path: after a limited number of attempts, the failing message is moved to a separate holding place where people or tools can inspect it later. Designing this path up front turns a mysterious production incident into a calm review of a short list.

Timeouts and the shape of long work

Every function has a maximum duration. HTTP functions in the second generation may run up to an hour, event-driven functions are limited to a much shorter window, and scheduled or task-queue functions sit in between. When work could exceed these limits, do not stretch the function. Break the work into smaller steps, each triggered by the completion of the last, or hand long jobs to a service built for long-running batch work. A function that regularly runs near its limit is a warning sign, not a success.

flowchart TD
    A["Event delivered"] --> B{"Already processed?"}
    B -->|"Yes"| C["Skip and report success"]
    B -->|"No"| D["Do the work"]
    D --> E{"Worked?"}
    E -->|"Yes"| F["Record id and report success"]
    E -->|"Temporary error"| G["Report error for retry"]
    E -->|"Permanent error"| H["Send to dead letter and report success"]
        

You cannot fix what you cannot see. Because you never log into the machine, observability is delivered through managed tools.

Logs

Anything your function writes to its standard output and error streams is collected automatically and sent to Cloud Logging. Platform-generated entries, such as request records and errors, appear alongside your own. The most useful habit is structured logging: writing log entries as structured records with named fields instead of free text. Structured entries can be filtered, grouped, and counted far more easily, and they let you attach a correlation identifier so that every log line belonging to one request or one event can be found together.

Metrics

Cloud Monitoring collects metrics automatically for every function. The most useful ones answer a few basic questions: how many invocations are happening, how long they take, how much memory and CPU they use, how many instances are running, and how many executions end in errors. You can build dashboards from these and, more importantly, create alerts so that a person is told when something drifts out of its healthy range.

Tracing

When one user action flows through several functions and services, a single log line tells only a fragment of the story. Distributed tracing links the pieces together into one timeline, so you can see that a slow response was caused by a particular downstream call. Passing the trace context along with each outgoing call is what stitches the timeline together.

What to alert on

Serverless pricing is simple in spirit but rewards understanding. The goal is to know what drives the bill and where the hard limits sit.

What you pay for

The bill is built from a few components: the number of invocations, the compute time consumed measured against the CPU and memory you allocated, outbound network data, and any minimum instances you keep warm. A generous monthly free allowance covers small workloads. Because the exact rates and free tiers change, always use the official pricing page and the pricing calculator rather than relying on remembered numbers.

Two design choices have an outsized effect on cost. First, concurrency: because one instance can serve many requests, high concurrency spreads the cost of an instance across more work. Second, minimum instances: they remove cold starts but convert part of the pay-per-use model into a steady cost. Neither is right for everything, so measure rather than guess.

Limits to design around

Advantages and trade-offs

Where functions sit among Google Cloud compute options

Good patterns turn small functions into dependable systems. Anti-patterns turn them into puzzles at three in the morning.

Patterns worth knowing

flowchart LR
    U["Upload to bucket"] --> E1["Storage event"]
    E1 --> F1["Splitter function"]
    F1 --> T["Topic of small jobs"]
    T --> W1["Worker instance A"]
    T --> W2["Worker instance B"]
    T --> W3["Worker instance C"]
    W1 --> R["Results store"]
    W2 --> R
    W3 --> R
        

Anti-patterns to avoid

The following scenarios show how the ideas in this guide combine in typical production systems. They are illustrative patterns drawn from common industry practice.

What these examples share

Look at the common threads. Each design keeps functions small and focused. Each uses a queue or event to decouple steps. Each protects against duplicates, uses a limited identity, and treats failure as a normal, planned-for condition. None relies on in-memory state. These habits, more than any specific feature, are what make a serverless system calm to operate.

A checklist of habits that experienced teams build into every function, and the traps that catch newcomers.

Best practices

Common mistakes

A short pre-release review

Short, direct answers to questions that come up again and again.

They describe the same family of products. Google Cloud now presents the newer generation under the Cloud Run functions name because it is built on Cloud Run, while the older name remains common in tools and conversation.

For new work, the second generation is generally the better starting point because of concurrency, larger limits, longer HTTP duration, and broader event sources. Check current documentation for any feature you specifically depend on.

You can greatly reduce them with minimum instances, lean dependencies, and light global code, but you cannot promise to eliminate every one, because scaling out always involves starting new instances at some point.

No. Delivery is at-least-once, so duplicates are possible. Make your function idempotent so that a repeated event does no harm.

It depends on the generation and trigger type. In the second generation, HTTP functions can run much longer than event-driven ones, with scheduled and task-queue functions in between. Confirm the current figures on the official quota page and split work that approaches the limit.

Only as a temporary speed-up in memory. Instances can disappear at any time and different instances do not share memory, so durable data belongs in a database, a cache service, or object storage.

Give the function a path into your private network using a managed connector or a direct network option, and send private-bound traffic through it. Keep the database free of public addresses.

Require authentication, grant the invoker permission only to specific identities, and consider stricter ingress settings. Never grant invoker access to everyone unless the function is truly meant to be public.

Common causes include a trigger loop, a very high invocation count, minimum instances left on, low concurrency forcing many instances, long waits on slow downstream calls, and large outbound data. Metrics and billing reports help pinpoint which one applies.

When you need long-lived processes, full control of the container, heavy steady computation, or a large multi-service application. Moving to a container service is a natural next step, especially because the second generation already runs on that foundation.

Yes, but deploy them as separate functions so each has its own settings, identity, and scaling. Shared helper code is fine; one giant entry point doing everything is not.

Break the work into smaller steps connected by events or a workflow service, or hand the job to a service designed for long-running batch work, instead of stretching a function toward its time limit.

Cloud Functions lets you run small pieces of code in response to events or web requests without ever touching a server. The second generation, now surfaced as Cloud Run functions, rests on Cloud Run for serving and Eventarc for events, which brings higher concurrency, larger limits, and a wide range of event sources. Behind the simplicity sits a clear pipeline: your source is built into a container, stored in a registry, started as instances on demand, and called through a small framework. Scaling is automatic but tunable through minimum instances, maximum instances, concurrency, and resource size. Security depends on getting two identities right, one for who may call the function and one for what the function may do. Reliability depends on assuming duplicates and failures, using idempotency, retries, and dead-letter paths. Observability comes from structured logs, metrics, alerts, and traces. And the healthiest designs keep functions small, stateless, and decoupled by queues and events. Hold on to those ideas and you can build systems that are cheap when quiet, strong when busy, and calm when something goes wrong.