AWS Lambda Cost Calculator (invocations + GB-seconds)
Estimate Lambda-style serverless cost from request volume and GB-second compute. Compare baseline vs peak traffic with your region/runtime pricing.
Maintained by CloudCostKit Editorial Team. Last updated: 2026-02-23. Editorial policy and methodology.
Best next steps
Use this calculator for the first estimate, then validate the answer with the closest guide or companion tool.
Inputs
Results
Treat Lambda as a runtime-shape bill, not just a request counter
Lambda totals are driven by two moving parts at once: invocation count and GB-seconds. That means a request spike is only half the story. Duration, memory size, retries, and cold-start-heavy traffic patterns often matter more than the request fee itself.
- Measure invocations and duration together over the same time window instead of estimating them separately.
- Use realistic duration distributions such as p50 and p95 when baseline and burst traffic behave differently.
- Keep memory settings tied to the actual function configuration; GB-seconds move immediately when memory changes.
Where Lambda estimates usually drift
- Retry bursts: async retries and failing downstream dependencies can multiply invocations.
- Long-tail duration: a small number of slow invocations can dominate compute cost in bursty systems.
- Concurrency behavior: cold-start mitigation, traffic spikes, and parallelism can change real runtime shape.
- Adjacent observability: logs, metrics, transfer, and downstream services are often larger than the Lambda request line item.
How to reconcile the estimate with the bill
- Compare invocation totals with measured function traffic over the same billing period.
- Check whether p95 or retry-heavy duration explains why billed GB-seconds exceed the simple average case.
- Separate core Lambda charges from CloudWatch, egress, and downstream service costs before deciding the calculator is wrong.
- Run a second scenario for launch or incident months if normal traffic does not represent your highest-cost periods.
What to do when one side dominates
If GB-seconds dominate, tune memory, duration, and handler behavior first. If invocation growth dominates, inspect retries, batching, and event fan-out. If the Lambda bill looks reasonable but the serverless stack still feels expensive, move next to logs, queues, API Gateway, or egress instead of stretching this page into a full platform cost model.
Next steps
Example scenario
- 50M invocations/month, 120ms avg duration, 512MB memory -> estimate requests + compute charges.
- Peak 220% scenario shows bursty months or incident spikes.
Included
- Request fees from invocations/month and $ per 1M requests.
- Compute fees from GB-seconds (invocations x duration x memory GB) and $/GB-second.
- Optional RPS to monthly invocations estimator.
- Optional free tier deduction (toggle).
- Baseline vs peak scenario table for invocation spikes.
Not included
- Logging/metrics (for example, CloudWatch), data transfer, and downstream service costs.
- Provisioned concurrency and other add-ons unless you model them separately.
How we calculate
- GB-seconds = invocations x (duration_ms / 1000) x (memory_MB / 1024).
- Request cost = billable_invocations / 1,000,000 x $ per 1M requests.
- Compute cost = billable_GB_seconds x $ per GB-second.
- Total = request cost + compute cost (excluding logs, transfer, etc).
FAQ
Why do I need to enter pricing?
Does this include CloudWatch logs and metrics?
How do I estimate duration and memory?
Related tools
Related guides
Disclaimer
Educational use only. Not legal, financial, or professional advice. Results are estimates based on the inputs and assumptions shown on this page. Verify pricing and limits with your providers and documentation.
Last updated: 2026-02-23. Reviewed against CloudCostKit methodology and current provider documentation. See the Editorial Policy .