AWS Lambda Web Functions removes API Gateway from the serverless web path

AWS Lambda Web Functions lets your code listen on a port and handle HTTP requests directly, without API Gateway or an Application Load Balancer in front of it. For platform leads and architects running serverless web backends, this changes the latency profile, the cost model and the operational surface area of every endpoint you expose.

What changes when the gateway disappears#

Lambda Web Functions are a new compute primitive. Your function runs an HTTP server — Express, Hono, Fastify or any Node.js framework — on a port inside the Lambda execution environment. CloudFront can now sit directly in front of that function as an origin, terminating TLS at the edge and enforcing Origin Access Control so only CloudFront can reach the function source 1. The request path is shorter: client → CloudFront edge → Lambda Web Function. No API Gateway integration request/response mapping, no ALB target group health checks, no VPC Link for private integration.

The pricing model shifts from "requests plus duration" to "active CPU time plus memory held". You pay for the CPU your code actually uses while handling a request, not for the wall-clock time spent waiting on a database query or a downstream HTTP call source 2. A single warm environment can serve multiple concurrent requests, which AWS says reduces cold starts by orders of magnitude. Native HTTP streaming is supported, so server-side rendered pages and long-running AI inference endpoints can flush chunks to the client without buffering the entire response.

Existing Lambda functions are now called Lambda Event Functions — a naming change only, with no code changes or redeployments required source 2.

The biggest operational surprise teams face when moving from classic Event Functions to Web Functions isn't latency—it's concurrency discipline. On standard Lambda, you could get away with sloppy in-memory singletons, un-scoped global database clients, or mutable module-level state because each execution environment handled exactly one request at a time. The moment a warm Web Function serves concurrent requests on a single port, un-scoped state turns into cross-request data leaks or race conditions. Before migrating, audit your framework middleware to ensure request-scoped context (like user tenancy and tracing headers) is isolated using AsyncLocalStorage rather than process globals.

Latency: fewer hops, edge TLS, connection reuse#

Removing API Gateway eliminates one network hop and the integration latency it adds. CloudFront terminates TLS at the edge, so the function receives plain HTTP on its port. The function can keep HTTP/1.1 keep-alive or HTTP/2 connections open across multiple requests within the same warm environment, avoiding the TCP and TLS handshake on every invocation. For workloads that stream responses — SSR React, Next.js, AI token streaming — the client receives the first bytes sooner because there is no API Gateway buffering stage.

In our experience building web and mobile applications that serve SSR pages and webhook endpoints, the tail latency improvement from cutting the gateway tier is measurable once you move past the cold-start phase. The cold-start reduction claim — "orders of magnitude" — comes from the ability to pack many concurrent requests into one warm environment, so the probability that an incoming request finds a ready environment is higher. We have not seen independent benchmarks yet; treat the claim as directional until the community publishes real-world numbers.

Cost: pay for active CPU, not wait time#

API Gateway charges per request plus data transfer. ALB charges per LCU-hour. Lambda Event Functions charge per request plus GB-seconds of wall-clock duration. Lambda Web Functions charge for active CPU time (vCPU-seconds) and the memory allocated to the environment (GB-seconds), not for idle time waiting on I/O source 2.

For a typical web backend that spends 80–90% of request duration waiting on a database or an external API, the active CPU fraction is small. A 500 ms request that uses 30 ms of CPU on a 2 GB function costs roughly the CPU portion of 30 ms × 2 GB, not 500 ms × 2 GB. At high request volumes with high I/O wait, the savings can be significant. For CPU-bound workloads — image transformation, on-the-fly compression, heavy middleware — the bill will look similar to the old model.

There are no additional fees for CloudFront Origin Access Control or for using a Lambda Web Function as a CloudFront origin source 1. Data transfer between CloudFront and the function follows standard CloudFront data transfer pricing.

Operational complexity: fewer moving parts, familiar frameworks#

You deploy a Lambda Web Function with the same tooling — SAM, CDK, CloudFormation, CLI, Console — but the artifact is a Node.js HTTP server that listens on process.env.PORT (or the port the runtime assigns). No API Gateway stage variables, no mapping templates, no binary media type configuration, no custom domain setup in API Gateway. Custom domains and managed TLS certificates live in CloudFront source 1.

VPC connectivity works the same way as Event Functions: the function can be placed in a VPC to reach RDS, ElastiCache or private ALBs source 2. Multi-Region routing is supported: deploy once and serve each request from the Region closest to the end user source 2.

Observability changes. You lose API Gateway access logs and metrics (latency, 4xx/5xx counts, cache hit/miss) and gain CloudFront standard logs and Lambda function logs. You will need to correlate CloudFront request IDs with Lambda request IDs if you want end-to-end tracing. X-Ray and CloudWatch Logs Insights still work; the instrumentation points are just in different places.

Migration from API Gateway or ALB#

From API Gateway HTTP API or REST API#

1. Rewrite the handler — move from the event, context callback to an HTTP server that listens on a port. Express, Hono and Fastify all work without adapters source 2.
2. Remove API Gateway resources — delete the API, stages, custom domain mappings, usage plans and WAF associations.
3. Create a CloudFront distribution — set the Lambda Web Function as the origin, enable Origin Access Control, attach your custom domain and ACM certificate, and attach AWS WAF if you need application-layer rules source 1.
4. Update DNS — point your domain to the CloudFront distribution domain name.
5. Test — verify that headers, query strings, cookies and request bodies arrive unchanged. CloudFront passes the original credentials through OAC, so existing sign-in flows keep working source 1.

From ALB with Lambda target group#

1. Rewrite the handler as above.
2. Remove the ALB, target group, VPC Link (if used) and associated security groups.
3. Create a CloudFront distribution with the Lambda Web Function as origin and OAC enabled.
4. If you need VPC-only access — keep the function in the VPC and use CloudFront with a VPC origin configuration (CloudFront can reach ENIs in your VPC). This is a newer CloudFront capability; verify it is available in your Region.

What you lose and what you gain#

When to stay on API Gateway or ALB#

• You need request/response transformation without code changes — mapping templates, header rewriting, body transformation.
• You rely on API Gateway authorizers or usage plans for quota enforcement across many consumers.
• You have a mixed fleet — some endpoints on Lambda, some on ECS/Fargate, some on EC2 — and ALB gives you a single entry point with path-based routing.
• You need WebSocket API support — Lambda Web Functions are HTTP only at launch.
• You run in a Region where Lambda Web Functions are not yet available — currently US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), Europe (Ireland) source 2.

What to do next#

1. Prototype a single endpoint — take a low-traffic API route, rewrite it as an Express/Hono server, deploy as a Lambda Web Function, put CloudFront in front with OAC, and measure latency, cost and error rates for two weeks.
2. Audit your API Gateway / ALB usage — list custom authorizers, mapping templates, usage plans, WAF rules, canary configurations. Decide which move to middleware, which move to CloudFront Functions or Lambda@Edge, and which you can drop.
3. Update your IaC — CDK, SAM or CloudFormation modules for the new pattern. The AWS Agent Toolkit can also generate scaffolding source 2.
4. Plan the cutover — use CloudFront continuous deployment or weighted DNS to shift traffic gradually. Keep the old API Gateway / ALB live until error budgets and latency percentiles are within your SLOs.

A & A Labs helps teams design and migrate serverless web backends, including the move from API Gateway to Lambda Web Functions with CloudFront. If you are evaluating the architecture for a new product or planning a migration, we can work with you on the prototype, the cost model and the operational runbooks.