AWS Lambda Web Functions run Node.js HTTP servers without adapters

What happened

AWS has introduced Lambda Web Functions, a new form of serverless compute that runs an ordinary Node.js HTTP server directly on the platform, with no adapter libraries and no per-event handler. According to a dev.to analysis, the application simply listens on the host and port Lambda supplies through the AWS_LAMBDA_HTTP_ENDPOINT variable — the same code you would run locally with node index.js — while AWS provides the HTTPS endpoint, TLS and scaling.

The feature is not a wholesale replacement for classic Lambda. Event-driven work — SQS messages, S3 events, streams — still belongs to the traditional event-handler model. Web Functions also scale to zero when idle, and Node.js is currently the only supported runtime.

What actually changes

Much of what demos show — REST, streaming, webhooks — was already possible in other ways; what changes is the shape of the function. Instead of a handler receiving a parsed JSON event, you write a normal HTTP server on a port. Lambda forwards raw HTTP/1.1 traffic — method, path, query string, body and nearly all headers — so Express, Fastify or Hono see a standard request and response, though parsing and validation are your job. Supported verbs include GET, HEAD, POST, PUT, PATCH, OPTIONS and DELETE; HTTP/1.0 is rejected with a 505, and Lambda adds context headers such as lambda-web-request-id.

Concurrency is the bigger shift. A conventional Event Function environment handles one request at a time; a Web Function environment serves many simultaneously, like any Node server. For workloads that spend most of their time waiting on a database, an external API or an LLM, many requests can share one process instead of each occupying its own environment.

The environment is also no longer frozen between requests, which the dev.to post notes enables global state, reusable connections and background tasks.

Tuning knobs

Three parameters govern behavior. maxConcurrencyPerEnvironment ranges from 1 to 128 and is set on a revision; the effective ceiling may be lower but never higher, and changing the value requires a new revision. maxEnvironments caps environments per region on the endpoint. rateLimit sets accepted requests per second per region, in multiples of 100 up to 1,000 and multiples of 1,000 above that; excess traffic gets a 429, as does traffic that arrives when scaling is exhausted, while requests queue behind an initializing environment. Unlike the concurrency setting, maxEnvironments and rateLimit can be changed on the fly with aws lambda-web update-web-function-endpoint, without redeploying.

Security and billing

Every endpoint is reachable from the internet regardless of its authentication mode. With IamAuth, Lambda validates the SigV4 signature and strips the Authorization header before forwarding. With ApplicationManaged, Lambda authenticates nothing: knowing the URL is enough to reach the app, so authentication must live in the application. The dev.to post also cautions that some headers cannot be trusted — X-Forwarded-Host arrives unvalidated, and the real client address is the last value in X-Forwarded-For.

Billing covers active CPU and memory while the environment exists, not wall-clock time. A request waiting on a slow database burns little CPU, so the wait is barely billed.

Where it does not fit

The author lists several cases where Web Functions are the wrong tool: simple, low-volume request/response jobs are easier as a classic function URL; queues and streams remain event-function territory; requests cap at 900 seconds, so longer jobs must be split; WebSockets and HTTP/2 are unsupported, since persistent bidirectional connections are not held open to the environment; and multi-step workflows fit durable functions better, with checkpoints, retries and wait states that consume no compute. The rule of thumb offered: if the workload is not an HTTP server handling concurrent traffic, Web Functions probably do not apply.

API Gateway keeps its job

A Web Function ships with its own HTTPS endpoint, which is often enough for internal APIs, but it does not make API Gateway obsolete. The guidance cited in the post recommends placing CloudFront or API Gateway in front when you need a custom domain, WAF inspection, caching or centralized edge controls. API Gateway also retains features a Web Function lacks: per-client API keys, usage plans, JWT and Cognito authorizers, and per-consumer quotas. A Web Function's rate limit applies per endpoint and region, not per consumer.

Why it matters

Removing the adapter layer makes Lambda a plausible home for ordinary web applications, not just event glue. Existing framework code can move to serverless largely unmodified, and per-environment concurrency combined with CPU-based billing makes I/O-heavy and LLM-backed workloads far more economical than the one-request-per-environment model. The constraints — public endpoints, a single runtime, no WebSockets — are real, but the boundary between running a server and writing a function has become noticeably thinner.