Serverless computing: how it works, what it costs and where it is heading

What serverless computing means

The CNCF glossary describes serverless as computing that abstracts servers away from the user: the provider (a public cloud or an internal platform team) handles the machines, capacity follows demand without anyone adjusting it, and charges are pay-per-use. The entry also makes a distinction worth keeping: "serverless" and "FaaS" are often used interchangeably, but they are different concepts. Decentralized apps built on blockchains are a different idea again, covered in what web3 is.

The CNCF's serverless whitepaper splits a serverless platform into two parts:

• Functions as a service (FaaS): small units of code triggered by events or HTTP requests, run and scaled as needed without servers to manage. AWS Lambda, which the whitepaper dates to November 2014, is the best-known example.
• Backend as a service (BaaS): managed services reached through an API, such as databases, object storage, queues and authentication, that scale and operate out of sight. Functions are stateless, so these services usually hold the state.

In 2026 a third group sits beside them: serverless containers, where you hand the platform a container image instead of a function and it still scales on demand and bills per use. Test any product sold as serverless with three questions: are the servers entirely someone else's, does it scale on its own (ideally to zero), and do you pay for use rather than capacity? Where an answer is no, that is where the extra bill or operations work hides.

Serverless does not mean no operations either. The whitepaper says plainly that operations engineers are still needed; their work moves from patching and capacity planning to permissions, observability and cost control.

How serverless works: events, instances and scale to zero

Every serverless platform runs the same loop, whatever it calls the parts:

1. An event arrives: an HTTP request, a queue message, a file landing in object storage, a database change or a timer.
2. The platform looks for a warm instance. AWS Lambda calls it an execution environment, Cloud Run a container instance, Cloudflare Workers an isolate.
3. If none is free, it starts one. On Lambda that means downloading your code, starting the runtime and running your initialization code: the cold start.
4. Your code runs inside the memory, CPU and time limits you configured.
5. The instance waits. Lambda freezes the environment after an invocation and keeps it for a while, so a later request can reuse it: a warm start.
6. Idle instances are removed. On Cloud Run, when no requests arrive, even the last instance goes. That is "scale to zero".

Scaling is the same loop in parallel. When events arrive faster than existing instances can take them, the platform adds instances. Lambda lets each function add up to 1,000 execution environments every 10 seconds until the account reaches its concurrency quota; requests beyond that fail with a throttling error (HTTP 429).

How much work one instance takes at a time differs by platform, and it changes both the cost and the code:

• A default Lambda execution environment runs one invocation at a time, so 100 simultaneous requests need 100 environments.
• A Cloud Run instance can take up to 1,000 concurrent requests; services created in the Google Cloud console default to 80.
• A Workers isolate can serve several requests at once on a single-threaded event loop.
• Azure Functions on the Flex Consumption plan lets you set concurrency per instance, and that setting decides how many instances the platform needs.

Instances are also disposable. Cloud Run's writable file system lives in memory and disappears when the instance stops, and the platform can stop any instance when it scales in. Anything that must survive goes to a managed service: a database, object storage or a queue. The same logic says to do expensive setup once per instance, not once per request:

import boto3

# Runs once per execution environment, during initialization
s3 = boto3.client("s3")

def handler(event, context):
    # Runs on every invocation and reuses the client created above
    listing = s3.list_objects_v2(Bucket=event["bucket"], MaxKeys=10)
    return listing["KeyCount"]

Cold starts, and what platforms do about them

A cold start is the delay a request pays when no warm instance is free. AWS reports that cold starts typically affect under 1% of Lambda invocations and last from under 100 ms to over a second, and that they are more common in development and test functions, which run less often. They are billed, too: since August 1, 2025, Lambda charges for the initialization (INIT) phase in every configuration, including ZIP packages on managed runtimes, where it used to be free.

The first remedy is in your own code: fewer and lighter dependencies, and nothing in initialization that the first request does not need. After that, each platform has its own tools, and the ones that keep capacity warm are billed while they wait:

SnapStart changes how you write initialization code. Lambda initializes the function once when you publish a version, takes a Firecracker microVM snapshot of its memory and disk state, and restores new environments from that snapshot as traffic grows. It supports Java 11 and later, Python 3.12 and later, and .NET 8 and later. The catch is uniqueness: anything created during initialization, such as a unique ID, a secret or the seed for random numbers, is copied into every restored environment, and network connections opened then may not survive the restore. Generate unique values after restore, and check connections before using them.

The main serverless platforms in 2026

These four platforms show the range of designs. They differ less in what they promise than in what you deploy, what scales and what you pay for:

AWS Lambda is the reference point. CPU grows with memory (at 1,769 MB a function gets the equivalent of one vCPU), and the default quota of 1,000 concurrent executions per Region can be raised to tens of thousands; new accounts start lower (Lambda quotas).

Azure Functions now steers new apps to the Flex Consumption plan: Linux only, virtual network integration, instance sizes of 512 MB, 2,048 MB or 4,096 MB, and per-function scaling up to 1,000 instances. Microsoft calls the original Consumption plan legacy, and hosting on Linux in the Consumption plan retires on September 30, 2028.

Google Cloud Run runs containers and, since August 22, 2024, functions: Cloud Functions became Cloud Run functions, on the same infrastructure. Besides request-driven services, it runs jobs to completion, worker pools for background work such as queue consumers, and long-lived single instances, and for Go, Node.js, Python, Java, .NET and Ruby it can build the container from your source code.

Cloudflare Workers runs code in isolates of V8, the JavaScript engine behind Chromium and Node.js, on machines in hundreds of locations, so code runs close to users by default. One runtime process hosts many isolates, and Cloudflare says an isolate starts around a hundred times faster than a Node.js process in a container or virtual machine. Workers are written in JavaScript, TypeScript or Python, or in languages such as Rust, Go and C compiled to WebAssembly. The price is tight limits: 128 MB of memory per isolate and a budget of CPU time per request.

Serverless containers and serverless on Kubernetes

Functions are the smallest unit, not the only one. Many teams get most of the benefit with far less rewriting by running existing containers on a serverless platform:

• Google Cloud Run, above, is container-first: any language you can package as a container image.
• Azure Container Apps, Microsoft's serverless platform for containers, scales with KEDA (Kubernetes Event-driven Autoscaling) on HTTP traffic, queue messages or event sources such as Azure Service Bus, Event Hubs, Apache Kafka and Redis, up to 1,000 replicas. Most apps can scale to zero, where they incur no usage charges; apps that scale on CPU or memory load cannot. It can also host Azure Functions.
• AWS Fargate runs Amazon ECS tasks without EC2 instances or clusters to manage, each task in its own isolation boundary. It removes the servers, not the capacity decisions: you size each task and pay per second (with a one-minute minimum on Linux) from the image download until the task stops, busy or not.

On your own clusters, Knative provides the same model. Knative Serving scales HTTP containers from zero to thousands of instances, Knative Eventing routes events in the CloudEvents format, and Knative Functions builds functions as standard containers, all on any Kubernetes cluster. Created at Google in 2018, Knative graduated in the CNCF on October 8, 2025. Red Hat OpenShift Serverless is Red Hat's enterprise serverless platform built on Knative.

Self-hosting moves the idle cost rather than removing it. The CNCF whitepaper notes that whoever provides the platform pays for it even when it is idle, so your developers see scale to zero while your platform team runs the cluster underneath. The right home differs from one workload to the next: our cloud transformation service places every workload on a path, with its dependencies, risks and cost understood before anything moves, including containerizing it for OpenShift or Kubernetes.

Limits and quotas that shape the design

Serverless platforms trade control for limits, and the limits shape the architecture more than the language does. As of September 2026:

From each provider's quota page: Lambda, Azure Functions, Cloud Run and Workers. On Workers, an HTTP request has no wall-clock limit while the client stays connected; the CPU budget is what runs out.

What the limits mean in practice:

1. Split long work into a queue, a batch job (a Cloud Run job task can run for up to 168 hours) or a durable workflow (see below).
2. Answer HTTP quickly: accept, queue, return. An HTTP-triggered Azure function must respond within 230 seconds whatever its timeout, because of the Azure Load Balancer's idle timeout.
3. Pass references, not payloads. Store large files in object storage and send the key; synchronous Lambda requests and responses are capped at 6 MB.
4. Expect retries and duplicates. When an asynchronous Lambda invocation fails, Lambda by default runs it two more times, and it can deliver an event more than once even without an error. Make handlers idempotent, so processing an event twice leaves the same result as processing it once.
5. Protect what sits downstream. A function at 1,000 instances can open 1,000 database connections. Cap it with reserved concurrency on Lambda or maximum instances on Cloud Run.

What serverless costs, and when it costs more than a container

Serverless prices have the same shape everywhere, a charge per request plus a charge for resources while code runs, but the units differ, and the units decide the bill:

• AWS Lambda: $0.20 per million requests plus $0.0000166667 per GB-second (x86 in US East, N. Virginia), in 1 ms steps, with a monthly free tier of one million requests and 400,000 GB-seconds (Lambda pricing). Duration runs from when your code starts until it returns, so waiting on a slow API is billed.
• Cloudflare Workers bills CPU time, not wall-clock time: the Standard model includes 10 million requests and 30 million CPU milliseconds a month, then charges $0.30 per additional million requests and $0.02 per additional million CPU milliseconds.
• Google Cloud Run bills CPU and memory in 100 ms steps, either per request (idle instances are free and each request carries a fee) or for the instance's whole lifetime (no request fee). Google recommends the first for sporadic or spiky traffic and the second for steady traffic.
• Azure Functions Flex Consumption bills memory for the time instances spend executing, plus a baseline for always ready instances.

The per-use premium is the whole trade. One workload, at list prices in US East (N. Virginia) calculated from the published unit prices in September 2026:

The Lambda figure also assumes one request at a time; a Fargate task that serves many requests at once does more work for the same price. The result flips when the workload is idle most of the day: the same function busy for one hour a day uses 216,000 GB-seconds a month, inside Lambda's 400,000 GB-second free tier if nothing else in the account uses it, while a Fargate task left running still costs the full amount.

Beyond steady traffic, serverless bills grow in predictable places: warm capacity billed while idle, functions on duration-billed platforms that spend their time waiting for a database or an API, runaway loops (see security below), and the services around the function. AWS notes that the other services a function uses, and data transfer, are billed separately: if your function reads and writes Amazon S3, the S3 requests and storage appear on the S3 bill.

The providers now sell a middle ground for steady workloads. Lambda Managed Instances run functions on EC2 instances that Lambda manages in your account, priced at the EC2 rate plus a 15% management fee on the on-demand price and $0.20 per million requests, with no per-request duration charge; EC2 Savings Plans and Reserved Instances apply. Cloud Run's instance-based billing plays the same role.

Lock-in and portability

Serverless lock-in rarely sits in the function code. It sits in everything around it: the event formats your handlers parse, the triggers and permissions wired between services, and workflow engines with their own definitions. Moving a Lambda function to Cloud Run means rewriting those connections far more than the business logic.

Four habits keep the way out open:

1. Keep business logic in ordinary modules, and make the handler a thin adapter that turns the platform's event into a function call you could make from anywhere.
2. Prefer containers where the platform allows them. Cloud Run, Azure Container Apps, Fargate and Knative all run standard container images, so the artifact moves even when the configuration does not. Knative's own documentation names cloud-specific lock-in as a problem it addresses, because it runs on any Kubernetes cluster.
3. Use open formats. CloudEvents, a specification for describing event metadata in a common way, graduated in the CNCF on January 25, 2024 and is used by Knative among others. Google's open-source Functions Framework, which wraps Cloud Run functions, runs on any platform that supports the language, including your own servers.
4. Define the infrastructure as code, so triggers, permissions and limits are written down and reviewed rather than clicked together in a console.

Observability and security: what stays your job

The CNCF glossary lists what the provider takes over: operating system maintenance, security updates, load balancing, capacity planning and monitoring. That covers the platform, not what you deploy on it. Your code, its permissions and its telemetry stay yours, and a few duties matter more on serverless, not less.

On security:

• Permissions. Each Lambda function acts through an execution role. AWS recommends trimming it to the permissions the function actually uses before production, and IAM Access Analyzer can generate that policy from the function's CloudTrail activity. One role per function limits what a compromised function can reach.
• Patching what you ship. In the Auto runtime update mode, Lambda applies runtime security updates for you; if you deploy container images, rebuilding from the latest base image and redeploying is your job. Your application's dependencies are always your job.
• Input. Every event is untrusted input, whether it comes from a public URL or from a queue another team writes to. The usual secure coding practices apply unchanged.
• Cost as an attack surface. On a platform that scales without limit, a DDoS attack can turn into a bill rather than an outage, a denial of wallet. Cloudflare recommends per-invocation CPU limits for exactly this reason. Cap concurrency, set budget alerts, and keep Lambda's recursive loop detection on: it stops a function that has been invoked about 16 times in the same chain of requests.

On observability, one user action can cross an API gateway, several functions and a couple of queues, each writing its own logs. Plan for:

• Distributed tracing with OpenTelemetry. Its FaaS semantic conventions, still marked as in development, define attributes such as faas.trigger and faas.coldstart, so traces from different platforms read the same way.
• Background agents. With Cloud Run's request-based billing, CPU is allocated only while a request is being processed, so a telemetry agent that works in the background needs instance-based billing. Google calls out OpenTelemetry agents as the example.
• The numbers that matter: throttled requests (HTTP 429), cold start rate, duration against the timeout, concurrency against the quota, and cost per thousand requests.

The future of serverless: what changed from 2024 to 2026

The direction is clear from what the providers shipped: serverless no longer means only short, stateless functions. As of September 2026:

More kinds of compute under the same model

Lambda Managed Instances run functions on EC2 instance types you choose, including Graviton4, with many invocations per execution environment. They scale on CPU use without cold starts and, without traffic, keep a configured minimum rather than scaling to zero; AWS positions them for steady, high-volume workloads. Lambda MicroVMs give each user or job its own Firecracker-based virtual machine with its own HTTPS URL, which can be suspended and resumed for up to 8 hours: a building block for running code written by users or AI tools in isolation. Accelerators have arrived too: Cloud Run attaches NVIDIA L4 or RTX PRO 6000 Blackwell GPUs to instances that start in about 5 seconds and still scale to zero.

Durable execution becomes part of the platform

The oldest serverless limit, the timeout, is being routed around rather than raised. Lambda durable functions checkpoint progress after each step and can suspend an execution for up to a year. While a workflow waits for a human approval or an external system, it pays no compute charges. When it resumes, Lambda replays the handler from the beginning, skipping completed steps and using their stored results.

Because the handler runs again from the top on every resume, anything outside a step runs again too, so side effects belong inside steps. The same model exists elsewhere: Durable Functions on Azure manages state, checkpoints, retries and recovery for orchestrations written in code, and Cloudflare Workflows persists state for minutes, hours or even weeks.

WebAssembly as a lighter unit of deployment

WebAssembly (Wasm) compiles languages such as Rust, Go and C to a portable binary, and it already runs on Cloudflare Workers. Its system interface, WASI, is maturing: WASI 0.2 was released at the end of January 2024, and as of September 2026 WASI 0.3, which adds native async support, is the current release, though most toolchains still target 0.2. On Kubernetes, SpinKube runs Spin WebAssembly apps next to containers through an operator and a containerd shim. It is early (WASI support on Workers is still experimental), but small binaries that start fast and run anywhere are exactly what serverless platforms want.

When to use serverless, and when not to

Most estates end up with a mix: functions for events and glue, serverless containers for web services, and managed databases under both. If the serverless part is a website or web application, our web design and development team builds typed front ends rendered on the server and at the edge. If it is a wider move of existing applications onto containers and cloud platforms, start with our cloud transformation assessment, and find more on the subject under cloud.