AWS Lambda Web Functions vs Event Functions vs EC2/ECS

What a Web Function is

AWS Lambda Web Functions (announced 12 October 2026) let you run a normal Node.js HTTP server on Lambda. The correct name is "Web Functions", not "web workers". EC2 and ECS are the traditional ways to host APIs, so the comparison below makes sense.

You can deploy a standard server built with Express, Hono, Fastify, Next.js or any Node.js framework. You do not rewrite it into an event handler, and you do not need adapters. The only Lambda-specific item is the AWS_LAMBDA_HTTP_ENDPOINT environment variable, which gives the host and port your server must listen on.

Lambda now has three types. All three use the same Firecracker isolation technology.

Differences from traditional (Event) Lambda

The main change is that one environment serves many requests at the same time, and you pay for CPU work, not wait time.

Main advantages

1. Fewer cold starts during bursts. In old Lambda, 100 concurrent requests need 100 environments. Web Functions share warm environments, and Lambda keeps spare capacity (headroom) ready before demand.
2. Lower cost for I/O-heavy APIs. A request that waits for a database or external API uses little CPU. Old Lambda bills that wait time. Caution: memory still accrues for as long as the environment exists, including idle time.
3. No lock-in to the Lambda model. The same code runs locally, in a container or on EC2.
4. Simple global deployment. Add --regions us-east-1,eu-west-1,... to one command. Lambda copies the code and sets up latency-based routing behind one global URL.
5. Built-in canary releases. Send 90% of traffic to the current revision and 10% to the new one with one API call.
6. Response streaming without extra configuration. Useful for LLM token streaming and SSR.

Comparison with EC2 and ECS

Web Functions remove most of the work of running ECS + ALB, but they do not yet replace ECS for Java, real-time connections or always-warm workloads.

What Web Functions give that EC2/ECS do not

• No servers or clusters to manage. No AMI patching, ECS cluster, task definition, ALB or auto-scaling group.
• Scale to zero. Lambda removes idle environments. On EC2/ECS, at least one instance or task runs and costs money all the time.
• Fast scaling. ECS/EC2 auto scaling takes minutes. Lambda adds environments in seconds and keeps headroom.
• Built-in HTTPS, multi-region and traffic splitting. On ECS you build these with ALB, Route 53 and CodeDeploy.
• Strong isolation per environment through Firecracker microVMs.

What Web Functions do NOT give (EC2/ECS is still better)

• Language choice. Node.js only. A Java or Spring Boot service must still use ECS, EKS, EC2 or classic Lambda (with SnapStart).
• Always-warm capacity. There is no minimum or reserved-environment setting. An endpoint always scales from zero, so first-request latency is less predictable than warm ECS tasks.
• WebSockets and long-lived connections. The endpoint accepts HTTP/1.1 only and removes the Upgrade header. WebSockets will most likely not work. For chat or real-time push, use ECS or API Gateway WebSockets.
• Full control of the machine. No instance types, GPUs, OS packages, sidecars or custom networking. Each environment uses 2 vCPUs on Arm64.
• Background work and long-lived state. Lambda can remove an environment at any time. After SIGTERM, the process has up to 1 second to clean up. Keep important data in DynamoDB, S3 or another external store.
• Custom domain and WAF on the endpoint. You must put a CloudFront distribution in front.
• Region coverage. At launch: N. Virginia, Ohio, Oregon, Tokyo and Ireland only. No Mumbai region yet.
• Cost at high, steady load. For constant high traffic, a well-sized ECS service or reserved EC2 can cost less, because memory is billed for the whole life of each environment.

Points to be careful about in code

One environment serves many requests at the same time, so the code must be safe for concurrent use.

• Do not keep per-request state in global variables.
• Guard shared mutable state (caches, counters) that changes across await boundaries.
• Node.js uses a single-threaded event loop. CPU-heavy synchronous code blocks all concurrent requests in that environment.
• Your server must start to listen within 10 seconds. Put heavy initialization after listen().
• When limits are reached, Lambda returns HTTP 429 at once and does not queue throttled requests. Clients must retry with backoff and jitter.
• Scaling limits per Region: 10,000 RPS per endpoint, 100,000 RPS per account, 2,000 vCPUs per account (about 1,000 environments).

Decision guide

In short, a Web Function is "a Node.js web server, run like Lambda."

Sources

• Announcing AWS Lambda Web Functions – AWS News Blog
• AWS Lambda Web Functions – Developer Guide
• HTTP requests and responses
• Execution environment lifecycle
• Scaling behavior for Lambda Web Functions