AWS Lambda Cost Calculator

Workload preset:

Start from a documented workload shape, then replace it with measured or forecast values.

Architecture:

The selected architecture chooses the built-in US East example rates unless custom rates are enabled.

Monthly invocations:

Enter observed or forecast invocations and choose the matching scale.

Scale

On-demand billed duration:

This duration applies to invocations outside a Provisioned Concurrency window.

Memory allocation:

Use the configured function memory, not observed peak memory use.

Execution model:

Choose on-demand only or split the month between on-demand and a provisioned window.

Use free-tier allowances:

Apply the entered allowances only when still available to this workload; account and organization usage can consume them elsewhere.

Monthly budget:

Enter 0 to omit the budget comparison.

$ USD

Estimate withheld. {{ workflowFeedback }}

Async event share:

Keep 0% when no invocation uses Lambda asynchronous event payload metering.

Average async event:

One request unit covers up to 256 KB; each started 64 KB beyond that adds one unit.

Ephemeral storage:

The neutral 512 MB default adds no storage charge.

Response-streaming share:

Keep 0% when the function does not use Lambda HTTP response streaming.

Average streamed response:

Only bytes above 6 MB per streamed response enter the monthly streaming meter.

Use custom rate card:

Leave off for the cited US East examples; enable for a verified Region or account rate card.

Cost component	Monthly cost	Billing basis	Copy
{{ row.label }}	{{ row.value }}	{{ row.detail }}

A Lambda Functions bill is assembled from several meters rather than one flat price. Requests are counted separately from execution duration, while configured memory converts running time into gigabyte-seconds. Workloads that use Provisioned Concurrency, extra ephemeral storage, asynchronous payloads, or streamed responses can activate additional charges.

This matters most when a workload changes shape. Doubling invocations usually doubles request and execution quantities, but increasing memory can also shorten runtime. A provisioned window adds capacity cost even when traffic is quiet, and account-wide pricing tiers or allowances may already be partly consumed by other functions.

Main quantities that shape an AWS Lambda Functions estimate
Planning quantity	What changes it	Common source
Request units	Invocation count and asynchronous event size	Invocation metrics plus retry and payload forecasts
On-demand GB-seconds	Invocations, billed duration, and configured memory	Lambda reports or a measured load test
Provisioned charges	Traffic share, duration, configured concurrency, and enabled hours	Alias or version configuration and traffic schedule
Optional meters	Storage above 512 MB and streamed bytes above 6 MB per response	Function configuration and response measurements

A useful estimate therefore begins with the billed quantities, not only the nominal request count. Configured memory must replace peak memory use, duration should be the billed duration for the selected architecture, and any no-charge allowance must be limited to the amount still available to this workload.

The result covers the modeled Lambda Functions meters only. Logs, API Gateway, queues, databases, data transfer, NAT, support, taxes, credits, private pricing, and newer Lambda products or features need separate estimates when they apply.

How to Use This Tool:

Start with a representative workload, then replace every assumption that can be measured or quoted for the target Region.

Choose a Workload preset and Architecture. The built-in rate examples differ for x86 and Arm; enable the custom rate card when another Region or account agreement applies.
Enter Monthly invocations, On-demand billed duration, and Memory allocation. Include expected retries and use configured memory rather than observed peak consumption.
Select the Execution model. For a provisioned window, enter its invocation share, billed duration, concurrency, and monthly enabled hours; all four values affect the estimate.
Enable the allowance switch only when the entered request, compute, and streaming amounts remain available to this workload. Set a Monthly budget if the result needs a comparison guardrail.
Open Advanced when asynchronous payload metering, extra ephemeral storage, response streaming, or custom rates apply. Correct the first invalid field if Estimate withheld appears.
Review the monthly total and the largest active line in Cost ledger. Confirm that line's usage quantity and rate before optimizing a smaller charge.

Interpreting Results:

The monthly total is a planning estimate for the active meters. Read it together with the ledger basis: a low request charge can sit beside a much larger duration or provisioned-capacity charge, and a zero line may reflect an entered allowance rather than zero usage.

Cost per million divides the modeled total by actual invocations. It can rise when large asynchronous events create multiple request units or when provisioned capacity stays enabled during quiet periods.
Budget reports the difference from the entered Lambda-only limit. A result at or below that number does not prove the whole application is within budget.
Cost mix shows which active meter deserves verification first. Recheck Region, date, architecture, account tier, and remaining allowances before treating the estimate as a bill forecast.

Technical Details:

Execution duration is priced from allocated memory and billed time. On-demand and provisioned traffic are separated because they can use different duration rates, while Provisioned Concurrency capacity depends on configured environments and enabled time rather than invocation count.

Formula Core:

The monthly total is the sum of request, execution, provisioned-capacity, storage, and streaming charges after the entered allowances are applied.

\begin{aligned} G_{o} & = N_{o} \times \frac{t_{o}}{1000} \times \frac{M}{1024} \\ G_{p} & = N_{p} \times \frac{t_{p}}{1000} \times \frac{M}{1024} \\ G_{c} & = C \times H \times 3600 \times \frac{M}{1024} \\ C_{month} & = C_{requests} + C_{on-demand} + C_{provisioned-duration} + C_{capacity} + C_{storage} + C_{streaming} \end{aligned}

AWS Lambda cost formula symbols
Symbol	Meaning	Unit
`N_o`, `N_p`	On-demand and provisioned-window invocations	count
`t_o`, `t_p`	Average billed duration for each traffic group	ms
`M`	Configured memory allocation	MB
`C`	Provisioned concurrency	environments
`H`	Provisioned enabled time	hours
`G_o`, `G_p`, `G_c`	On-demand duration, provisioned duration, and configured capacity	GB-s

Each cost component multiplies its billable quantity by the active rate. Entered request and on-demand compute allowances are subtracted before their rates are applied. Provisioned duration and configured capacity do not use the entered on-demand compute allowance.

Lookup Core:

The built-in card uses these documented US East example rates. A custom rate card replaces them when enabled.

Built-in AWS Lambda Functions example rates
Meter	x86	Arm	Rate unit
Requests	$0.20	$0.20	per million request units
On-demand duration	$0.0000166667	$0.0000133334	per GB-s
Provisioned duration	$0.0000097222	$0.0000077778	per GB-s
Provisioned capacity	$0.0000041667	$0.0000033334	per GB-s
Extra ephemeral storage	$0.0000000309	$0.0000000309	per GB-s
Response streaming	$0.008	$0.008	per GB

Rule Core:

Several meters use step or floor rules that are easy to miss in a simple request-times-duration estimate.

AWS Lambda Functions meter rules represented in the estimate
Meter	Modeled rule	Boundary
Asynchronous requests	One request unit through 256 KB, then one additional unit for each started 64 KB chunk	At 256 KB the factor is 1; above 256 KB the next partial chunk counts
Ephemeral storage	Execution seconds multiplied by configured storage above 512 MB	Exactly 512 MB adds no storage quantity
Response streaming	Streamed invocations multiplied by bytes above 6 MB per response	Responses at or below 6 MB add no streaming overage
Budget	Monthly total minus the entered budget	A positive variance is over budget; zero or a negative variance is not over

Intermediate quantities retain full numeric precision. Currency is rounded for display, so displayed line items may differ by a few cents from a total calculated from unrounded values.

Limitations and Accuracy Notes:

Built-in rates are documented US East examples, not a live quote. Pricing can differ by Region, architecture, usage tier, account agreement, and date.

Use custom rates for the Region and agreement being evaluated.
Reduce entered allowances when other functions or linked accounts consume them.
Model billed duration from representative traffic; averages can hide long-tail executions and retries.
Add every service and Lambda feature outside the listed meters separately.

Worked Examples:

Three-million-request mobile backend

Three million x86 invocations at 120 ms and 1,536 MB produce 540,000 GB-s. With 400,000 GB-s and one million request units still available, the built-in example rates give about $2.33 for compute plus $0.40 for requests, or approximately $2.73 for the modeled month.

Async payload just above the included size

An average asynchronous event of 257 KB uses two request units because the first byte above 256 KB starts a 64 KB chunk. At 25% async traffic, only that quarter of invocations receives the 2× factor; compute invocations do not double.

References:

AWS Lambda pricing, Amazon Web Services.
Configure Lambda function memory, Amazon Web Services.
Configuring provisioned concurrency for a function, Amazon Web Services.
Response streaming for Lambda functions, Amazon Web Services.