AWS Just Split Lambda in Two. Here’s Which Half You Should Use.

Your Lambda API has been paying to wait. On October 12, AWS finally fixed that. Here’s what changed, in plain English, with pictures.

Picture 500 users hitting your API at the same moment. Each request calls a database, then waits 150 ms for the answer.

On classic AWS Lambda, that means 500 separate execution environments. Possibly 500 cold starts. And you pay for every millisecond each one sits there doing nothing but waiting.

That’s not a bug. It’s how Lambda has always worked: one request, one box.

On October 12, 2026, AWS changed that. It launched Lambda Web Functions, a new kind of Lambda where your code is just a normal web server. One environment can handle up to 128 requests at once, and you pay for the CPU your code actually uses, not the time it spends waiting.

And quietly, the Lambda you already know got a new name: Lambda Event Functions. Nothing about it changes. No redeploys, no code changes. It’s just a name to tell the two apart.

If you build APIs, web apps, or AI endpoints on AWS, this is the biggest change to Lambda in years. By the end of this post you’ll know exactly how the two differ, what each one costs, and which one to pick.

Let’s go.

First, how Lambda has always handled web traffic

Classic Lambda only understands events. A JSON object comes in, your handler runs, a JSON object goes out.

A browser doesn’t speak events. It speaks HTTP. So something has to sit in front of your function and translate: API Gateway, an Application Load Balancer, or a Function URL. It turns the HTTP request into an event, and turns your return value back into an HTTP response.

This works. Millions of APIs run this way. But it comes with three costs most people stop noticing:

1. Your code is shaped around Lambda. You write a handler(event), not an Express app. To use a real framework, you add an adapter like Serverless Express or the AWS Lambda Web Adapter.
2. Every concurrent request gets its own environment. 500 slow requests in flight = 500 environments, and potentially 500 cold starts.
3. You pay for waiting. Billing is memory × wall-clock time. If your function waits 180 ms on a database and computes for 20 ms, you pay for all 200.

Meet Lambda Web Functions: just run your server

A Web Function flips the model. Instead of a handler, you give Lambda a normal HTTP server that listens on a port. Express, Hono, Fastify, Next.js, plain Node.js. The same code you run on your laptop.

Lambda does the rest:

• Gives you an HTTPS endpoint out of the box. No API Gateway needed.
• Scales your server out with traffic, and back down to zero when it’s idle.
• Lets each environment handle many requests at once (64 by default, up to 128).
• Can replicate to several Regions behind one global URL, routing each user to the closest one.
• Bills active CPU time, not wall-clock time.

Two new words to learn. A revision is an immutable snapshot of your code and config, like a published version. An endpoint is the HTTPS URL that routes traffic to one or two revisions, like an alias that also owns the URL, the auth, and the rate limit. Want a canary release? Send 90% of traffic to the old revision and 10% to the new one. One API call.

The big difference: one request per box vs. many

If you remember one thing from this post, make it this picture.

When a burst of traffic arrives, Web Functions fill up warm environments first instead of spinning up a new one for every request. Fewer environments means fewer cold starts. Lambda also keeps some warm headroom ahead of demand, so small traffic bumps rarely hit a cold start.

Here’s the full side-by-side:

The billing change (and why “cheaper” isn’t automatic)

Most API requests spend their time waiting: on DynamoDB, on another service, and more and more on an LLM streaming tokens back. The two models treat that waiting very differently.

Event Functions bill requests + configured memory × wall-clock duration. Waiting costs the same as working.

Web Functions bill four things, all at 1 ms granularity: requests, active vCPU time, the memory each environment holds for as long as it exists, and data transfer. Waiting on I/O uses almost no CPU, so it costs very little.

A worked example

AWS’s pricing page uses an I/O-heavy API: 10 million requests a month, each taking 200 ms end to end, with only 50 ms of real CPU work. US East (N. Virginia), Arm, before free tier:

Surprised? So was I. Web Functions are not automatically cheaper. The request price is 50% higher, and you pay for memory while an environment sits idle between requests.

Get Dharmik Soni’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

They win when requests mostly wait and you’d otherwise bump Event Function memory up just to get more CPU. They can lose on quiet or tiny endpoints. Model your real traffic and load test before you switch.

Show me the code

Before: an Event Function behind API Gateway. Your logic lives inside Lambda’s event format.

export const handler = async (event) => {
  const name = event.queryStringParameters?.name ?? 'world';
  return {
    statusCode: 200,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ message: `Hello, ${name}` }),
  };
};

After: a Web Function. It’s just Express. The only Lambda-specific line reads the host and port from AWS_LAMBDA_HTTP_ENDPOINT.

import express from 'express';

const app = express();
const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');
app.get('/', (req, res) => {
  res.json({ message: `Hello, ${req.query.name ?? 'world'}` });
});
app.listen(port, host);

Run it locally with AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js. Deploy it with one command:

aws lambda-web deploy --name my-web-app --code ./my-app

That bundles your code, creates the function, publishes a revision, attaches an endpoint, and hands back a live HTTPS URL. AWS says it takes under a minute.

Want it global? Add --regions us-east-1,eu-west-1,ap-northeast-1. Lambda copies your code to all three and routes each user to the fastest one through a single URL.

One catch: your code must now be safe for concurrent requests. Module-level variables that assume “one request at a time” will bite you. Audit those before you port anything.

So which one should you use?

Web Functions don’t replace Event Functions. They take over one job: answering HTTP requests directly. Everything else stays where it is.

AWS’s own picture of a modern app uses both: Web Functions for the user-facing API and server-side rendering, Event Functions for background work like queues and file processing, and Lambda MicroVMs (the third new form factor) for running untrusted code in a sandbox.

A simple pattern: the Web Function takes the request, validates it, and replies fast. Anything slow or multi-step gets handed off with SendMessage, PutEvents, or a Step Functions StartExecution, where Event Functions do the heavy lifting.

Read this before you migrate

This launched five days ago. Day-one services have rough edges. The ones that matter most:

• Node.js only. Node.js 24 on Arm64, .zip packages. Python, Java, .NET or containers? Stick with Event Functions plus the Lambda Web Adapter for now.
• Five Regions. N. Virginia, Ohio, Oregon, Tokyo and Ireland.
• No knobs for size. Every environment is 2 GB and 2 vCPUs. You tune with max concurrency per environment instead.
• No provisioned concurrency. It always scales to zero, so the first request after a quiet period is a cold start. Keep startup fast.
• HTTP/1.1 only, no WebSockets. No custom domain or WAF on the endpoint directly. Put CloudFront in front; it now supports Web Functions as a private origin with OAC.
• HTTP-only triggers. A Web Function can’t be an SQS consumer, an S3 trigger, or a Step Functions Lambda task.
• “Active” doesn’t mean healthy. Lambda doesn’t check that your server actually starts at deploy time.

Limits will change fast. Check the developer guide before you lean on any number here.

The bottom line

For ten years, Lambda asked web developers to bend their code to fit it. Web Functions flip that around: a server on a port, a framework you already know, and the same code on your laptop and in the cloud.

The trade? You unlearn “one request, one environment” and write concurrency-safe code.

Try it this weekend. In a sandbox account, run:

aws lambda-web deploy --name hello-world --hello-world

Then pick one Node.js API that spends most of its time waiting on I/O, port it, load test it, and compare the bill.

If this helped you understand Lambda’s biggest change in years, give it a clap and follow for more hands-on AWS breakdowns. Are you moving anything to Web Functions? Tell me in the comments.

Sources

• Announcing AWS Lambda Web Functions, AWS News Blog
• AWS Lambda announces Lambda Web Functions, What’s New at AWS
• Lambda Web Functions developer guide, AWS Docs
• Bring Your HTTP Server, Leave the Handler Behind, AWS Builder Center (pricing comparison and launch caveats)
• AWS Lambda pricing