AWS Lambda Web Functions lets developers deploy standard Node.js HTTP applications without rewriting them as event handlers. Its concurrent request model, active-CPU billing and managed scaling offer new hosting options, but network, security and operational limitations affect where it fits.
A developer builds an API using Express or Fastify. The application starts an HTTP server, listens on a port and handles incoming requests. Running that application on traditional AWS Lambda usually requires adapting it to an event-handler interface.
On October 12, 2026, AWS introduced Lambda Web Functions, which lets developers deploy a conventional Node.js HTTP server directly to Lambda. At launch, AWS made the service available in five Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) and Europe (Ireland). AWS may add Regions, so check its current list before you plan around the service.
Web Functions also introduce a different execution model. Multiple HTTP requests can share an execution environment, and charges distinguish active CPU consumption from memory allocated over the environment’s lifetime. These capabilities make Lambda an option for more web applications, but they do not remove the need to choose the right hosting architecture.
What changes from traditional Lambda?
AWS now calls its existing Lambda handler model Event Functions. That naming change does not require existing functions to be rewritten.
An Event Function receives an event, executes its handler and returns a result. A standard Event Function execution environment processes one invocation at a time. A Web Function instead runs a normal Node.js HTTP server. Lambda routes HTTP traffic to the server, which can handle concurrent requests.
| Characteristic | Event Functions | Web Functions |
|---|---|---|
| Programming model | Event handler | Port-listening Node.js HTTP server |
| Typical workloads | Events, queues, scheduled jobs and API handlers | HTTP APIs, web applications, server-side rendering and streaming |
| Concurrency per environment | One invocation at a time | Multiple HTTP requests |
| Compute billing basis | Invocation duration | Active CPU consumption |
| Memory billing basis | Invocation duration | Execution-environment lifetime |
| Scaling | Managed invocation scaling | Managed HTTP scaling, including scale-to-zero |
Both models continue to have distinct purposes. An application might use Web Functions for an API and retain Event Functions for queue processing or scheduled tasks. The timeout rules of Event Functions are a separate topic, covered in our article on Lambda’s 90-minute timeout.
Source: AWS, Announcing AWS Lambda Web Functions, October 12, 2026.
How concurrent requests change execution
The main change is that a single execution environment can work on many requests at once, as an ordinary web server does. At launch, Web Functions support Node.js 24 on Arm64, and each execution environment has 2 vCPUs and 2 GB of memory. Unlike a traditional Event Function environment, a Web Function environment can serve several requests simultaneously.
AWS dynamically adjusts how many requests an environment handles based on observed resource utilization. The maxConcurrencyPerEnvironment setting defines an upper bound between 1 and 128, and its default is 64. That value is not guaranteed concurrency. Lambda may select a lower effective limit when CPU or memory usage makes additional requests unsuitable.
This can benefit applications dominated by asynchronous I/O. For example, a Node.js API might spend much of its request time waiting for database queries or external services. While one request waits, the event loop can process other requests.
CPU-intensive synchronous work behaves differently. If a request blocks the event loop, other requests sharing that process may also be delayed.
Sharing one process between requests also creates a state problem. Request-specific information must not be stored in shared mutable globals. Caches, counters and other shared objects need appropriate handling when asynchronous operations interleave.
An application written for a conventional Node.js server may already account for these conditions. Developers should still verify its actual behavior in the managed Lambda environment.
Sources: AWS, Execution environment lifecycle, Scaling behavior and Runtime support.
What does active-CPU billing mean?
Active-CPU billing means you are charged for the CPU time your code actually uses, not for the time a request spends waiting on other systems. Customers pay for requests, active CPU consumption, memory usage over the execution environment’s lifetime and applicable data transfer. This differs from the traditional Lambda duration model, which includes the time an invocation spends waiting for downstream operations.
Consider an API request that performs a brief calculation and then waits for a database response. Under Web Functions, the waiting period may consume little active CPU. However, memory charges continue while the execution environment exists, including idle time between requests. An endpoint can scale to zero after traffic stops, but an environment does not necessarily disappear immediately after each request.
This distinction makes Web Functions potentially attractive for some I/O-heavy applications. It does not establish that the service is cheaper for every application. A cost comparison must consider traffic patterns, average request duration, CPU utilization, memory consumption, data transfer and the behavior of the current hosting platform. Applications with sustained CPU-intensive workloads may have different economics from applications dominated by network waits.
Source: AWS, Lambda Web Functions overview.
How deployment and scaling work
A Web Function contains revisions and endpoints. A revision is an immutable snapshot of application code and configuration. An endpoint provides the HTTP entry point and routes requests to one or two revisions according to its traffic configuration.
This separation supports controlled rollouts. Teams can create a new revision, test it and direct a portion of traffic to it.
Client calls the endpoint
Every Web Function endpoint has a publicly reachable domain name.
With IamAuth, Lambda requires appropriately authorized, signed requests.
With ApplicationManaged, Lambda passes requests through without performing caller authentication.
Endpoint picks a revision
An endpoint provides the HTTP entry point and routes requests to one or two revisions according to its traffic configuration.
Teams can create a new revision, test it and direct a portion of traffic to it.
One environment, many requests
Unlike a traditional Event Function environment, a Web Function environment can serve several requests simultaneously.
The maxConcurrencyPerEnvironment setting defines an upper bound between 1 and 128, and its default is 64.
Lambda may select a lower effective limit when CPU or memory usage makes additional requests unsuitable.
Response and timeout
Lambda forwards the complete incoming request body before delivering the application’s response.
Web Function requests have a default timeout of 30 seconds and a configurable maximum of 900 seconds, or 15 minutes.
If it expires after response headers have been sent, the client may receive a truncated response rather than a clean application error.
AWS provides three principal scaling controls.
| Setting | Purpose |
|---|---|
maxConcurrencyPerEnvironment | Upper bound on concurrent requests within one environment |
maxEnvironments | Optional maximum number of environments per endpoint in each Region |
rateLimit | Optional request-arrival limit per endpoint in each Region |
The service also enforces account-level limits, including regional vCPU capacity and request-rate quotas. Increasing an endpoint setting does not override those account quotas.
When an endpoint exceeds a request-rate limit or runs out of available serving capacity, Lambda can return HTTP 429 responses. There are additional cases to consider. Setting rateLimit to zero disables traffic and produces HTTP 503 with a specific platform error indicator. AWS can also return HTTP 503 while shedding load to protect the service.
Clients should retry only when appropriate, waiting longer after each failure and adding a random delay (backoff and jitter). Write operations may require idempotency keys or deduplication so retries do not repeat business effects.
A deployed revision is not necessarily a working application
AWS distinguishes revision and endpoint resource states from actual application readiness. A revision can become active even if its HTTP server fails to start correctly.
After deployment, teams should send a real HTTP request, inspect application logs and confirm that the endpoint serves the intended response. For production rollouts, weighted revision deployment and a verified rollback path are more reliable than assuming resource creation equals successful application deployment.
Sources: AWS, Scaling behavior and Core concepts.
Streaming works, with protocol limitations
Web Functions support HTTP response streaming. This can help applications deliver server-rendered content, incremental API results or AI-generated output as it becomes available.
However, the request and response path has an important limitation. AWS documents HTTP/1.1 half-duplex behavior. Lambda forwards the complete incoming request body before delivering the application’s response.
Applications should therefore finish reading a request body before writing their response. This matters for designs that expect bidirectional streaming while a client is still uploading data.
WebSocket upgrades are not supported. Server-sent events may be suitable for one-way server-to-client streaming, but applications requiring persistent bidirectional WebSocket communication need another supported architecture.
Web Function requests have a default timeout of 30 seconds and a configurable maximum of 900 seconds, or 15 minutes. The timeout must cover request-body reception and response delivery. If it expires after response headers have been sent, the client may receive a truncated response rather than a clean application error.
Source: AWS, Configuring networking for Web Functions.
Multi-Region deployment and VPC connectivity are not interchangeable
AWS supports multi-Region endpoints that replicate application revisions across selected supported Regions and route requests according to network latency. This can help applications serve geographically distributed users.
However, deploying the application across Regions does not automatically replicate its databases, sessions, secrets or downstream dependencies. Teams must ensure that every participating Region can access the resources required to serve requests.
A multi-Region rollout can also fail halfway. An endpoint update may succeed in one Region and fail in another. AWS recommends checking regional update status rather than treating the overall endpoint status as proof that every Region has received the same revision.
A significant limitation for private resources
Web Functions also support outbound connectivity to resources inside an Amazon VPC through an egress network connector. Endpoints come in three types. A HomeRegion endpoint serves traffic from the home Region only, while MultiRegion and PerRegion endpoints serve traffic from several Regions.
As of November 6, 2026, those connectors are supported only with HomeRegion endpoints.
AWS does not support associating a VPC egress connector with revisions served through MultiRegion or PerRegion endpoints. An application that requires direct access to a private database through such a connector therefore cannot assume that it can also use Web Functions’ built-in multi-Region endpoint distribution. This constraint must be resolved during architecture selection, not after deployment.
VPC egress connectivity also does not make the Web Function’s incoming HTTPS endpoint private. Inbound access and outbound network connectivity are separate concerns.
Inbound is public
Every Web Function endpoint has a publicly reachable domain name.
IAM authentication does not turn the endpoint into a private network resource.
Outbound can be private
Web Functions also support outbound connectivity to resources inside an Amazon VPC through an egress network connector.
VPC egress connectivity also does not make the Web Function’s incoming HTTPS endpoint private.
Inbound access and outbound network connectivity are separate concerns.
HomeRegion only
AWS does not support associating a VPC egress connector with revisions served through MultiRegion or PerRegion endpoints.
An application that requires direct access to a private database through such a connector therefore cannot assume that it can also use Web Functions’ built-in multi-Region endpoint distribution.
Decide early
This constraint must be resolved during architecture selection, not after deployment.
However, deploying the application across Regions does not automatically replicate its databases, sessions, secrets or downstream dependencies.
Sources: AWS, Configuring networking for Web Functions, Core concepts and Best practices for Lambda Web Functions.
Security starts at the public endpoint
Every Web Function endpoint has a publicly reachable domain name. AWS provides two authentication approaches.
With IamAuth, Lambda requires appropriately authorized, signed requests. With ApplicationManaged, Lambda passes requests through without performing caller authentication. The application or an upstream service must implement the necessary authentication and authorization.
IAM authentication does not turn the endpoint into a private network resource. For public applications, developers must also address input validation, rate abuse, request authorization and protection of sensitive information.
Web Function endpoints do not support custom domain names or direct AWS WAF association. Amazon CloudFront can sit in front of a Web Function to provide a custom domain, caching and AWS WAF protection.
For an IamAuth endpoint, AWS recommends CloudFront origin access control (OAC), so that CloudFront signs its requests to the origin. With other front doors, the endpoint remains directly reachable, so the application should verify a shared secret or token. Without suitable origin restrictions, direct requests may bypass the intended front door.
Browser applications also require appropriate Cross-Origin Resource Sharing (CORS) configuration. Lambda does not add CORS headers for Web Functions, so the application or its front door must handle them. CORS is not an authentication mechanism.
Sources: AWS, Best practices for Lambda Web Functions and Configuring networking for Web Functions.
When should developers consider Web Functions?
The choice should follow the workload’s actual behavior.
| Workload | Approach worth evaluating |
|---|---|
| Node.js APIs with asynchronous database or network calls | Web Functions |
| Node.js server-side rendering | Web Functions |
| HTTP response streaming or server-sent events | Web Functions, within timeout and protocol limits |
| Queue processing and scheduled background work | Event Functions |
| Persistent WebSocket communication | Another WebSocket-capable hosting architecture |
| Web service needing direct private VPC access and built-in multi-Region distribution | Another design or hosting approach |
| Applications requiring unsupported runtimes or custom runtime resources | Container hosting or another suitable compute service |
At launch, Web Functions support Node.js only. Applications using another runtime, requiring different compute resources or depending on unsupported networking behavior should not be forced into the service simply because it is serverless. Existing ECS or Fargate applications may already meet their needs effectively. Migration should follow demonstrated operational or economic benefits.
A focused production-readiness test
Before adopting Web Functions, select one representative non-production HTTP service. Confirm that the server starts correctly and listens on the required endpoint. Test concurrent requests, shared state, database connections and event-loop blocking. Measure actual CPU and memory billing behavior under realistic traffic.
Verify throttling, cold starts, timeout handling, streaming responses and safe client retries. Then validate endpoint authentication, CloudFront origin protection, VPC requirements and regional deployment behavior. Finally, deploy a second revision and prove that traffic can be moved back to the previous working version.
These checks help distinguish a successful demonstration from an application that can be operated reliably.
What Web Functions actually change
AWS Lambda Web Functions brings familiar Node.js web applications into Lambda without requiring the traditional handler model. Concurrent HTTP processing, managed scaling and active-CPU billing make it a meaningful new hosting option.
The limits matter as much as the features. Applications must be safe under concurrent requests. Memory billing continues while environments exist.
WebSocket upgrades are unavailable. VPC egress connectors cannot currently be combined with built-in multi-Region endpoint types.
The practical decision is not whether Lambda can run a normal web server.
It is whether Web Functions’ execution, networking and operational model fits the application better than its existing hosting alternatives.
References and further reading
- AWS, Announcing AWS Lambda Web Functions. October 12, 2026. Launch Regions, runtime and the three Lambda form factors.
- AWS, Lambda Web Functions overview. Programming model, billing and supported workloads.
- AWS, Core concepts. Revisions, endpoints and request processing.
- AWS, Scaling behavior. Dynamic concurrency, quotas and throttling.
- AWS, Execution environment lifecycle. Concurrency safety, shutdown and environment reuse.
- AWS, Configuring networking. HTTP streaming, VPC restrictions, endpoint connectivity and CORS.
- AWS, Best practices. Security, retry behavior, rollout verification and multi-Region operations.
- AWS, Runtime support. Node.js runtime requirements and memory.
Sources verified November 5, 2026 and checked again on November 6, 2026. Technical capabilities and limitations reflect AWS’s documentation on those dates, and a new service changes quickly, so check the sources above before you act. Cost and performance implications are architectural analysis, not independent TechiesJournal benchmark results.