Lambda cost per million invocations: a worked pricing breakdown
Lambda cost per million invocations depends on two levers, the flat per-request fee and the per-GB-second duration charge, and the duration part usually dominates. Working through real numbers shows exactly where the cost goes and which lever to pull. Here is the breakdown.
Quick answer
Lambda charges about $0.20 per million requests plus about $0.0000166667 per GB-second of compute (x86; ARM is roughly 20 percent cheaper). For a 512 MB function running 200 ms per call, a million invocations cost about $0.20 in requests plus about $1.67 in duration, roughly $1.87 total. The duration charge usually dominates, and it scales with both memory and run time, so the biggest levers are cutting execution time, right-sizing memory, and moving to ARM. A common mistake is over-allocating memory: it multiplies the GB-second cost, though more memory also gives more CPU, so the fastest-and-cheapest point is found by testing. The headline is that duration, not the per-request fee, is where Lambda cost lives.
Lambda's pricing looks simple, two charges, but it is easy to misjudge where the money goes. Many teams focus on the per-request fee when the duration charge is almost always the larger part. Working through the numbers for a million invocations shows exactly how the two combine and which lever actually moves the bill.
The two charges
| Charge | Rate (x86, us-east-1) | Scales with |
|---|---|---|
| Requests | ~$0.20 per million | Number of invocations |
| Duration | ~$0.0000166667 per GB-second | Memory x run time |
| ARM discount | ~20% off duration | Choosing arm64 architecture |
A GB-second is one gigabyte of allocated memory for one second of execution. Lambda bills duration as allocated memory (in GB) multiplied by run time (in seconds), at about $0.0000166667 per GB-second. The request charge is a flat $0.20 per million invocations regardless of size or duration. So total cost is requests plus duration, and the two behave very differently.
A worked example
Take a function allocated 512 MB (0.5 GB) that runs 200 ms (0.2 s) per call. Each invocation uses 0.5 times 0.2, or 0.1 GB-second. A million invocations use 100,000 GB-seconds, at about $0.0000166667 each, or about $1.67 in duration. Add the request charge of $0.20 per million, and the total is about $1.87 per million calls. Notice the split: duration is roughly 89 percent of the cost, requests only 11 percent.
Now double the memory to 1 GB with the same 200 ms run time: duration doubles to about $3.33, and the total jumps to about $3.53. The per-request fee did not change, but the bill nearly doubled, because duration scales with memory. That is the lever that matters.
Where the cost actually lives
Because duration dominates, the levers that cut Lambda cost are the ones that reduce GB-seconds: shorten execution time (faster code, fewer synchronous waits, connection reuse), right-size memory so you are not paying for allocation you do not need, and switch to the ARM (Graviton) architecture for roughly 20 percent off duration, covered in the Lambda ARM savings guide. The per-request fee is fixed and small, so chasing it is rarely worthwhile.
The memory paradox
More memory costs more per second, but Lambda scales CPU with memory, so a function given more memory often runs faster, using fewer seconds. Sometimes doubling memory more than halves run time, so the cheapest setting is a higher memory tier, not the lowest. This is why memory tuning is empirical: test several memory sizes, measure the resulting duration, and pick the one with the lowest GB-second product, the method in the Lambda memory right-sizing guide. The lowest memory is not always the cheapest.
Putting it to work
Estimate your invocation volume, memory, and duration, then compute requests plus duration to get the cost per million and the monthly total. Focus optimization on duration: trim run time, tune memory empirically, and use ARM. For very high, steady volume, compare against running on EC2 or Fargate, which can win once the load is continuous. Price your Lambda functions against the resource catalog so the per-million cost is a known number before you deploy.
FAQ
How much does a million Lambda invocations cost?
It depends on memory and duration, but for a 512 MB function running 200 ms per call, about $1.87: roughly $0.20 in request charges (at $0.20 per million) plus about $1.67 in duration (100,000 GB-seconds at about $0.0000166667 each). The duration part is roughly 89 percent of the cost. ARM (Graviton) functions are about 20 percent cheaper on the duration charge, lowering the total further.
What is a GB-second in Lambda pricing?
A GB-second is one gigabyte of allocated memory for one second of execution. Lambda bills the duration charge as allocated memory in GB multiplied by run time in seconds, at about $0.0000166667 per GB-second for x86. So a 512 MB (0.5 GB) function running 200 ms (0.2 s) uses 0.1 GB-second per invocation. This duration charge usually dominates Lambda cost, far outweighing the flat per-request fee.
What is the biggest driver of Lambda cost?
Duration, not the per-request fee. The duration charge scales with allocated memory multiplied by run time, so it typically makes up around 85 to 90 percent of a function's cost, while the flat $0.20-per-million request fee is a small remainder. The levers that cut Lambda cost are therefore reducing execution time, right-sizing memory, and moving to the cheaper ARM architecture, not trying to reduce the request charge.
Does more Lambda memory always cost more?
Not necessarily. More memory costs more per second, but Lambda scales CPU with memory, so a function given more memory often runs faster and uses fewer seconds. Sometimes doubling memory more than halves run time, making a higher memory tier cheaper overall. The cheapest setting is found empirically by testing several memory sizes and picking the one with the lowest memory-times-duration product, not simply the lowest memory.
How does C3X help estimate Lambda cost?
C3X prices your Lambda functions from Terraform against a live catalog, so the cost per million invocations, based on memory, duration, and architecture, is visible in the pull request before you deploy. That lets you see the effect of a memory change or an ARM switch as a concrete number, and compare Lambda against EC2 or Fargate for high-volume workloads, rather than discovering the duration charge on the monthly bill.
What to do next
Know your Lambda cost per million before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.