Why AWS Lambda Bills You for Time It Isn't Computing
Lambda's GB-second billing multiplies duration by allocated memory for the entire request lifecycle — activeCpuTimeMs + idleWaitTimeMs — so a function that spends 50ms parsing JSON and then 300ms blocked on a database query is billed for the full 350ms at its configured memory size (this tool defaults Lambda to 512MB / 0.5GB). Cloudflare Workers' CPU-time billing counts only activeCpuTimeMs — the runtime pauses the billing clock during outbound fetch and database I/O — so that same 300ms wait costs nothing extra on Workers, which defaults here to a 128MB allocation.
The Two Formulas Side by Side
- AWS Lambda:
(activeCpuTimeMs + idleWaitTimeMs) × invocations × 0.5GB × price-per-GB-second, plus a flat $0.20 per million requests. - Cloudflare Workers:
activeCpuTimeMs × invocations × 0.128GB × price-per-GB-second, plus $0.15 per million requests. - The lever: increasing
idleWaitTimeMs(slower downstream DB or API calls) grows the Lambda term but leaves the Cloudflare term untouched, so the gap between the two bars widens purely as a function of how long your function sits idle.
When the Gap Actually Shrinks
Set idleWaitTimeMs to 0 in the calculator to see this converge: with no I/O wait, Lambda's duration term equals Cloudflare's, and the remaining cost difference comes entirely from the memory-allocation gap (0.5GB vs 0.128GB), not the billing model. In other words, Cloudflare's edge advantage is largest for I/O-bound workloads — database calls, third-party API fan-out — and much smaller for CPU-bound work like image processing or heavy serialization.