Lambda Web Functions: Are You Charged While Waiting for an API?
Most of each request in a Lambda web function goes to waiting on a model API, with the CPU almost idle. Are you still paying during that wait, and for which resource?
- Waiting for an API can consume little CPU while memory charges continue.
- Memory billing includes idle gaps for as long as the execution environment remains alive.
- Compare active CPU use, environment lifetime and request concurrency when evaluating the total bill.
An idle CPU does not make the request free
Lambda Web Functions separate active CPU metering from memory billing. The service overview says memory charges accrue throughout an execution environment’s lifetime, including gaps between requests. Requests and data transfer are separate charges.
A database query or a streamed model response may leave the CPU with little to do. That reduces the CPU component; it does not eliminate the memory holding the server and its in-flight requests.
| Component | What is measured |
|---|---|
| CPU | Active CPU consumption by the application and runtime. |
| Memory | Consumption across the environment’s lifetime, including idle gaps. |
| Requests and transfer | Charged separately from compute. |
HTTP servers join the existing event model
In its October 12 announcement, AWS introduced Web Functions for port-listening Node.js applications, including Express, Hono and Fastify. An HTTP application no longer needs an event-handler adapter for this form of Lambda.
The familiar event-driven product remains as Lambda Event Functions, with wall-clock billing. Queue consumers and service-triggered processing still fit that model; Web Functions target HTTP APIs and web applications.
Each Web Function environment can serve concurrent requests. The configured per-environment ceiling defaults to 64 and accepts values from 1 to 128. Lambda can enforce a lower dynamic limit, so 128 is not a throughput promise.
The server still has a runtime and state contract
The supported runtime is currently Node.js 24. Applications must listen at the host and port supplied in AWS_LAMBDA_HTTP_ENDPOINT. Hard-coding a local address can leave the application unreachable.
Runtime patches are automatic. You cannot freeze a particular patch release or disable patching through runtime management controls.
The environment lifecycle also matters: globals, caches and connections survive across requests. Reusable connection pools can help, but request-specific credentials and customer data belong in request scope. Concurrent requests can interleave when shared state is modified across an asynchronous operation.
Active is a deployment state, not an application health check
AWS explicitly says an Active revision or endpoint does not confirm server startup. Send a request after deployment and inspect application logs.
The operating guidance calls for load testing against real dependencies, tracking latency, CPU, memory and downstream capacity. Build native dependencies for Arm64 and verify updates in every participating Region.
Evaluate a migration with both resource consumption and concurrency in view. Measure the application under representative traffic before turning a smaller CPU charge into an assumed reduction in the whole bill.
FAQ
Are existing functions converted automatically?
No. The event-driven programming model remains available as Event Functions. Web Functions are a separate HTTP-server form factor.
Does scaling to zero remove cold starts?
No. A request arriving after environments have scaled to zero must wait for a new environment to initialize.