Serverless Cost Estimator

Estimates monthly cost for a Lambda-style serverless function from invocation count, average duration and allocated memory — the two-line-item pricing model (compute + requests) that every major serverless platform uses in some form, whether it's AWS Lambda, Azure Functions or Google Cloud Functions.

The pricing model, in the actual units it's billed in

Serverless compute is billed in GB-seconds — memory allocated (in GB) multiplied by execution duration (in seconds) multiplied by invocation count. A function allocated 512MB running for 150ms, called a million times a month, uses (512/1024) × 0.15 × 1,000,000 = 75,000 GB-seconds. On top of that, there's a flat per-request charge, billed per million invocations regardless of how long each one ran.

Why memory allocation affects the bill more than people expect

Doubling the memory allocated to a function doubles its GB-second cost for the same duration — but it often doesn't double the actual execution time, because more memory also means proportionally more CPU allocated on most serverless platforms. A function that's CPU-bound rather than memory-bound can sometimes run meaningfully faster with more memory, partially or even fully offsetting the higher per-GB-second rate. This is the single most common serverless cost optimisation that gets missed: profiling a function at a couple of different memory settings and comparing total cost (not per-GB-second rate) often reveals that a higher memory tier is actually cheaper overall, not more expensive, because of the reduced duration.

The free tier is bigger than most people budget for

The standard monthly free tier — 1 million requests and 400,000 GB-seconds of compute — genuinely covers a lot of low-to-moderate traffic workloads entirely for free. A function running a few hundred thousand times a month at modest memory and duration can sit at $0 in gross terms. The free tier resets monthly and doesn't roll over, so it's worth sizing against expected steady-state monthly volume, not a one-off burst.

Where serverless pricing stops being obviously cheaper

Serverless is genuinely cost-effective for spiky, unpredictable, or low-average traffic, since you pay only for actual execution time with no idle server cost. It stops being the obvious cheap choice once you have sustained high, predictable load — at that point, a provisioned server or container running continuously at high utilisation often works out cheaper per unit of work than paying the serverless per-invocation premium at scale. The crossover point depends heavily on your actual duration and memory profile, which is exactly why running the numbers for your specific workload — rather than assuming serverless is always cheaper — matters before committing to an architecture.