Do AWS Lambda Web Functions Replace API Gateway for Web Apps?

Lambda Web Functions can replace API Gateway as the serving layer for a web app only in a narrow slice of cases today: greenfield Node.js 24 services deployed in its five launch regions, where you are willing to handle end-user authentication, throttling, and related gateway concerns in your own code or in front of a CDN. Everywhere else, the evidence supports keeping what you have.

That answer comes with an honesty obligation. Every Web Functions-specific fact in this article traces to two AWS pages: the announcement published October 12, 2026 and the Lambda pricing page. No independent benchmark, review, or production report on Web Functions exists yet. So treat the performance framing in AWS’s headline (“fast, consistent web app performance”) as an unreplicated vendor claim, and treat anything not in those two pages as unknown rather than absent. Where capabilities are shipped, I say shipped; where the announcement gestures at behavior without documentation, I say so.

What AWS actually shipped

The announcement defines Web Functions as a new Lambda form factor that runs ordinary HTTP servers without the event-handler rewrite Lambda has historically required. Per AWS: “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” (AWS announcement).

Three properties of that launch are documented and matter for the API Gateway question:

• It is a serving layer, not an invoke target. A Web Function gets its own URL of the form <domain-id>.lambda-web.global.on.aws, with automatic multi-region replication and latency-based routing “on a best-effort basis” through that one global URL (AWS announcement). This is the same architectural slot API Gateway or an ALB occupies: the thing clients talk to.
• It is multi-concurrent. Each execution environment handles up to 128 concurrent requests, per the announcement. That is a different execution model from the one-request-at-a-time model Event Functions are known for, and it is what makes web workloads plausible on it at all.
• It bills on a different unit. AWS’s pricing page now lists three form factors with distinct meters: “Lambda Event Functions are priced per request and execution duration. Lambda MicroVMs are priced per instance-second. Lambda Web Functions are priced per requests and active CPU time” (AWS Lambda pricing).

Also shipped, per the announcement: VPC connectivity, the ability to select a Web Function endpoint as a CloudFront origin, with static assets served from cache and dynamic requests routed to the function, and CloudFront origin access control (OAC), under which “CloudFront signs requests to the origin, and the endpoint allows only your distribution to invoke it.”

What AWS does not document for Web Functions: end-user authentication, throttling, custom domains, response caching, and any quotas page. Dollar rates are documented, on the pricing page, and a free tier is referenced there but not quantified. Those absences are where the replacement question actually lives.

The programming model change is the real story

The migration-cost axis favors Web Functions more than any other. The Event Functions model asks you to reshape a web app around an event object and a handler signature, or to run an adapter shim that translates API Gateway events into fake HTTP requests for your framework. Web Functions skip that: your code listens on a port and handles standard HTTP requests, which AWS describes as “ideal for web applications, API backends, and interactive HTTP workloads where multiple concurrent requests and I/O-heavy processing are the norm” (AWS announcement).

For a team with an existing Express or Fastify service, that removes an entire class of adapter bugs: event-to-request translation edge cases, binary payload handling, header casing, and the mismatch between what your framework sees locally and what it sees behind the shim. It also means local development and production run the same code path, which the event-handler model never quite achieved.

The tradeoff is that you now own HTTP concerns Lambda previously delegated to the gateway. Your process terminates TLS-adjacent concerns, parses routes, and, as discussed below, may have to enforce auth and rate limits itself. That is normal web-server work, but it is work, and teams that adopted API Gateway precisely to avoid writing it should price that in.

Concurrency and billing: where the economics actually change

The 128-requests-per-environment figure (AWS announcement) is the number that changes the cost model, because it pairs with a billing unit AWS has priced in full. Event Functions bill $0.20 per million requests plus $0.0000166667 per GB-second of duration, with a free tier of one million requests and 400,000 GB-seconds per month (AWS Lambda pricing). Web Functions bill $0.30 per million requests, $0.0000276944 per vCPU-second of active CPU, and $0.0000036667 per GB-second of memory for as long as each execution environment runs; the published examples are Arm prices in US East (N. Virginia) and “exclude the free tier and data transfer” (AWS Lambda pricing).

Working AWS’s own numbers makes the comparison concrete. Its second example is an I/O-heavy API backend: 10 million requests a month, each 200 ms end to end of which 50 ms is active CPU, in a roughly 300 MB environment, for a $19.61 monthly bill (AWS Lambda pricing). Push the same traffic through the Event Functions rates: 10 million requests at 200 ms is 2 million seconds, which at 512 MB of memory is 1 million GB-seconds, or $16.67, plus $2.00 in requests, about $18.67 (AWS Lambda pricing). At 1 GB of memory the same bill is about $35.33. For ordinary request/response traffic the two form factors land close enough that your configured memory decides the winner.

The gap opens when requests stay open far longer than the CPU works. AWS’s fourth example is an LLM streaming endpoint: 5 million requests a month, each open 3,000 ms with 200 ms of active CPU, billing $33.94, because “you pay for only the 200 ms of active CPU” (AWS Lambda pricing). The same traffic on Event Functions at 512 MB is 15 million seconds, 7.5 million GB-seconds, about $125.00 plus $1.00 in requests at the published rates (AWS Lambda pricing). That is the case active-CPU billing was built for.

Three caveats. Memory “is metered for as long as the execution environment exists” (AWS announcement), and the pricing examples assume exactly one environment running for a 30-day month, so an always-warm service carries a fixed memory floor that bursty traffic does not. The examples exclude the free tier, whose Web Functions amounts AWS references but does not state. And this is a two-way comparison: API Gateway’s own rates are not in this article’s sources, so the third column of the ledger stays empty here.

Structurally: if your Lambda-backed web app is I/O-bound, the billing dimension moved in your favor; if it is CPU-bound (image processing, heavy serialization), active-CPU billing is less clearly a win and may not be one at all.

What the launch surface rules out

This is the strongest counter to any replacement claim, and it is not arguable. Per AWS: “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” (AWS announcement).

Set that against the Event Functions estate. As of 2025, Lambda supports Node.js, Python, Java, Go, .NET, Ruby, and custom runtimes (Wikipedia: AWS Lambda). Every Python FastAPI service, every Java Spring function, every .NET API currently behind API Gateway has no Web Functions target to migrate to. So does every workload pinned to x86, and every workload outside five regions. “Does this replace API Gateway?” is, for the large majority of existing Lambda web apps, answered by the runtime list alone: the question cannot come up yet.

Streaming and cold starts: knowns that do not transfer

Two performance-adjacent axes need careful handling, because the available evidence either measures the old execution model or prices the new one without measuring it.

Response streaming. For Event Functions, streaming is documented: via InvokeWithResponseStream or a function URL in ResponseStream mode, improving time to first byte, supporting payloads over 6 MB, charged per GB written with the first 6 MB per request free (AWS Lambda pricing). For Web Functions, long-lived streaming is not merely possible; it is priced. The announcement names “AI inference endpoints streaming token responses” as a target workload (AWS announcement), and the pricing page’s fourth example is an LLM streaming endpoint whose requests stay open 3,000 ms (AWS Lambda pricing). What AWS does not document is the per-byte side: no per-GB streamed charge, no payload limit, and no streaming API equivalent to InvokeWithResponseStream appears in the Web Functions material. If your app streams very large responses, the byte-level terms are an open verification item, not a checkbox.

Cold starts. The independent cold-start literature is real but measures a different thing. A Java Lambda study found that choosing the right memory configuration improved cold starts by about 70%, “going from an average of 16307 ms to 4867 ms” (arXiv:2310.16510). And an analysis of Lambda’s first-generation architecture describes each new MicroVM downloading the function image, “a .zip file up to 250MiB in size,” from S3 and unpacking it (arXiv:2305.13162). Both were measured on Event Functions. A multi-concurrent Web Function environment amortizes its startup across up to 128 requests rather than one (AWS announcement), so cold starts should matter less per request, but that is an inference from the architecture, not a measurement, and AWS’s announcement offers no cold-start numbers of its own. The concurrency ceiling also cuts the other way: a traffic spike beyond what warm environments can absorb still forces new environments, and nobody outside AWS has measured how fast those start.

Global routing, CloudFront, and the gateway features you may be rebuilding

The global URL is the most interesting architectural piece. AWS describes deploying to three regions with replication and latency-based routing configured automatically, “on a best-effort basis, through one global URL” (AWS announcement). “Best-effort” is undefined: the announcement publishes no SLA and no failover semantics, so treat it as a convenience, not a guarantee, until AWS documents routing behavior.

CloudFront origin support is shipped per the announcement and is the natural pairing: static assets from cache, dynamic requests to the function. It also matters because CloudFront is where some of the missing gateway features can be partially reattached.

Which brings us to the crux. What AWS ships at launch is origin protection, not end-user auth. With CloudFront OAC attached to a Web Function endpoint, “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” (AWS announcement). That decides which distribution may reach your origin; it does not decide which end user may call your API. End-user authentication and authorization, throttling and rate limiting, custom domains, and response caching appear nowhere in AWS’s Web Functions material. Absence of documentation is not proof of absence, and AWS may well document some of these later. But the closest precedent is not reassuring for a default posture: the Lambda Function URL, the prior “Lambda without API Gateway” option, gives a function “a unique and permanent URL which can be accessed by authenticated and non-authenticated users alike” (Wikipedia: AWS Lambda). A bare URL puts the burden of deciding who may call it on your application code by default.

That is a build-vs-buy question, and it deserves honest framing in both directions. Writing JWT verification and a token-bucket rate limiter in Express middleware is well-trodden work, and for a small internal tool it may be genuinely cheaper than operating a gateway. For a public API with per-client quotas, WAF rules, and usage plans across teams, rebuilding that surface in code is a real engineering commitment that recurs forever. One more caveat on the other side: no API Gateway documentation is among the sources here, so I cannot cite gateway-side pricing or feature specifics. Verify that side of the ledger against current AWS docs before committing.

Where each option stands

Cells marked undocumented or not sourced mean AWS’s published Web Functions material, or this article’s sources, do not cover them; they are not claims that the capability does not exist.

What I would do with this

If you are starting a new Node.js web service today, deploy to one of the five launch regions, and your auth story is a single identity mechanism you are comfortable enforcing in middleware: Web Functions is a reasonable default serving layer. You skip the adapter layer, you get a billing unit that matches how I/O-heavy workloads actually consume compute, and the global URL plus CloudFront origin covers a conventional web architecture. I would still trial it first on work that tolerates rough edges, because every performance characteristic above the concurrency ceiling is unmeasured by anyone outside AWS.

Keep API Gateway, or your ALB, or your existing Function URL, for everything else: any non-Node.js runtime, any region outside the launch five, any app whose large-payload streaming depends on per-byte terms AWS has not published, and any app where throttling, per-client auth, or custom domains are requirements rather than nice-to-haves. In those cases the replacement question is not “no” so much as “not answerable from what AWS has published,” which for infrastructure decisions should resolve to staying put.

Three things to re-verify before this advice ages: whether AWS states the Web Functions free-tier amounts and quotas, and what API Gateway adds to the same traffic, which needs pricing not in this article’s sources; whether end-user auth, throttling, custom domains, and streamed-byte terms get documented; and whether independent cold-start and latency benchmarks appear. The decision framework, programming-model fit, active-CPU versus GB-second economics, and the gateway-feature build-vs-buy question, will outlive whatever changes in those three. The launch specifics will not.

Frequently Asked Questions

Which runtimes and regions support Lambda Web Functions at launch?

Per AWS: “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” (AWS announcement).

How does Lambda Web Functions billing differ from Event Functions?

AWS’s pricing page now lists three form factors with distinct meters: “Lambda Event Functions are priced per request and execution duration. Lambda MicroVMs are priced per instance-second. Lambda Web Functions are priced per requests and active CPU time” (AWS Lambda pricing).

Does Lambda Web Functions include end-user authentication and throttling?

What AWS does not document for Web Functions: end-user authentication, throttling, custom domains, response caching, and any quotas page. Dollar rates are documented, on the pricing page, and a free tier is referenced there but not quantified. Those absences are where the replacement question actually lives.