AWS Lambda Web Functions
Run Web Apps Serverless in 2026

October 15, 2026 / Nirav Shah

AWS Lambda Web Functions: Run Your Web Apps Serverless Without Adapters or Load Balancers

For over a decade, running a normal web application on AWS Lambda felt like forcing a square peg into a round hole. You had to wrap your Express or Fastify app in adapter layers, wire up API Gateway, and accept that every request got its own execution environment — even if that request was just waiting on a database.

That changed in October 2026. AWS announced Lambda Web Functions, a brand-new type of Lambda function that runs a standard Node.js HTTP server exactly as you wrote it. One deploy command. A public HTTPS endpoint. No adapters, no servers, no load balancers to manage.

In this post, we’ll break down what AWS Lambda Web Functions are, the problems they solve, how they’re billed, and when you should (and shouldn’t) use them for your next web application.

What Are AWS Lambda Web Functions?

AWS Lambda Web Functions are a new type of Lambda function, launched in October 2026, that lets your code run as a standard HTTP server listening on a port — instead of an event handler that gets invoked once per event.

That single change is what makes them special. Web frameworks like Express, Fastify, and Hono run completely unmodified. Next.js in standalone mode needs only a tiny entry file. Your app reads the host and port from an environment variable, calls server.listen(), and that’s it — the same code that runs on your laptop runs on Lambda.

A Web Function is made up of three resources:

• Web Function — the top-level resource holding your name and configuration
• Revision — an immutable snapshot of your code and config, created on every deploy, so you can roll back instantly by routing traffic to an earlier revision
• Endpoint — the network entry point with a unique HTTPS domain, authentication type, and traffic-routing rules

At launch, Web Functions run Node.js 24 on Arm64 with 2 vCPUs and 2 GB of memory per execution environment, and they support VPC connectivity so your app can reach private databases and internal services.

Deployment is one command:

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

The AWS CLI bundles your code, creates the function and an endpoint, and hands you a live public HTTPS URL.

The Problem: Why Classic Lambda Was Awkward for Web Applications

Lambda launched in 2014 with a brilliantly simple model: upload your code, and AWS handles everything else. But that code ran as an event handler — invoked once per event, such as a queue message or a file landing in S3. AWS now calls this an Event Function, and it remains the right choice for event-driven workloads.

For web applications, though, this model created real friction:

1. Adapter layers everywhere. To run Express or Next.js on Lambda, you needed tools like the Lambda Web Adapter or framework-specific shims to translate API Gateway events into HTTP requests your framework could understand. More moving parts, more things to debug.
2. One request per environment. An Event Function environment serves exactly one request at a time. If 200 users opened streaming connections, Lambda had to spin up as many as 200 separate environments — wasteful and expensive.
3. Frozen between invocations. Lambda freezes the environment when no invocation is running, so background tasks (telemetry, keep-alive pings, scheduled cleanup) simply stop.
4. Paying for wait time. With wall-clock billing, your function billed for the entire duration of a request — including the seconds it spent idle, waiting on a database query or a slow third-party API.

The result? Many teams who loved the serverless operating model still reached for containers (ECS, Fargate, App Runner) the moment they needed to host a “normal” web app. Lambda Web Functions close that gap.

Key Features of Lambda Web Functions

1. No adapter layer — your framework runs as-is

Your code is a plain HTTP server. Express, Fastify, Hono, and plain Node.js servers run without modification. You develop locally with npm start, test on localhost:3000, and deploy the exact same code.

2. Real concurrency per environment

Each execution environment handles up to 128 concurrent requests (default 64), not one at a time. In AWS’s own load test, 300 streaming requests with 200 open simultaneously were served by just 5 execution environments — where Event Functions would have needed up to 200. You can tune maxConcurrencyPerEnvironment, cap total environments with maxEnvironments, and set a rateLimit to protect downstream databases and APIs.

3. Active-CPU billing — stop paying for waiting

This is the headline feature. You pay for requests, memory, and actual CPU time consumed — not wall-clock duration. When your code waits on a database, a downstream API, or an AI inference call, it uses almost no CPU, so the wait costs very little. In AWS’s test, a fleet serving 484 requests consumed only about 4.8 seconds of total CPU.

4. Long-lived environments

Web Function environments stay alive and warm. They can hold streaming connections open (server-sent events, long polling) and run background tasks outside the request path — things Event Functions simply couldn’t do.

5. Multi-region global endpoints built in

Add --endpoint-type MultiRegion --regions us-east-1,eu-west-2 to your deploy command, and Lambda replicates your code to each region and gives you a single global URL with latency-based routing via Route 53. In AWS’s demo, a caller in the UK dropped from 90 ms (single-region US endpoint) to 16 ms (routed to London) — with zero load balancers or DNS records to configure.

6. Flexible authentication

Choose ApplicationManaged (public endpoint, your code handles OAuth/JWT/Cognito) or IamAuth (AWS validates every request with SigV4 — ideal for service-to-service APIs). For custom domains, caching, and AWS WAF, put CloudFront in front of the endpoint.

Web Functions vs Event Functions: What’s the Difference?

Event Functions aren’t going anywhere — they’re still the right tool for event-driven workloads. Web Functions simply give web applications a model that fits how they actually work.

How to Deploy a Lambda Web Function (Quick Walkthrough)

Here’s how simple the whole flow is:

Step 1 — Write a normal Node.js server. The runtime provides the address in the AWS_LAMBDA_HTTP_ENDPOINT environment variable:

const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || "0.0.0.0:3000").split(":");
server.listen(Number(port), host);

Step 2 — Test locally with npm start and open http://localhost:3000. No emulators, no SAM local, no mocking API Gateway events.

Step 3 — Deploy with one command:

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

The CLI bundles your code, creates the function, an execution role, and a dev endpoint, and prints a live HTTPS URL in the format https://<id>.<shard>.lambda-web.<region>.on.aws.

Step 4 — Go global (optional):

aws lambda-web deploy --name my-web-app --code . --endpoint-name global --endpoint-type MultiRegion --regions us-east-1,eu-west-2

Lambda replicates your code and environment variables to each region, centralizes logs in your home region, and serves everything from one global URL.

You can also define everything in AWS CloudFormation for infrastructure-as-code pipelines, and the runtime writes per-environment summary metrics (request count, peak concurrency, CPU time) to CloudWatch Logs every minute.

When Should You Use Lambda Web Functions?

Web Functions are a great fit for:

• Server-side rendered web apps — Next.js (standalone mode), or any SSR framework that starts an HTTP server
• REST and GraphQL APIs — especially APIs that spend most of their time waiting on databases or third-party services, where active-CPU billing shines
• Streaming endpoints — server-sent events, live dashboards, AI chat responses that stream token by token
• Microservices — service-to-service APIs secured with IamAuth, no API Gateway required
• Spiky or unpredictable traffic — scale to zero when idle, scale out automatically under load

Stick with Event Functions for queue processing, S3 triggers, scheduled jobs, and anything genuinely event-driven. And for very heavy, sustained CPU workloads running 24/7 at near-full utilization, dedicated containers or EC2 may still be more economical — serverless wins when traffic is variable.

One current limitation to note: at launch, Web Functions support Node.js 24 on Arm64 only. If your stack is Python, Java, or .NET, you’ll need to wait for additional runtime support or use the classic Lambda + adapter approach for now.

How Lambda Web Functions Pricing Works

Web Functions bill three things separately:

1. Requests — a small charge per request served
2. Memory — billed for the memory your environments consume while alive
3. Active CPU time — billed only for the CPU your code actually uses

The key insight: an environment can stay alive for minutes holding open connections, yet consume only a fraction of a second of CPU. If your API spends 900 ms of a 1-second request waiting on a database, you’re billed CPU for roughly the 100 ms of real work — not the full second. For I/O-heavy web workloads (which is most of them), this can be dramatically cheaper than wall-clock billing.

For current rates, check the AWS Lambda pricing page.

Final Thoughts: Serverless Finally Fits the Web

AWS Lambda Web Functions remove the last big excuse for not running web applications serverless. You write a standard Node.js HTTP server, deploy it with one command, and get a scalable, pay-for-what-you-use HTTPS endpoint with global routing built in — no adapters, no load balancers, no idle servers burning money at 2 a.m.

For teams already on AWS, this is worth evaluating today for new APIs, SSR frontends, and streaming workloads. For teams weighing Lambda against containers, the economics just shifted meaningfully in Lambda’s favor for I/O-heavy web apps.

Thinking about moving your web applications to serverless? As an AWS Partner, Eternal Soft Solutions helps businesses design, build, and migrate applications on AWS — from Lambda and serverless architectures to full cloud modernization. Get in touch to discuss whether Lambda Web Functions fit your stack.

Source: AWS Compute Blog — Exploring AWS Lambda Web Functions for building web applications (13 Oct 2026)