Back to the journal

Lambda Web Functions: multiple requests, one server

Native HTTP servers, shared concurrency and active CPU billing: where Lambda Web Functions can help a Cloud and DevOps team today.

AWS SERVERLESS
AWSLambdaDevOps
Lire en français

A platform dashboard calls AWS, checks a CI pipeline and returns a deployment summary. Most of its response time may be spent waiting for those services. Lambda Web Functions changes the hosting and billing model for this kind of HTTP workload. It runs a standard Node.js server and shares its environment across concurrent requests.

What AWS has added

Announced on 12 October 2026, Web Functions runs a standard Node.js HTTP server on Lambda. Express, Hono and Fastify applications can listen on a port without a Lambda handler adapter. At launch, the runtime is Node.js 24 on ARM64, in Northern Virginia, Ohio, Oregon, Tokyo and Ireland. Paris is not in that launch list. AWS announcement.

The service provides an HTTPS endpoint, response streaming and automatic scaling down to zero. A revision captures code and configuration; endpoints route requests to revisions. Service overview.

What about Python?

Web Functions currently does not support Python. The only documented runtime is nodejs24.x. Python runtimes remain available on classic Lambda, so an existing Python API cannot move unchanged to Web Functions. Web Functions runtimes · Python on Lambda.

Python is widely used on Lambda: Datadog reported 58% Python functions versus 31% Node.js in 2021 among its customers. These are historical figures, not current market shares. In 2023, the invocation chart shows approximately 44% Node.js and 28% Python. Deployed function counts and invocation volume are different measures; these reports cannot establish a leading language in 2026. Datadog 2021 · Datadog 2023.

The difference from classic Lambda

The comparison below uses on-demand Event Functions, the familiar Lambda model. Lambda Managed Instances is a separate option that already supports concurrent invocations. Lambda compute and pricing.

Aspect Classic on-demand Lambda Lambda Web Functions
Application entry point Event handler HTTP server listening on a port
Concurrency in one environment One invocation at a time Multiple HTTP requests
Compute billing Duration and allocated memory Active CPU and memory over environment lifetime
Natural workload SQS consumers, S3 events, scheduled tasks APIs, server-rendered pages, streaming
Conceptual model: three simultaneous requests, with one handler per environment on the left and a shared HTTP server on the right. Actual placement depends on scaling.
Conceptual model: three simultaneous requests, with one handler per environment on the left and a shared HTTP server on the right. Actual placement depends on scaling.Download SVGDraw.io source

AWS manages the effective concurrency per environment. The configurable ceiling reaches 128, but this is not a throughput guarantee. Settings such as maxEnvironments and rateLimit help bound load on databases and downstream APIs. Scaling.

Where it could be useful today

An internal platform API. Aggregate deployment status, AWS resource metadata and pipeline results behind one endpoint. Reusing an existing Node.js server could reduce the adaptation work required to move that service to serverless hosting.

A backend for a developer portal. Return environment inventories or release summaries to a frontend. Keep authorization scoped to the requesting user and environment.

An AI response gateway. Forward a model’s streamed response while performing authentication and request accounting. Web Functions hosts the gateway; model inference remains a separate service and cost.

These uses follow the documented HTTP and streaming capabilities; they still need testing with representative traffic. Workload guidance.

Proposed architecture: a read-only API aggregates AWS and CI/CD information. Application authentication and scoped read permissions are explicit.
Proposed architecture: a read-only API aggregates AWS and CI/CD information. Application authentication and scoped read permissions are explicit.Download SVGDraw.io source

In this proposed design, the application validates the identity provider’s tokens and enforces user permissions. AWS API calls use scoped execution-role credentials; the CI/CD API uses its own read credential. CloudFront is optional for the basic endpoint, and provides a front door for a custom domain and WAF. Endpoint access.

What changes for Cloud and DevOps teams

Build: keep the HTTP framework, package the server and manage versioned releases. Weighted revisions support gradual rollout; multiregion endpoints add latency-based routing. Data placement still needs an explicit design: a nearby API calling a distant database can remain slow. Deployment model.

Run: shared environments require request-scoped state. Global variables must not hold one user’s token or response. A synchronous CPU-heavy operation blocks the Node.js event loop and affects other requests. Persist durable state externally, and monitor latency, errors and downstream saturation. Cold starts remain possible after scale-to-zero. Environment lifecycle.

FinOps: waiting on an external service uses little CPU, but memory remains billable while the environment exists, including between requests. Add requests, transfers, logging and dependencies when comparing total cost. Savings need measurements under representative traffic. Pricing.

A small test in Ireland

To move from the diagram to the console, a Node.js API was deployed in eu-west-1. It exposes /health and /api/platform-summary. Deployment statuses are synthetic, and a deliberate 250 ms asynchronous wait stands in for a downstream call.

The endpoint requires an IAM signature. The lab caps scaling at two environments, with a ceiling of four requests per environment and an endpoint limit of 100 requests/s.

An unsigned /health request returns 403; the SigV4-signed request returns 200. Four batches of four parallel API calls produced 16 successful responses out of 16. The application counter observed two overlapping requests in each of the two processes used: setting a ceiling of four does not force Lambda to fill every environment.

CloudShell report: 403 without a signature, 200 with SigV4, 16 successful responses and two overlapping requests observed in each of two Node.js processes.
Saved CloudShell test results: the client signs requests with SigV4; the server running on Web Functions is Node.js.

CloudWatch logs then show the route, status and process that served each request. Authentication headers are never logged by the demo application.

CloudWatch Logs: lab logs showing the requested route, HTTP 200 status, process identifier and overlapping request count.
Lab observability: logs connect each route with its status and process. The concurrency counter is instrumented by the demo application.

The benefit for this kind of API is shared HTTP execution: while one request waits, the same process can handle another. With classic on-demand Lambda, each concurrent invocation occupies a separate environment.

How to evaluate it

Start with one read-only API in Ireland and compare the same business logic on both models. Test a tiny JSON response, parallel downstream calls and a CPU-heavy route under sparse traffic, steady load and bursts. Record p50/p95/p99, successful throughput, errors and total cost per successful request.

Web Functions is an option to assess when a Node.js HTTP service spends much of its time waiting. Existing event consumers still fit Event Functions. The choice depends on measured results: deployment effort, behavior under load and cost with actual traffic.

About the author

Cloud & DevOps Engineer

Hi everyone! I design and operate cloud architectures. Here I share news, experiments and lessons learned about AWS, DevOps and AI agents, exploring how new capabilities can meet real needs.

Profile and articles

Cloud, DevOps and AI agents. The Kloud journal.

Back to the journal