--- title: AWS Lambda Web Functions run standard HTTP servers... description: AWS introduced Lambda Web Functions, a new Lambda compute type that runs standard HTTP servers (Express, Hono, Fastify, Next.js or any Node.js framework)... canonical: https://daily.dev/posts/aws-lambda-web-functions-run-standard-http-servers-without-event-handlers-gfnlppgxo twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: AWS Lambda Web Functions run standard HTTP servers without event handlers | daily.dev og:description: AWS introduced Lambda Web Functions, a new Lambda compute type that runs standard HTTP servers (Express, Hono, Fastify, Next.js or any Node.js framework)... og:url: https://daily.dev/posts/aws-lambda-web-functions-run-standard-http-servers-without-event-handlers-gfnlppgxo og:image: https://api.daily.dev/og/posts/gFnlpPGXo.png og:image:alt: AWS Lambda Web Functions run standard HTTP servers without event handlers og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # AWS Lambda Web Functions run standard HTTP servers without event handlers **[Collections](https://daily.dev/sources/collections)** · 2 min read · 4 upvotes · 1 comments ## Summary AWS introduced Lambda Web Functions, a new Lambda compute type that runs standard HTTP servers (Express, Hono, Fastify, Next.js or any Node.js framework) directly, without requiring adapters or event-handler rewrites. Each environment handles up to 128 concurrent requests, billing is based on active CPU time, and native HTTP streaming and VPC connectivity are supported, running on Node.js 24/Arm64. Deployment is a single CLI command that provisions an HTTPS URL, scaling, multi-region routing, and canary traffic shifting. Existing Lambda functions are renamed Lambda Event Functions (no code changes needed), and CloudFront can now use a Lambda Web Function directly as an origin with TLS termination, caching, and Origin Access Control for DDoS protection. The feature launches in five AWS regions including N. Virginia and Ireland. ## Content AWS has added a new Lambda compute type called Lambda Web Functions. Your code listens on a port and handles HTTP requests directly, so an Express, Hono, Fastify or Next.js app (or any Node.js framework) can run without adapters or a rewrite into event handlers. ## How it works Each execution environment can handle up to 128 concurrent requests. Billing follows active CPU time. Time spent waiting on I/O uses little CPU, so it costs little. Native HTTP streaming is supported, and so is VPC connectivity. Functions run Node.js 24 on Arm64. Deployment is one CLI command. AWS says it returns a live HTTPS URL in under a minute. The same command handles scaling, multi-region distribution with latency-based routing, and canary traffic shifting between revisions. ## Naming Existing Lambda functions are now called Lambda Event Functions. It is a naming change only, and no code needs to change. Web Functions sit next to them, along with Lambda MicroVMs, which are isolated sandboxes for untrusted code. ## CloudFront as an origin CloudFront can now use a Lambda Web Function as an origin. That gives you TLS termination at the edge, caching, and custom domains with managed certificates, with no application code changes. Origin Access Control limits the function so it can only be reached through CloudFront. That helps protect against network-layer DDoS attacks, and you can attach AWS WAF for more protection. The feature is available everywhere except the CloudFront China region, at no additional fee. You can configure it through the console, SDK, CLI or CloudFormation. ## Availability Web Functions launch in five AWS Regions, including US East (N. Virginia) and Europe (Ireland). ## Questions this post answers ### What is AWS Lambda Web Functions and how is it different from regular Lambda functions? Lambda Web Functions is a new AWS Lambda compute type that lets code listen on a port and handle HTTP requests directly, so frameworks like Express, Hono, Fastify, or Next.js run without adapters or event-handler rewrites. Existing Lambda functions are renamed Lambda Event Functions, a naming change only requiring no code updates. Web Functions support up to 128 concurrent requests per environment, native HTTP streaming, VPC connectivity, and run Node.js 24 on Arm64. _Teams weighing a move to Lambda Web Functions can track serverless deployment changes like this on daily.dev._ ### How is AWS Lambda Web Functions billing calculated? Billing follows active CPU time rather than total execution time. Time spent waiting on I/O uses very little CPU, so those periods cost little, making the pricing model friendlier for HTTP servers that spend time idle waiting on network or database calls compared to traditional time-based Lambda billing. _Developers estimating serverless costs can follow pricing model shifts like this on daily.dev._ ### Can CloudFront use a Lambda function as an origin directly? Yes, CloudFront can now use a Lambda Web Function as an origin, providing TLS termination at the edge, caching, and custom domains with managed certificates without application code changes. Origin Access Control restricts the function to be reachable only through CloudFront, helping guard against network-layer DDoS attacks, and AWS WAF can be attached for added protection. It is available everywhere except the CloudFront China region at no extra fee. _Engineers architecting edge delivery for serverless apps can track CloudFront integration updates on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 120 comments across hackernews (as of 2026-10-14). **TL;DR:** Reaction is split between excitement that Lambda finally supports standard web servers without adapters (seen as a direct answer to Cloudflare Workers, Vercel Fluid Compute, Cloud Run, and Azure Container Apps) and long-running skepticism about whether FaaS/Lambda architectures are worth the operational complexity compared to containers or VMs. **Sentiment:** 30% positive · 40% mixed · 30% skeptical **The case for** - Removes the need for adapters/shims like serverless-express, making it easier to lift-and-shift standard Express/Fastify/Hono apps onto Lambda. - Multi-concurrency per environment plus active CPU billing is seen as a meaningful improvement over the old one-request-per-environment model. - Praised for being a strong, overdue competitive response to Cloudflare Workers and similar edge/serverless container platforms. - Some report very low real-world costs and simple operations running production workloads on Lambda already. - Good fit for extremely bursty or sparse workloads where paying for idle capacity would be wasteful. **The pushback** - Node.js-only support at launch is seen as a major gap, especially for performance-sensitive or non-JS backends. - Comparisons to Cloud Run and Azure Container Apps argue those already offer similar or better scaling, concurrency, and scale-to-zero billing without lambda-specific quirks. - Concerns about cold starts persisting in low-traffic scenarios despite multi-concurrency claims. - General distrust of FaaS/Lambda-heavy architectures leading to fragmented, hard-to-maintain systems across many functions/repos. - Lack of container or WASM support is viewed as a missing killer feature, though noted as on the roadmap. - Pricing complexity (memory billing, data transfer, request counts) seen as less transparent than Cloudflare's model. **By community** - hackernews (mixed): Discussion splits between enthusiasm for closing the gap with Cloudflare Workers/Cloud Run and a long-running architectural debate over whether Lambda/FaaS is ever the right choice, with a vocal contingent pushing back hard on blanket anti-Lambda takes. **Hottest debate:** Whether FaaS/Lambda is fundamentally a good architectural choice at all, versus containers (Cloud Run, Azure Container Apps, ECS/Fargate) which several commenters argue already match or beat Lambda's new scaling and billing model. **Open questions** - Will cold starts still be a real problem in low-traffic scenarios despite multi-concurrency and proactive scale-up? - When will container or WASM-based deployment support land, since it's only listed as 'coming soon'? - Will support expand beyond Node.js to other runtimes like Python, .NET, Java, or Rust? **Highlights** > My biased take as the architect of Workers: It's a classic Clay Christensen innovator's dilemma. V8 isolates seem "worse" on their face (e.g. mostly incompatible with non-JS apps, more difficult to secure), while aiming down-market. The hyperscalers' biggest existing customers aren't asking for them; they are asking for more and better micro VMs to run their existing codebases. It's only the little guys looking to deploy greenfield apps with low ops overhead and on a tight budget that really appreciate the Workers model, and to AWS these seem like small potatoes. Meanwhile there's a huge amount of investment needed to build out this entirely new and different way of doing things (we've been working on it almost a decade now!). In the worst case, this investment is wasted, and in the best case, cannibalizes the existing product line. There likely many people at AWS who recognize the dilemma, but still cannot push the organization in the right direction. Too much inertia, too many stakeholders who don't get it, because it's unintuitive. When orgs get big they just cannot take disruptive steps, even when they were built on disruption in the past. They only finally come around after the new disruptor is eating their lunch, but by then it's too late. > — [kentonv on hackernews](https://news.ycombinator.com/item?id=50072261) > Disappointed by the NodeJS-only requirement and the 128 req/env/sec ceiling. NodeJS-only feels very pre-AI. Let me tell my agent to write my web service in Rust/C++/C/Go/Zig, and ship a statically-linked single binary that fits within a maximum binary size ceiling. I'd get much better performance, and make much more of the premium CPU/RAM pricing that I'm being asked to pay in exchange for scale-to-zero and fast autoscaling. The rest is amazing. First-class support as a CloudFront origin. Easy multi-region and gradual deployment. Clearly, finally, a great response to Cloudflare. Just.... so close, and yet, so far. No way am I going back to Node as a web backend for greenfield projects in 2026. > — [solatic on hackernews · 2 comments](https://news.ycombinator.com/item?id=50077138) > > I strongly recommend never using functions as a service unless you genuinely have some client edge compute requirement that absolutely cannot be solved via some other means. Why? What’s the downside? Are you taking the benefits into account in your calculus? This sort of general, input-free recommendation is junior level thinking at best. > I am fairly confident I could support more capacity with a single t3a.nano instance. It depends on what resources those connections are using (memory, CPU, I/O, network). What actual work is being done? > — [otterley on hackernews](https://news.ycombinator.com/item?id=50070519) > I would agree with OP with "stay away". The Google paper Towards Modern Development of Cloud Applications[0] does a great job explaining why. TL;DR the case they make against micro-services architectures (which Lambda encourages): 1. It hurts performance 2. It hurts correctness 3. It is hard to manage 4. It freezes APIs 5. It slows down application development For even a moderately complex system, spreading logic out over multiple discrete runtimes doesn't make sense; instantly run into each of the 5 points. The only times I've found functions useful is truly single-point behavior where we were running some logic connected to CloudFront on each request for some header parsing. It is certainly possible to write a monolith in Lambda as well, but then that would be bad architecture and a bad fit and I suppose why they are now introducing this new model that is more like GCP Cloud Run or Azure Container Apps. [0] https://sigops.org/s/conferences/hotos/2023/papers/ghemawat.... > — [CharlieDigital on hackernews](https://news.ycombinator.com/item?id=50071635) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50064063) · 16 points · 4 comments - [hackernews](https://news.ycombinator.com/item?id=50069318) · 81 points · 116 comments ## Community discussion Top comments from developers on daily.dev. **@pdfopsdev** · 0 upvotes > 128 concurrent requests per environment is the number that matters here, that's basically them admitting this competes with Fargate now, not classic Lambda. billing on active CPU time instead of wall clock is the real win though, long-polling or streaming responses stop being a tax. ## Similar posts on daily.dev - [You’re Paying for Servers You’re Not Using. AWS Lambda Fixes That.](https://daily.dev/posts/you-re-paying-for-servers-you-re-not-using-aws-lambda-fixes-that--pbzq6ixun) · Medium · 0 upvotes · 0 comments - [AWS Lambda](https://daily.dev/posts/aws-lambda-nmgvbaj4o) · Towards Dev · 0 upvotes · 0 comments - [Serverless Architecture: When to Use It \(and When Not To\)](https://daily.dev/posts/serverless-architecture-when-to-use-it-and-when-not-to--3trxabnfp) · Syncfusion · 0 upvotes · 0 comments - [Edge Functions vs Serverless 2026: The Honest Truth](https://daily.dev/posts/edge-functions-vs-serverless-2026-the-honest-truth-tjktppggt) · Alex CloudStar · 0 upvotes · 0 comments --- Tags: [#aws](https://daily.dev/tags/aws), [#nodejs](https://daily.dev/tags/nodejs), [#serverless](https://daily.dev/tags/serverless), [#aws-lambda](https://daily.dev/tags/aws-lambda) [View this post on daily.dev](https://daily.dev/posts/aws-lambda-web-functions-run-standard-http-servers-without-event-handlers-gfnlppgxo) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"AWS Lambda Web Functions run standard HTTP servers without event handlers","url":"https://daily.dev/posts/aws-lambda-web-functions-run-standard-http-servers-without-event-handlers-gfnlppgxo","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/aws-lambda-web-functions-run-standard-http-servers-without-event-handlers-gfnlppgxo"},"datePublished":"2026-10-13T16:12:09.472Z","dateModified":"2026-10-14T07:41:03.546Z","description":"AWS introduced Lambda Web Functions, a new Lambda compute type that runs standard HTTP servers (Express, Hono, Fastify, Next.js or any Node.js framework)...","image":"https://pbs.twimg.com/media/HUgR6ufWQAADkgj.jpg","thumbnailUrl":"https://pbs.twimg.com/media/HUgR6ufWQAADkgj.jpg","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/aws-lambda-web-functions-run-standard-http-servers-without-event-handlers-gfnlppgxo","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"aws,nodejs,serverless,aws-lambda","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"AWS Lambda Web Functions run standard HTTP servers without event handlers"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/aws-lambda-web-functions-run-standard-http-servers-without-event-handlers-gfnlppgxo","comment":[{"@type":"Comment","text":"128 concurrent requests per environment is the number that matters here, that’s basically them admitting this competes with Fargate now, not classic Lambda. billing on active CPU time instead of wall clock is the real win though, long-polling or streaming responses stop being a tax.","datePublished":"2026-10-14T18:09:51.816Z","url":"https://daily.dev/posts/gFnlpPGXo#c-8XMZ7jpEh","author":{"@type":"Person","name":"PDFops","url":"https://daily.dev/pdfopsdev","image":"https://media.daily.dev/image/upload/s---8isRBKc--/f_auto/v1782922291/avatars/avatar_orjMeK8QKaaVZwGq7ScPz?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/aws-lambda-web-functions-run-standard-http-servers-without-event-handlers-gfnlppgxo#faq","mainEntity":[{"@type":"Question","name":"What is AWS Lambda Web Functions and how is it different from regular Lambda functions?","acceptedAnswer":{"@type":"Answer","text":"Lambda Web Functions is a new AWS Lambda compute type that lets code listen on a port and handle HTTP requests directly, so frameworks like Express, Hono, Fastify, or Next.js run without adapters or event-handler rewrites. Existing Lambda functions are renamed Lambda Event Functions, a naming change only requiring no code updates. Web Functions support up to 128 concurrent requests per environment, native HTTP streaming, VPC connectivity, and run Node.js 24 on Arm64. Teams weighing a move to Lambda Web Functions can track serverless deployment changes like this on daily.dev."}},{"@type":"Question","name":"How is AWS Lambda Web Functions billing calculated?","acceptedAnswer":{"@type":"Answer","text":"Billing follows active CPU time rather than total execution time. Time spent waiting on I/O uses very little CPU, so those periods cost little, making the pricing model friendlier for HTTP servers that spend time idle waiting on network or database calls compared to traditional time-based Lambda billing. Developers estimating serverless costs can follow pricing model shifts like this on daily.dev."}},{"@type":"Question","name":"Can CloudFront use a Lambda function as an origin directly?","acceptedAnswer":{"@type":"Answer","text":"Yes, CloudFront can now use a Lambda Web Function as an origin, providing TLS termination at the edge, caching, and custom domains with managed certificates without application code changes. Origin Access Control restricts the function to be reachable only through CloudFront, helping guard against network-layer DDoS attacks, and AWS WAF can be attached for added protection. It is available everywhere except the CloudFront China region at no extra fee. Engineers architecting edge delivery for serverless apps can track CloudFront integration updates on daily.dev."}}]} ```