{"article":{"slug":"announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere","title":"Announcing AWS Lambda Web Functions for fast, consistent web app performance anywhere","subtitle":null,"summary":"AWS introduces Lambda Web Functions: run standard HTTP servers (Express, Hono, Fastify, Next.js and other Node frameworks) on Lambda without event-handler adapters, with multi-concurrent requests, active CPU billing, one-command multi-region deploy and latency-based routing alongside Event Functions and MicroVMs.","content_type":"announcement","language":"en","canonical_url":"https://aws.amazon.com/blogs/aws/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere/","author":{"name":null,"url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"Amazon Web Services","url":"https://aws.amazon.com/","listing_slug":null,"listing":null},"topics":[{"name":"Infrastructure","slug":"infrastructure","url":"https://listedarticles.com/topics/infrastructure"},{"name":"Announcements","slug":"announcements","url":"https://listedarticles.com/topics/announcements"},{"name":"Web Development","slug":"web-development","url":"https://listedarticles.com/topics/web-development"},{"name":"Developer Tools","slug":"developer-tools","url":"https://listedarticles.com/topics/developer-tools"},{"name":"DevOps","slug":"devops","url":"https://listedarticles.com/topics/devops"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":1051,"reading_minutes":5,"published_at":"2026-10-12T22:34:47.000Z","added_at":"2026-10-13T11:12:05.868Z","updated_at":"2026-10-13T11:12:05.868Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere","markdown_url":"https://listedarticles.com/articles/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere.md","example":false,"citation":"Amazon Web Services. \"Announcing AWS Lambda Web Functions for fast, consistent web app performance anywhere.\" 12 Oct 2026. https://aws.amazon.com/blogs/aws/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere/ (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://aws.amazon.com/blogs/aws/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere/"},"body_markdown":"Today, we’re announcing [AWS Lambda Web Functions](https://aws.amazon.com/lambda/lambda-web-functions/), a new form factor that lets you run standard HTTP web applications on Lambda without rewriting your code into an event handler. You can take a standard port-listening server built with Express, Hono, Fastify, Next.js, or any Node.js framework, deploy it with a single command, and Lambda automatically handles scaling, multi-region distribution, and active CPU billing. No adapters, no infrastructure to manage, and no framework lock-in.\n\nWith this launch, AWS Lambda now offers three distinct form factors, each built on the same Firecracker isolation technology and designed for a different programming model.\n\n**Lambda Event Functions** are what you already know as Lambda functions. They use the event-driven, single-concurrent handler model with wall-clock billing. We’re introducing the “Event Functions” name to highlight that programming model: your function receives an event, processes it, and returns a response. The event-driven programming model is ideal for event processing, queue consumers, and invocations triggered by other AWS services.\n\n**Lambda Web Functions** use an HTTP-native programming model with multi-concurrent execution and active CPU billing. Your code listens on a port and handles standard HTTP requests. That programming model is ideal for web applications, API backends, and interactive HTTP workloads where multiple concurrent requests and I/O-heavy processing are the norm.\n\n**Lambda MicroVMs** provide isolated, stateful sandbox environments with customer-managed lifecycles for running untrusted or user-generated code.\n\nThe three complement each other. An application might use Event Functions for asynchronous backend processing, Web Functions for the user-facing API and server-side rendering layer, and MicroVMs for interactive code execution features, all within the same AWS account and sharing the same operational model.\n\n**Why Web Functions**Modern web applications need to serve global audiences with fast, consistent response times while giving developers the freedom to use standard frameworks and iterate quickly. Building this today typically requires assembling multiple infrastructure components, configuring multi-region deployments, setting up latency-based routing, and tuning billing models to avoid paying for I/O wait. Developers often find themselves adapting their application code to fit a specific compute model rather than deploying the HTTP server they already have.\n\nLambda Web Functions removes this complexity. Each execution environment handles multiple requests simultaneously (up to 128 concurrent requests per environment), which means a burst of incoming traffic can share warm environments instead of mapping each request to a new one. Web Functions meter the CPU time your code uses, so time spent waiting on a database query or an API call consumes little CPU. Memory is metered for as long as the execution environment exists. For I/O-heavy web workloads like server-side rendering, API backends, and AI inference endpoints streaming token responses, this can reduce compute costs.\n\n**Let’s try it out**To get started, I wrote a simple Express.js server. This is the same code I run locally with `node index.js`, no Lambda-specific adapters or wrappers required.\n\n```\nimport express from 'express';\n\nconst app = express();\nconst [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');\n\napp.get('/', (req, res) => {\n res.json({ message: 'Hello from Lambda Web Functions!' });\n});\n\napp.listen(port, host, () => {\n console.log(`Server running on port ${port}`);\n});\n```\n\nThe only difference from running locally is the `AWS_LAMBDA_HTTP_ENDPOINT` environment variable, which Lambda sets to the host and port your server must listen on. To run locally, set it yourself, for example `AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js`.\n\nWith my code ready, I deployed using the [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/):\n\n```\naws lambda-web deploy --name my-web-app --code ./my-app\n```\n\nOne command. No prior resource setup. The CLI bundled my source, created the Web Function, published its first revision, attached a Web Function endpoint, and returned a live HTTPS URL in under a minute.\n\nA revision is an immutable snapshot of the code I deployed. The endpoint is the HTTPS URL that routes traffic to a revision, or splits traffic across revisions. Those are the resources I use to iterate and to control how traffic moves to new code.\n\nI tested it immediately:\n\n```\n$ curl https://..lambda-web.us-east-1.on.aws/\n{\"message\":\"Hello from Lambda Web Functions!\"}\n```\n\nNext, I wanted my application to serve users in Europe and Asia with lower latency. I redeployed with multiple regions:\n\n```\naws lambda-web deploy --name my-web-app --code ./my-app \\\n --regions us-east-1,eu-west-1,ap-northeast-1\n```\n\nLambda Web Functions replicated my code to all three regions and configured latency-based routing automatically. Each request now routes to the Region with the lowest latency for the caller, on a best-effort basis, through one global URL (`.lambda-web.global.on.aws`).\n\nWhen I updated my code and ran the same deploy command again, the CLI detected the existing function, uploaded the new revision, and pointed the endpoint at it. Total turnaround from code change to live: seconds.\n\nFor production workflows that require a more gradual rollout, I can shift traffic between revisions with a single API call:\n\n```\naws lambda-web update-web-function-endpoint \\\n --function-name my-web-app \\\n --endpoint-name dev \\\n --auto-deployment-mode Disabled \\\n --revision-weights '[{\"revisionId\": \"\", \"weight\": 90}, {\"revisionId\": \"\", \"weight\": 10}]'\n```\n\nThis sends 90% of endpoint traffic to the current revision and 10% to the new one, giving me a canary deployment without additional tooling.\n\n**Better together with Amazon CloudFront**For applications that combine static and dynamic content, Web Functions works well alongside [Amazon CloudFront](https://aws.amazon.com/cloudfront/). You can select a Web Function endpoint as the origin for your CloudFront distribution. Static assets are served from the cache while dynamic requests route to your Web Function, giving you CDN performance for static content with serverless compute for the dynamic parts.\n\nWeb Functions improves the private-origin experience with CloudFront.With this launch, you attach CloudFront [origin access control (OAC)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-origin.html) to a Web Function endpoint instead. CloudFront signs requests to the origin, and the endpoint allows only your distribution to invoke it. You get the same private-origin pattern CloudFront already provides for [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/), without exposing the endpoint or adding custom authorization to your app.\n\n**Now available**AWS Lambda Web Functions is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). Web Functions run Node.js 24 (nodejs24.x) on Arm64 at launch and support Amazon Virtual Private Cloud (VPC) connectivity, allowing your function to access resources that exist within a VPC.\n\nTo get started, deploy your first Web Function in under a minute:\n\n```\naws lambda-web deploy --name hello-world --hello-world\n```\n\nFor pricing details, visit the [AWS Lambda pricing page](https://aws.amazon.com/lambda/pricing/). To learn more, see the [Lambda Web Functions documentation](https://docs.aws.amazon.com/lambda/latest/dg/web-functions.html).\n","body_html":"

Today, we’re announcing AWS Lambda Web Functions, a new form factor that lets you run standard HTTP web applications on Lambda without rewriting your code into an event handler. You can take a standard port-listening server built with Express, Hono, Fastify, Next.js, or any Node.js framework, deploy it with a single command, and Lambda automatically handles scaling, multi-region distribution, and active CPU billing. No adapters, no infrastructure to manage, and no framework lock-in.

\n

With this launch, AWS Lambda now offers three distinct form factors, each built on the same Firecracker isolation technology and designed for a different programming model.

\n

Lambda Event Functions are what you already know as Lambda functions. They use the event-driven, single-concurrent handler model with wall-clock billing. We’re introducing the “Event Functions” name to highlight that programming model: your function receives an event, processes it, and returns a response. The event-driven programming model is ideal for event processing, queue consumers, and invocations triggered by other AWS services.

\n

Lambda Web Functions use an HTTP-native programming model with multi-concurrent execution and active CPU billing. Your code listens on a port and handles standard HTTP requests. That programming model is ideal for web applications, API backends, and interactive HTTP workloads where multiple concurrent requests and I/O-heavy processing are the norm.

\n

Lambda MicroVMs provide isolated, stateful sandbox environments with customer-managed lifecycles for running untrusted or user-generated code.

\n

The three complement each other. An application might use Event Functions for asynchronous backend processing, Web Functions for the user-facing API and server-side rendering layer, and MicroVMs for interactive code execution features, all within the same AWS account and sharing the same operational model.

\n

Why Web FunctionsModern web applications need to serve global audiences with fast, consistent response times while giving developers the freedom to use standard frameworks and iterate quickly. Building this today typically requires assembling multiple infrastructure components, configuring multi-region deployments, setting up latency-based routing, and tuning billing models to avoid paying for I/O wait. Developers often find themselves adapting their application code to fit a specific compute model rather than deploying the HTTP server they already have.

\n

Lambda Web Functions removes this complexity. Each execution environment handles multiple requests simultaneously (up to 128 concurrent requests per environment), which means a burst of incoming traffic can share warm environments instead of mapping each request to a new one. Web Functions meter the CPU time your code uses, so time spent waiting on a database query or an API call consumes little CPU. Memory is metered for as long as the execution environment exists. For I/O-heavy web workloads like server-side rendering, API backends, and AI inference endpoints streaming token responses, this can reduce compute costs.

\n

Let’s try it outTo get started, I wrote a simple Express.js server. This is the same code I run locally with node index.js, no Lambda-specific adapters or wrappers required.

\n
import express from 'express';\n\nconst app = express();\nconst [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');\n\napp.get('/', (req, res) => {\n  res.json({ message: 'Hello from Lambda Web Functions!' });\n});\n\napp.listen(port, host, () => {\n  console.log(`Server running on port ${port}`);\n});
\n

The only difference from running locally is the AWS_LAMBDA_HTTP_ENDPOINT environment variable, which Lambda sets to the host and port your server must listen on. To run locally, set it yourself, for example AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js.

\n

With my code ready, I deployed using the AWS Command Line Interface (AWS CLI):

\n
aws lambda-web deploy --name my-web-app --code ./my-app
\n

One command. No prior resource setup. The CLI bundled my source, created the Web Function, published its first revision, attached a Web Function endpoint, and returned a live HTTPS URL in under a minute.

\n

A revision is an immutable snapshot of the code I deployed. The endpoint is the HTTPS URL that routes traffic to a revision, or splits traffic across revisions. Those are the resources I use to iterate and to control how traffic moves to new code.

\n

I tested it immediately:

\n
$ curl https://<domain-id>.<shard-id>.lambda-web.us-east-1.on.aws/\n{"message":"Hello from Lambda Web Functions!"}
\n

Next, I wanted my application to serve users in Europe and Asia with lower latency. I redeployed with multiple regions:

\n
aws lambda-web deploy --name my-web-app --code ./my-app \\\n    --regions us-east-1,eu-west-1,ap-northeast-1
\n

Lambda Web Functions replicated my code to all three regions and configured latency-based routing automatically. Each request now routes to the Region with the lowest latency for the caller, on a best-effort basis, through one global URL (<domain-id>.lambda-web.global.on.aws).

\n

When I updated my code and ran the same deploy command again, the CLI detected the existing function, uploaded the new revision, and pointed the endpoint at it. Total turnaround from code change to live: seconds.

\n

For production workflows that require a more gradual rollout, I can shift traffic between revisions with a single API call:

\n
aws lambda-web update-web-function-endpoint \\\n    --function-name my-web-app \\\n    --endpoint-name dev \\\n    --auto-deployment-mode Disabled \\\n    --revision-weights '[{"revisionId": "<current-revision-id>", "weight": 90}, {"revisionId": "<new-revision-id>", "weight": 10}]'
\n

This sends 90% of endpoint traffic to the current revision and 10% to the new one, giving me a canary deployment without additional tooling.

\n

Better together with Amazon CloudFrontFor applications that combine static and dynamic content, Web Functions works well alongside Amazon CloudFront. You can select a Web Function endpoint as the origin for your CloudFront distribution. Static assets are served from the cache while dynamic requests route to your Web Function, giving you CDN performance for static content with serverless compute for the dynamic parts.

\n

Web Functions improves the private-origin experience with CloudFront.With this launch, you attach CloudFront origin access control (OAC) to a Web Function endpoint instead. CloudFront signs requests to the origin, and the endpoint allows only your distribution to invoke it. You get the same private-origin pattern CloudFront already provides for Amazon Simple Storage Service (Amazon S3), without exposing the endpoint or adding custom authorization to your app.

\n

Now availableAWS Lambda Web Functions is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). Web Functions run Node.js 24 (nodejs24.x) on Arm64 at launch and support Amazon Virtual Private Cloud (VPC) connectivity, allowing your function to access resources that exist within a VPC.

\n

To get started, deploy your first Web Function in under a minute:

\n
aws lambda-web deploy --name hello-world --hello-world
\n

For pricing details, visit the AWS Lambda pricing page. To learn more, see the Lambda Web Functions documentation.

","headings":[]}}