What Is Serverless Computing?

The name is the first obstacle. Serverless computing runs on servers, a great many of them, owned and operated by the cloud provider. What the word actually describes is your relationship to those servers: you never see them, size them, patch them, or pay for them while they sit idle. You hand the provider a function, the provider runs it when something triggers it, and you are billed for the milliseconds it ran. Then it stops, and so does the meter.

That last sentence is why serverless matters to anyone who pays a cloud bill, and it is also where the model gets misunderstood in both directions: treated as always cheaper when it is not, or dismissed as a toy when it quietly runs much of the modern internet. This guide explains what serverless computing is, how it works under the hood, how it is priced across AWS Lambda, Azure Functions, and Google Cloud Run, where the hidden costs sit, and how to decide when it is the right model and when a container or a plain server is.

What Serverless Computing Actually Is

Serverless is a cloud execution model, not a technology or a product. In the traditional model, which our explainer on what the cloud is covers, you rent a virtual machine or a container, keep it running, and pay for every hour whether it is busy or not. In the serverless model, you deploy code and declare what should trigger it. The provider keeps the code ready, runs an instance when a trigger fires, runs more instances in parallel if many triggers arrive at once, and shuts them all down when the triggers stop. You are billed per execution, for the memory allocated multiplied by the time the code ran, usually to the millisecond.

Three properties follow from that and define the model. Serverless is event-driven: code runs because something happened, an HTTP request, a message on a queue, a file landing in storage, a timer. It scales to zero: no traffic means no instances and no compute charge, which no virtual machine can do. And it is fully managed: the provider owns the operating system, the runtime, patching, capacity, and availability, which is what makes it the closest real-world expression of the NoOps idea we describe in our

NoOps glossary entry.

How Serverless Works Under the Hood

Understanding the mechanics explains both the economics and the limitations. When you deploy a serverless function, the provider stores your code and its configuration, including how much memory it may use and what events trigger it. Nothing runs yet. When a trigger fires, the platform finds or creates an execution environment, a lightweight isolated container with your runtime loaded, and invokes your function with the event as input. If another trigger arrives while that environment is busy, the platform creates a second one, and a third, scaling horizontally with demand up to a concurrency limit.

Creating a fresh environment takes time, from tens of milliseconds to a few seconds depending on the runtime and the size of your code, and that delay is the cold start. Once an environment exists, the platform keeps it warm for a while and reuses it for subsequent invocations, which is why the second request is fast and the first is not. When traffic stops, warm environments are eventually reclaimed, and the function returns to costing nothing. Because environments are created and destroyed freely, functions must be stateless: anything that needs to persist between invocations lives in a database, a cache, or object storage rather than in the function's memory.

Three Flavors of Serverless

The word covers more than functions, and the distinctions matter when choosing a platform.

• Functions as a Service (FaaS). The core model: short-lived functions triggered by events, exemplified by AWS Lambda, Azure Functions, and Google Cloud Run functions. Best for event handlers, APIs, and glue code between services.
• Serverless containers. Platforms such as Google Cloud Run and AWS Fargate run a full container image on demand with serverless scaling and billing, removing the function-size and runtime constraints of FaaS while keeping scale-to-zero. Best for web services and applications already packaged as containers.
• Backend as a Service (BaaS). Managed services that are serverless from the consumer's point of view, such as DynamoDB, Firestore, S3, and Aurora Serverless, where you use the service and never see its servers. Most serverless applications combine FaaS for logic with BaaS for state.

A fourth, edge functions from providers such as Cloudflare Workers, runs tiny functions at hundreds of locations close to users, with its own pricing and constraints. The container flavor is where serverless meets the orchestration world we cover in our guide to container orchestration.

The Major Platforms and What They Cost

Serverless pricing has two components almost everywhere: a fee per request and a fee for compute consumed, measured as memory multiplied by execution time. The table shows the standard consumption-based tiers in US regions as of October 2026; rates change and vary by region, so confirm on each provider's pricing page, such as the Lambda pricing page.

Two readings of that table are worth drawing out. Lambda and Azure Functions are priced almost identically, so the choice between them is ecosystem rather than cost. And Cloud Run's larger free tier and ability to serve many requests from one instance can make it markedly cheaper for I/O-bound, high-concurrency work, while its double per-request fee makes it pricier for request-heavy, compute-light functions. The platform that is cheapest depends on the shape of your traffic, not on the headline rate.

A Worked Example: What a Serverless API Costs

Consider an API handling 10 million requests a month on AWS Lambda, each running for 200 milliseconds at 512 MB of memory, on x86. Compute is 10 million times 0.2 seconds times 0.5 GB, which is 1 million GB-seconds; subtract the 400,000 free and 600,000 GB-seconds bill at $0.0000166667 each, about $10. Requests: 9 million billable at $0.20 per million, about $1.80. Lambda compute for a 10-million-request API comes to roughly $12 a month.

Now add what the function needs around it. An HTTP API through Amazon API Gateway bills about $1 per million requests, so $10. CloudWatch Logs at $0.50 per GB ingested, with each invocation writing a kilobyte of logs, is about 10 GB and $5, plus storage if retention is left at never-expire. Data transfer out at $0.09 per GB for, say, 50 GB of responses is about $4.50. If the function reaches a database inside a VPC, a NAT Gateway adds about $32 a month regardless of traffic. The realistic total is $30 to $65 a month, of which the Lambda compute everyone quotes is between a fifth and a third. The same pattern holds on every platform: the function is the cheap part.

Serverless vs Containers vs Virtual Machines

The right comparison is not which is cheapest in the abstract but which cost model fits the workload.

When Serverless Is Cheaper, in Numbers

Take a workload that needs the equivalent of one vCPU and 2 GB of memory while active. As an always-on t3.small-class server it costs roughly $15 a month for compute. On Lambda at 2 GB, each second of execution costs about $0.0000333, so a month of continuous execution would be about $86, far more than the server. But serverless does not run continuously. If the workload is active 20 percent of the time, Lambda costs about $17, roughly even with the server before the server's disk, IP, and management overhead. At 10 percent utilization Lambda costs about $9 and wins; at 50 percent it costs about $43 and loses badly.

The rule of thumb that falls out: workloads idle more than roughly half the time favor serverless on compute alone, and the advantage grows as utilization falls, which is why serverless dominates for scheduled jobs, webhooks, event processing, and APIs with uneven traffic. Workloads that run hot all day belong on containers or servers, ideally on a commitment discount. The honest version of serverless economics is not that it is cheap but that it charges you for exactly as much as you use, which is a bargain precisely when you use little.

The Benefits

• No infrastructure to run. No servers to patch, no capacity to plan, no scaling policies to tune. For small teams this removes a whole category of work.
• Scale to zero and to thousands. Idle costs nothing, and a traffic spike is handled by the platform launching more environments, automatically and in parallel.
• Pay for exactly what runs. Billing to the millisecond means variable and low-volume workloads cost what they consume rather than what was provisioned for them.
• Speed of delivery. Deploying a function is faster than provisioning a server, which shortens the loop from idea to production, especially for event-driven glue between services.
• Built-in availability. Functions run across multiple availability zones by default, with no cluster to design for resilience.

The Drawbacks and Limits

• Cold starts. The first request after idle pays an initialization delay, from tens of milliseconds to seconds for heavy runtimes. Latency-sensitive paths may need provisioned concurrency, which reintroduces an always-on cost.
• Execution limits. Lambda functions cap at 15 minutes and a fixed memory ceiling. Long-running jobs, large in-memory computations, and persistent connections need a different model.
• Statelessness. Nothing survives between invocations, so state must live in external services, which adds latency and cost and shapes how you design.
• Vendor lock-in. Functions are portable in principle, but the event sources, permissions, and managed services around them are provider-specific, and migrating a mature serverless application is real work.
• Observability and debugging. Distributed, short-lived functions are harder to trace than a single process, and logging them well is both essential and, as the hidden-costs section shows, not free.
• Cost at scale. The same per-request pricing that makes low volume cheap makes very high steady volume expensive, and because spend scales with traffic rather than with a provisioning decision, it can grow faster than anyone planned.

Where Serverless Costs Hide

Serverless bills surprise teams for a specific reason: the compute fee is small and visible, and everything around it is larger and spread across other services. The usual culprits, in rough order of size, are API gateway fees per request, logging ingestion and storage (our guide to CloudWatch pricing shows how a chatty function's logs can cost more than its compute), data transfer out, NAT Gateway charges for functions that reach into a VPC, provisioned concurrency to avoid cold starts, and the managed databases and queues the functions depend on. Add retries, which bill every attempt, and generous default memory settings, which multiply the GB-second rate, and a function priced at a few dollars can anchor a bill of a few hundred.

The fix is to treat the infrastructure template as the place cost is decided. Set log retention explicitly, right-size memory to what the function uses, cap concurrency and API throttling, and prefer VPC endpoints to NAT where possible, all of which can be written into the deployment definition, as we describe in our comparison of AWS SAM and CloudFormation.

Serverless and FinOps

Serverless changes the FinOps problem in one important way. On servers, cost is set when you provision and is visible as a resource with a tag. In serverless, cost is set by code and traffic, there is no long-lived resource to tag, and spend is spread across functions, gateways, logs, and data services that each appear on different lines. Attribution therefore has to happen at the function and event level, mapping each function to a team and a feature and summing everything it triggers, which is the same discipline we describe for AI unit economics and for the same reason: usage-based spend has no infrastructure to hang a label on. Done well, serverless gives you the cleanest unit economics in the cloud, a precise cost per request; done badly, it gives you a bill that grows with success and that nobody can decompose. Seeing it per function, per team, and alongside the rest of the estate is what Opslyft's cost visibility is built for.

When to Use Serverless, and When Not To

• Use serverless for event-driven processing, webhooks, scheduled jobs, APIs with variable or low traffic, glue between managed services, prototypes, and anything that would otherwise leave a server idle most of the time.
• Use containers or servers for steady high-volume services running near capacity, long-running or stateful processes, latency-critical paths that cannot absorb cold starts, workloads needing specialized hardware, and systems where portability across providers is a requirement.
• Use both for most real applications: serverless for the spiky edges and event handling, containers or servers for the steady core, each on the pricing model that fits its utilization.

The Bottom Line

Serverless computing is the cloud's purest form of pay-for-use: code that runs when triggered, scales without intervention, and costs nothing while idle. That makes it the cheapest and simplest option for a large class of variable and event-driven work, and a poor fit for steady, heavy, or long-running load, where its per-request margin turns against you. The platforms are mature and priced nearly alike, so the decision is about workload shape rather than vendor. Choose it where utilization is low and bursty, watch the costs that gather around the function rather than inside it, and attribute spend at the function level so that a bill which grows with success is a bill you can explain. The broader principles are in our guides to cloud pricing models and cloud elasticity, which serverless takes to its logical conclusion.