Serverless in 2026: Lambda vs Cloud Run vs Workers, and When It Costs More

I have run things on AWS Lambda since the days when a VPC-attached function could take ten seconds to wake up, and I still reach for it first for glue code. But "serverless" in 2026 no longer means one thing. AWS alone now sells four shapes of Lambda, Google rents GPUs by the second on Cloud Run, Cloudflare runs full containers behind Workers, and Vercel bills for CPU only while your code is actually doing something. This post explains what serverless means in 2026, what changed in the last twelve months on Lambda, Cloud Run, Azure Container Apps, Cloudflare and Vercel, what each costs at list price for the same unit of work, and the workloads where serverless quietly costs more than a boring instance.

What does serverless mean in 2026?

The useful definition is operational, not architectural: you hand the provider a function or a container image, it decides how many copies run, it patches the OS, and you pay for something closer to use than to capacity. Everything else is a dial. In 2026 there are three dials that matter.

The first is what you deploy: a handler (classic Lambda, Workers), an HTTP server (Lambda Web Functions, Vercel Functions), or an OCI image (Cloud Run, Azure Container Apps, Cloudflare Containers). The second is concurrency per instance: one request per environment (classic Lambda), or many requests sharing an instance (almost everything else). The third is what the meter counts: wall-clock time while a request is open, allocated instance lifetime, or only the CPU cycles you burn.

That third dial is where the 2025 and 2026 changes land, and it decides the bill more than the brand does. If you only remember one thing from this post: a platform that bills wall-clock time per request punishes I/O-heavy code, and a platform that bills instance lifetime punishes idle capacity. Agent and LLM workloads, which spend most of their life waiting on a model API, are the extreme case of the first problem.

What changed on AWS Lambda between 2025 and 2026?

More than in any year since provisioned concurrency arrived. In order:

INIT is billed everywhere (August 2025). From 1 August 2025, AWS standardised billing for the INIT phase: on-demand invocations of ZIP-packaged functions on managed runtimes now pay for initialisation time, as container images, custom runtimes and provisioned concurrency already did. A cold start that used to be a latency problem is now also a line item. I cover how to measure and shrink it in the sibling guide, How to Reduce AWS Lambda Cold Starts.

SnapStart covers Java, Python and .NET. SnapStart takes a Firecracker microVM snapshot of the initialised environment when you publish a version and restores from it on scale-out. The current docs list Java 11+, Python 3.12+ and .NET 8+ across ZIP and container image formats; Node.js and OS-only runtimes are not supported, and neither are provisioned concurrency, EFS or ephemeral storage above 512 MB. Python and .NET went GA in November 2024 and, unlike Java, pay a cache and a restore charge.

Lambda Managed Instances (re:Invent 2025). Announced on 30 November 2025, this runs Lambda functions on EC2 instances in your own account that AWS operates. The docs spell out the trade: one execution environment handles many invocations at once, isolation is containers on Nitro instead of Firecracker, scaling follows CPU utilisation "without cold starts", and it does not scale to zero. Pricing is the EC2 price plus a 15% management fee plus $0.20 per million requests, and Savings Plans and Reserved Instances discount the EC2 part but not the fee. Publishing a version launches three instances by default for AZ resilience, which matters for the cost section below.

Durable functions (re:Invent 2025). Launched on 2 December 2025, durable functions checkpoint each step and replay from the start after a pause or failure, skipping completed steps. A single durable execution can run for up to one year, and waits suspend without compute charges. The meter is new: $8.00 per million durable operations, $0.25 per GB written and $0.15 per GB-month retained, on top of normal compute for each replay. This is AWS putting a Temporal-shaped programming model inside Lambda, and it is the most interesting option for agent workflows that wait on humans.

Lambda Web Functions (eight days ago). On 12 October 2026 AWS announced Web Functions: you deploy an ordinary HTTP server (Express, Next.js and friends) with no adapter, and one environment serves up to 128 concurrent requests. At launch it is Node.js 24 on arm64 in five regions. Billing is active CPU plus memory for the environment's lifetime. Classic Lambda has been renamed "Event Functions" in the docs. Read alongside the App Runner availability change, which closed App Runner to new customers on 30 April 2026, it is clear where AWS wants HTTP apps to go.

Cloud Run, Azure Container Apps, Cloudflare and Vercel in 2026

Google Cloud Run remains the cleanest "give us a container" product. It offers two billing modes: request-based (CPU and memory billed only while requests are in flight, plus $0.40 per million requests) and instance-based (billed for instance lifetime at a lower rate, no request fee). GPUs are now ordinary: the GPU docs list the NVIDIA L4 (24 GB) and RTX PRO 6000 Blackwell (96 GB), one per instance, instance-based billing required, scale to zero supported, and instances with drivers preinstalled starting in "approximately 5 seconds". Worker pools cover the other gap: long-running background consumers with no load-balanced URL and no autoscaling, where you set the instance count yourself.

Azure Container Apps is the Azure answer to Cloud Run. The consumption plan bills active vCPU-seconds and GiB-seconds, a much cheaper idle rate for replicas kept warm, and $0.40 per million requests after 2 million free, according to the Azure retail price API. Serverless GPUs (T4 and A100) are billed per second.

Cloudflare now has two serverless products. Workers run in V8 isolates and the pricing page bills only CPU time: $5 a month includes 10 million requests and 30 million CPU-milliseconds, then $0.30 per million requests and $0.02 per million CPU-ms, with no charge for wall time or egress. Containers and Sandboxes went GA on 13 April 2026, each container driven by a Durable Object, billed in 10 ms slices.

Vercel Fluid compute has been the default for new projects since 23 April 2025. Multiple invocations share one instance, and the pricing splits into Active CPU (paused while your code waits on I/O), provisioned memory for the instance lifetime and $0.60 per million invocations. In Washington D.C. (iad1) that is $0.128 per CPU-hour and $0.0106 per GB-hour.

The convergence is obvious. Lambda Web Functions, Vercel Fluid, Cloudflare and Cloud Run with concurrency all moved to "many requests per instance, bill CPU or instance time". Classic Lambda Event Functions are now the odd one out with one request per environment billed on wall time.

Serverless pricing comparison: same work, list prices

Here are the list prices I pulled for US East regions this week. The AWS numbers come from the AWS price list API for us-east-1, which is more reliable than the rendered pricing page.

Platform	CPU	Memory	Requests	Source
Lambda Event Functions, x86	bundled: $0.0000166667 per GB-s	bundled	$0.20 / M	AWS price list
Lambda Event Functions, arm64	bundled: $0.0000133334 per GB-s	bundled	$0.20 / M	AWS price list
Lambda Web Functions, arm64	$0.0000276944 per active vCPU-s	$0.0000036667 per GB-s	$0.30 / M	AWS price list
Lambda Managed Instances	EC2 on-demand + 15%	included	$0.20 / M	Lambda docs
Cloud Run, request-based (us-central1)	$0.000024 per vCPU-s	$0.0000025 per GiB-s	$0.40 / M	Cloud Run pricing
Cloud Run, instance-based (us-central1)	$0.000018 per vCPU-s	$0.000002 per GiB-s	none	Cloud Run pricing
Cloud Run GPU, L4 (no zonal redundancy)	$0.0001867 per GPU-s			Cloud Run pricing
Azure Container Apps, consumption (eastus)	$0.000024 per vCPU-s active	$0.000003 per GiB-s	$0.40 / M	Azure price API
Cloudflare Workers	$0.02 per M CPU-ms	none	$0.30 / M	Workers pricing
Cloudflare Containers	$0.000020 per vCPU-s	$0.0000025 per GiB-s	via Worker	Workers pricing
Vercel Fluid, iad1	$0.128 per Active CPU-hour	$0.0106 per GB-hour	$0.60 / M	Vercel pricing

Unit prices hide the shape of the bill, so the figure normalises them: one vCPU and 2 GB kept 100% busy for 30 days, compute only, before free tiers. For Lambda Event Functions I used 2 GB, which by the memory docs is slightly more than one vCPU (1,769 MB equals one vCPU). For the reference instance I derived the m7g.large on-demand price ($0.0816 an hour, 2 vCPU, 8 GiB) from its Lambda Managed Instances management fee in the same AWS price list.

At full utilisation the spread is about 2x, and a plain instance sits at the bottom with four times the memory. That is the honest baseline. It is also the least interesting comparison, because almost nothing runs at 100% CPU for a month, and most web and agent code spends its time waiting.

When does serverless cost more than containers or EC2?

The bill turns on concurrency and on what fraction of wall time is CPU. I worked an example with a short script. It describes a typical API or agent tool endpoint: 50 requests per second, 200 ms per request, of which 20 ms is CPU and the rest waits on a database or a model.

# serverless_cost.py: list prices, us-east, October 2026. Python 3.12+, stdlib only.
# Workload: 50 req/s for 30 days, 200 ms wall time per request, 20 ms of it on CPU.
SECONDS = 30 * 24 * 3600            # 2,592,000
RPS, WALL_S, CPU_S = 50, 0.200, 0.020
reqs = RPS * SECONDS                # 129.6M requests

# Lambda Event Function, arm64, 512 MB: one request per environment, billed on wall time.
lam_event = reqs * WALL_S * 0.5 * 0.0000133334 + reqs / 1e6 * 0.20

# Lambda Web Function, arm64: active vCPU-seconds + memory for env lifetime + requests.
# Assume 2 environments of 2 GB alive all month (128 concurrent requests max each).
lam_web = reqs * CPU_S * 0.0000276944 + 2 * 2 * SECONDS * 0.0000036667 + reqs / 1e6 * 0.30

# Cloud Run, instance-based billing: 2 instances of 1 vCPU / 2 GiB alive all month.
run_inst = 2 * SECONDS * (1 * 0.000018 + 2 * 0.000002)

# Lambda Managed Instances: 3 x m7g.large (AZ spread default) + 15% fee + requests.
lmi = 3 * 720 * 0.0816 * 1.15 + reqs / 1e6 * 0.20

for name, usd in [("Lambda Event arm64 512MB", lam_event), ("Lambda Web Functions", lam_web),
                  ("Cloud Run instance-based x2", run_inst),
                  ("Lambda Managed Instances 3x m7g.large", lmi)]:
    print(f"{name:40s} ${usd:8.2f}")

# Output when I ran it:
# Lambda Event arm64 512MB                 $  198.72
# Lambda Web Functions                     $  148.68
# Cloud Run instance-based x2              $  114.05
# Lambda Managed Instances 3x m7g.large    $  228.61

Classic Lambda bills all 200 ms for every request, including the 180 ms spent waiting, so the request count and the waiting dominate. Web Functions and Cloud Run let one instance absorb that waiting. Lambda Managed Instances loses here only because three instances is far more capacity than 10 concurrent requests need; at ten times the traffic, the same three instances would win comfortably. These are assumptions on my part, not measurements, so change the numbers to your own traffic before you believe any of them.

From that arithmetic and the pricing models, serverless costs more when:

• Traffic is steady and high. A flat line at a few hundred requests per second has no idle time to avoid paying for. This is exactly the case AWS built Managed Instances for, and it says so in the docs.
• Requests are I/O-bound on a wall-clock meter. LLM calls that stream for 20 seconds on classic Lambda pay for 20 seconds of memory per request. Active CPU platforms or concurrency-capable containers fix this.
• Per-request fees dominate. At $0.20 to $0.60 per million, tiny fast requests at high volume can cost more in request fees than in compute.
• You need minimum instances to hide cold starts. Provisioned concurrency, Cloud Run min instances and warm replicas turn a pay-per-use bill back into a capacity bill, at a premium over the equivalent VM.
• Egress and the API gateway in front. None of the figures above include them, and an API gateway in front adds its own per-request charge.

None of this means "move to Kubernetes". A cluster has its own floor of control plane, nodes and on-call time, which I weigh in Is Kubernetes Still Worth It in 2026?. It means pick the meter that matches your workload, which is the same discipline I argued for in FinOps for AI.

Cold starts in 2026: still a thing?

Less than they were, but they now cost money as well as latency. The Lambda docs say cold starts "typically occur in under 1% of invocations" and range from under 100 ms to over a second. Snapshot restore is the main structural fix: SnapStart on Lambda, and the same Firecracker technique underneath many agent sandboxes. I build one of those, PandaStack, my own Firecracker microVM cloud, so I am biased towards snapshots, and I wrote about what restore really costs to build. On concurrency-capable platforms, cold starts matter less because a warm instance absorbs bursts instead of spawning a new environment per request. The practical playbook for Lambda is in the cold start guide.

FAQ

Is AWS Lambda cheaper than Cloud Run?

It depends on concurrency. For bursty, low-volume, CPU-light work, Lambda's free tier and scale to zero usually win. For steady I/O-bound HTTP traffic, Cloud Run with concurrency, or the new Lambda Web Functions, is usually cheaper because many requests share one instance instead of each paying for its own wall time.

What are Lambda Managed Instances?

Lambda Managed Instances run Lambda functions on EC2 instances in your account that AWS provisions, patches and scales. You pay the EC2 price plus a 15% management fee and $0.20 per million requests, can apply Savings Plans to the EC2 part, and get multi-concurrent environments without cold starts. They do not scale to zero.

Did Lambda start charging for cold starts?

Yes. Since 1 August 2025, the INIT phase is billed for on-demand ZIP functions on managed runtimes, matching container images, custom runtimes and provisioned concurrency. You see it in the REPORT log line, where Billed Duration now includes Init Duration.

When should I not use serverless?

Avoid it for steady, high-utilisation workloads, long-lived connections on wall-clock billing, and anything that needs minimum instances everywhere to meet latency targets. In those cases a container service with instance-based billing, Lambda Managed Instances, or plain VMs on a commitment discount is usually cheaper.

This quarter, I would do three things. Look up the Init Duration share of every Lambda bill now that it is billed. Move any I/O-heavy HTTP function on classic Lambda to a concurrency-capable option (Web Functions if you are on Node.js, Cloud Run or Container Apps otherwise) and compare a month of invoices. And for anything that runs flat out all day, price it on Managed Instances or a reserved instance before assuming serverless is the cheap default it was in 2018.

Related: What Scale to Zero Cost Me to Build: 50s Sleeps, 14s Wakes, I Measured Every Stage of My 179ms Firecracker Boot Path and FinOps for AI in 2026: 98% Manage Token Spend, 3 in 4 Can't Prove the Value, GPUs Run at 5%, and FOCUS Gets a Token Column in 1.5.