Lambda Web Functions: idle memory still costs, and endpoints default to public

Express can run directly; check the language and region first

AWS launched Lambda Web Functions on October 12, 2026. Your code listens on a port and handles requests like a regular HTTP server. Node.js frameworks such as Express and Hono need no Lambda-specific adapter. The model suits API backends, server-rendered pages, webhooks and streaming responses. Server rendering means generating the page on the server when a request arrives.

The current offering supports Node.js only; do not assume Python, Java or .NET has the same support. The five launch regions are US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) and Europe (Ireland). Check AWS's current regional availability and documentation for subsequent expansion, and choose the region that fits your users and requirements.

One warm execution environment can handle multiple requests concurrently. Lambda manages these environments as traffic changes and can scale down to zero when traffic stops. A returning request may still wait for initialization, so automatic scaling does not guarantee that every request avoids a cold start.

A 200 ms request with 50 ms of CPU is not entirely free while waiting

Web Functions charges for requests, active CPU time, memory used throughout the execution environment's lifetime, and standard AWS data transfer. Compute usage is metered in 1 ms increments. Concurrent requests share an environment's CPU and memory; do not count that shared memory allocation once for each request.

Waiting for a database or downstream API uses little CPU. Memory charges continue for as long as the environment remains alive, including idle time between requests. Scaling to zero removes idle environments, but it does not mean all charges stop immediately when a particular request finishes.

AWS's hypothetical Example 2 uses 10 million requests per month, each taking 200 ms end to end with 50 ms of active CPU, and an environment using approximately 0.29 GB of memory. At the Arm rates for US East (N. Virginia), the calculation is $13.85 for CPU, $2.76 for memory and $3.00 for requests: $19.61 in total.

That example assumes evenly distributed traffic across a 30-day month and exactly one environment running throughout. It excludes the Free Tier and data transfer. It is AWS's worked calculation, not a measured result from this site or a quote for your workload. Calculate your region, architecture, environment count, account's Free Tier eligibility and transfer charges separately.

The default HTTPS endpoint is public; decide who authenticates requests

The current documentation says aws lambda-web deploy creates an ApplicationManaged endpoint by default. Your application implements login and authorization in this mode. Lambda does not apply IAM authentication to endpoint invocations or use the invocation resource policy to block them. Anyone who knows the endpoint domain can send requests, while your application can still reject unauthorized business operations.

If you need AWS IAM to control invocation, explicitly select --auth-type IamAuth and check caller permissions and signing requirements. IamAuth verifies identity using AWS-signed requests; it does not automatically replace your application's login system. These are configuration choices, not a report of a deployment, IAM change or live endpoint test performed for this article.

Putting CloudFront in front of the endpoint can provide a custom domain or AWS WAF protection, but CloudFront alone does not hide the origin endpoint. An ApplicationManaged origin remains publicly reachable at its own domain. Its invocation resource policy cannot restrict access to CloudFront alone.

CloudFront Origin Access Control is the mechanism by which CloudFront authenticates to the origin. AWS requires IamAuth, the lambda origin type, the always-amz-auth signing behavior and an appropriate resource policy. Also check which principals may make signed requests directly. Having a CloudFront distribution does not, by itself, make the origin private.

Behind CloudFront, where should you check 404s, lost login headers and 403s?

For a 404, first check whether the origin request policy forwards the viewer's Host header. A Web Functions endpoint expects Host to contain its origin endpoint domain, rather than the CloudFront distribution domain. If you use a managed origin request policy, choose AllViewerExceptHostHeader instead of copying AllViewer.

If your application relies on the Authorization header for login, include it in the cache policy for every cache behavior using this origin. For GET and HEAD requests, CloudFront otherwise removes Authorization before forwarding. Selecting always-amz-auth does not replace this forwarding configuration.

Regional endpoints use sigv4 signing; global endpoints use sigv4a. All regions associated with a global endpoint must be enabled by default. If it includes an opt-in region that requires explicit activation, CloudFront cannot sign for that region and the origin returns 403. Multi-region support does not mean every combination of regions supports OAC.

The new CloudFront distribution configuration must finish deploying, and a multi-region endpoint's resource policy must finish replicating to all its regions. Until both processes complete, some requests may temporarily receive 403 responses. AWS gives no fixed waiting period here. Check deployment and policy propagation status rather than promising that waiting a particular number of minutes will resolve it.

If you already use Lambda@Edge origin request or origin response triggers, check compatibility first. A cache behavior using a Lambda Web Function with OAC cannot also use those triggers; CloudFront rejects the combination. This applies to regional and global endpoints, whether the origin is accessed directly or through an origin group. These are suggested configuration checks; this site has performed no deployment or live endpoint tests.

Must existing Lambda functions migrate? Choose by the job they do

AWS is also renaming existing Lambda functions Lambda Event Functions. The announcement explicitly describes a name change that requires no code changes or redeployment. Queue messages, file uploads and similar event processing still call for the Event Functions model. A new product name is not a reason to rewrite a working flow.

Web Functions is designed for applications that receive HTTP requests directly. You deploy code as a .zip file, Lambda creates an HTTPS endpoint, and immutable revisions preserve code and configuration. An endpoint can route traffic to one or two revisions. Prepare the application and permissions using the current creation and deployment guide, rather than copying an old function's event-handler entry point.

For example, if an existing Express API spends most of its time waiting for database responses, estimate active CPU, memory across the environment's lifetime, request volume and transfer together before deciding whether to pilot Web Functions. This is a proposed evaluation scenario, not one we have executed. The CPU billing model alone cannot guarantee a lower bill than your existing setup.

Streaming responses do not establish compatibility with every protocol

Web Functions can stream a response incrementally to the client, which suits applications that return model output as it becomes available. The current HTTP guide specifies HTTP/1.1 for accepted and forwarded requests; HTTP/1.0 receives a 505 response. Supported methods are GET, HEAD, POST, PUT, PATCH, OPTIONS and DELETE.

The request line, request headers and terminating blank line have a combined limit of 128 KiB; exceeding it produces a 431 response. This is a header limit, not the request-body limit. This article does not establish request-body size, execution duration or every service quota. Check the complete current guide for those limits instead of copying them from another function type.

The endpoint removes certain headers, including Upgrade, Connection and Proxy-Authorization. Native HTTP response streaming does not establish support for WebSocket upgrades, arbitrary proxy protocols or SOCKS connections. If your application depends on these behaviors, check the relevant protocol documentation before evaluating it in an isolated environment.

Check suitability in three steps before a pilot

First, check the current AWS documentation for the supported language, target region, permissions and how your application must listen for requests. Choose an authorized, isolated environment and a non-sensitive sample. Confirm that direct HTTP handling fits the job, and retain a recovery path for the existing service.

Next, choose the endpoint authentication mode before any deployment. For ApplicationManaged, check your application's own authentication. For IamAuth or CloudFront Origin Access Control, follow the full official guide to check signing and policies. HTTPS encrypts the connection; its presence alone does not establish that access is restricted.

Finally, estimate active CPU, environment memory and lifetime, request count, scaling and data transfer together. If you later run a pilot, separately check authorized requests, unauthorized requests, response streaming and observed billing. Retain evidence with sensitive details removed, without recording credentials or private request content. These are proposed steps; this site has performed no cloud-account operations or performance tests for this article.