λ Serverless Lambda Compute Cost Estimator

Lambda bills in GB-seconds. Each invocation looks free — $0.0000166667 per GB-second is too small to feel. At 10M invocations/month with 200ms avg duration and 256MB, you're at $10.50/month per function. 100 functions. The decimal place shifts fast. Model it before your CFO asks why serverless costs more than EC2.

📐 Lambda Workload Profile

Configure invocation volume, avg duration (ms), and memory (MB). The engine computes GB-seconds at $0.0000166667/GB-s plus $0.20/million requests. Small unit cost, big multiplier effect.

AWS Lambda Pricing: GB-Seconds + Request Charges

AWS Lambda employs a two-part pricing model that charges separately for compute duration and invocation count. The compute charge is based on GB-seconds — the product of memory allocated (in GB) and execution duration (in seconds). The request charge is a flat $0.20 per million invocations, regardless of function size or duration. This decoupled model means that short, memory-light functions can be extremely cheap, while long-running, high-memory functions can accrue significant costs even at modest invocation volumes.

How This Calculator Works

ComponentFormulaRate (US East)
Compute CostInvocations × Duration(s) × Memory(GB) × $0.0000166667$0.0000166667 per GB-second
Request CostInvocations × $0.20 / 1,000,000$0.20 per million requests
Total CostCompute Cost + Request Cost

The GB-Second Formula in Practice

A GB-second is the fundamental unit of Lambda compute billing. A function configured with 1,024 MB (1 GB) of memory running for 1 second consumes exactly 1 GB-second. For a function with 512 MB running for 200 ms, each invocation consumes 0.5 GB × 0.2 s = 0.1 GB-seconds. At 5 million invocations per month, that is 500,000 GB-seconds. Multiplied by the $0.0000166667 rate, the pure compute cost is approximately $8.33. The request charge adds another $1.00 (5 × $0.20), totaling roughly $9.33 per month for a moderate-volume API backend.

Cost Optimization Strategies

Lambda costs scale linearly with duration and memory, but not independently. Increasing memory also increases vCPU allocation proportionally (1,769 MB = 1 vCPU), which can reduce execution duration for CPU-bound workloads. This creates a non-obvious optimization surface: a 256 MB function running for 400 ms costs the same in GB-seconds as a 512 MB function running for 200 ms, but the latter may provide lower latency. Use AWS Compute Optimizer or Lambda Power Tuning to find the cost-latency Pareto frontier for your specific function payloads.