I Tested AWS Lambda at 128 MB, 256 MB, 512 MB, and 1 GB - Here's What Happened
I benchmarked the same CPU-bound workload across four AWS Lambda memory configurations and analyzed the resulting performance, memory usage, and estimated compute cost. The experiment also uncovered some interesting differences between local SAM testing and real Lambda execution.
Series: Serverless in Practice (3 articles)
- 1I Tested AWS Lambda at 128 MB, 256 MB, 512 MB, and 1 GB - Here's What Happened This article
I wanted to answer a simple question:
How much does AWS Lambda memory configuration actually matter for a CPU-bound workload?
So I ran the same deterministic SHA-256 hashing workload on AWS Lambda at 128 MB, 256 MB, 512 MB, and 1 GB.
The result was more interesting than I expected.
The 1 GB configuration was roughly 8× faster than 128 MB.
But there was a catch.
The fastest configuration wasn't the cheapest one.
And before getting to those results, I ran into another interesting problem: my local Lambda testing wasn't behaving anything like the real AWS environment.
The Experiment
The goal was to isolate the effect of Lambda's memory configuration on a CPU-bound workload.
I kept everything else as consistent as possible:
- Runtime: Python 3.13
- Architecture: x86_64
- Region: ap-south-1 (Mumbai)
- Timeout: 30 seconds
- Workload: deterministic SHA-256 hashing
- Memory configurations: 128 MB, 256 MB, 512 MB, 1024 MB
- Invocations: 10 per configuration
- Total benchmark runs: 40
The basic architecture looked like this:
Benchmark runner → AWS Lambda → CPU workload → JSON result → Local results file → Charts
The Lambda function itself didn't store benchmark results. Each invocation returned its measurements as JSON, and the benchmark script collected them locally.
Local Lambda Isn't Real Lambda
One of the first things I learned during this experiment was that a Lambda function running locally through SAM isn't necessarily representative of the real Lambda environment.
I initially used AWS SAM and Docker to test the function locally.
The function worked. The workload completed. Everything looked fine.
Then I deployed it to AWS. And things got weird.
The Timeout Story
My initial workload was intentionally heavy.
It created roughly 10 MB of data and repeatedly hashed it 100 times.
Locally, it completed in under a second.
On AWS Lambda at 128 MB, however, it hit the 30-second timeout.
CloudWatch showed:
- Memory Size: 128 MB
- Max Memory Used: ~51 MB
- Duration: 30,000 ms
- Status: Timeout
CloudWatch logs showing the CPU-bound workload repeatedly hitting the 30-second timeout at 128 MB, despite using only 51 MB of memory.
The important part was the memory usage.
The function wasn't running out of memory.
It simply wasn't getting enough CPU to finish the workload within the timeout.
That forced me to rethink the benchmark.
Calibrating the Workload
Instead of making the workload so heavy that the lowest memory configuration couldn't finish, I reduced the hashing loop from 100 iterations to 10.
This produced a workload that was still CPU-bound, but allowed all four configurations to complete successfully.
That made the comparison much more useful.
The benchmark was now testing:
How does giving Lambda more memory - and therefore more CPU - affect execution time and cost for the same CPU-bound workload?
The Benchmark
I ran 10 invocations at each memory configuration.
That gave me 40 real AWS Lambda measurements.
The results were remarkably consistent.
| Memory | Average | Median | p95 | p99 |
|---|---|---|---|---|
| 128 MB | 4147.03 ms | 4141.14 ms | 4259.10 ms | 4272.88 ms |
| 256 MB | 1930.65 ms | 1932.88 ms | 1952.60 ms | 1957.24 ms |
| 512 MB | 875.62 ms | 873.10 ms | 899.50 ms | 906.16 ms |
| 1024 MB | 517.86 ms | 518.57 ms | 530.82 ms | 534.89 ms |
The trend was very clear.
As memory increased, execution time dropped dramatically.
Average execution time drops sharply as Lambda memory increases, falling from 4.15 seconds at 128 MB to just 0.52 seconds at 1 GB.
1 GB Was About 8× Faster
At 128 MB, the workload took an average of 4.15 seconds.
At 1 GB, it took just 0.52 seconds.
That's approximately an 8.01× speedup.
| Memory | Speedup vs 128 MB |
|---|---|
| 128 MB | 1.00× |
| 256 MB | 2.15× |
| 512 MB | 4.74× |
| 1024 MB | 8.01× |
Increasing memory delivers substantial CPU performance gains, with the 1 GB configuration achieving an 8.01× speedup over the 128 MB baseline.
This is exactly the kind of behavior you would expect from a CPU-bound Lambda workload.
Increasing the memory allocation doesn't just give the function more RAM.
It also gives the function access to more CPU resources.
But Here's the Interesting Part: Memory Usage Barely Changed
Despite the huge difference in execution time, the actual memory used by the function stayed almost constant.
| Memory Allocation | Average Used | Maximum Used | Utilization |
|---|---|---|---|
| 128 MB | 28.77 MB | 28.77 MB | 22.48% |
| 256 MB | 28.80 MB | 28.80 MB | 11.25% |
| 512 MB | 28.74 MB | 28.81 MB | 5.63% |
| 1024 MB | 28.47 MB | 28.49 MB | 2.78% |
Memory consumption remained nearly constant at around 28–29 MB across all Lambda configurations, showing that the performance gains came from additional CPU resources rather than higher memory usage.
This is an important distinction.
The workload wasn't asking for more memory.
It was benefiting from the additional CPU capacity associated with higher Lambda memory configurations.
So if you looked only at memory utilization, you might conclude that 128 MB was already more than enough.
For this workload, that would be misleading.
Why Does More Memory Make Lambda Faster?
AWS Lambda allocates CPU power proportionally with memory.
That means increasing the configured memory can increase the CPU resources available to the function.
For a CPU-bound workload like repeated SHA-256 hashing, that can have a huge effect.
The workload doesn't suddenly become more efficient.
The Lambda execution environment simply has more computational resources available to finish it.
This is why the same code went from roughly:
4.15 s → 1.93 s → 0.88 s → 0.52 s
as memory increased.
The Cost Calculation
Here's where things get interesting.
Lambda pricing for duration is based on GB-seconds, meaning both memory allocation and execution duration affect compute cost.
For this experiment, I estimated compute cost using:
GB-seconds = Memory in GB × Execution time in seconds
and:
Compute cost = GB-seconds × $0.000020
These calculations use the measured average workload duration and exclude request charges and other account-level billing factors.
| Memory | Avg Duration | GB-seconds / Invocation | Estimated Cost / Invocation | Estimated Cost / 1M |
|---|---|---|---|---|
| 128 MB | 4.147 s | 0.518 | $0.00001037 | $10.37 |
| 256 MB | 1.931 s | 0.483 | $0.00000965 | $9.65 |
| 512 MB | 0.876 s | 0.438 | $0.00000876 | $8.76 |
| 1024 MB | 0.518 s | 0.518 | $0.00001036 | $10.36 |
Estimated compute cost varies with both memory allocation and execution time, with 512 MB producing the lowest cost at approximately $8.76 per million invocations for this workload.
And that's the part I didn't expect.
The fastest configuration wasn't the cheapest.
512 MB Was the Sweet Spot
For this particular workload, 512 MB produced the lowest estimated compute cost while still being dramatically faster than the 128 MB configuration.
Compared with 128 MB:
- 256 MB: 2.15× faster, ~7% lower estimated compute cost
- 512 MB: 4.74× faster, ~16% lower estimated compute cost
- 1024 MB: 8.01× faster, roughly the same estimated compute cost
So 512 MB was the sweet spot in this experiment.
Not because 512 MB is universally the best Lambda configuration.
It isn't.
The optimal setting depends heavily on the workload.
But for this specific CPU-bound workload, it provided a very attractive balance between latency and compute cost.
The Diminishing Returns Become Interesting
Going from 128 MB → 256 MB gave a huge improvement.
Going from 256 MB → 512 MB gave another huge improvement.
Going from 512 MB → 1024 MB still made the function faster, but the cost started moving back upward.
That's an important lesson when tuning Lambda functions:
Don't automatically choose the largest memory configuration just because it's the fastest.
And don't automatically choose the smallest one because it uses less memory.
Benchmark the actual workload.
What This Experiment Taught Me
There were a few lessons that stood out.
1. Memory configuration can be a CPU configuration
For CPU-bound workloads, Lambda memory isn't simply about preventing out-of-memory errors.
Increasing memory can significantly increase available CPU resources and reduce execution time.
2. Local Lambda testing has limits
SAM + Docker was useful for checking whether the function worked.
But the actual performance characteristics were only meaningful when measured on real AWS Lambda.
3. More memory doesn't necessarily mean more memory usage
My function used around 28–29 MB across every configuration.
The dramatic performance improvement came from additional compute resources, not from needing more RAM.
4. Fastest doesn't necessarily mean cheapest
1 GB was the fastest configuration.
512 MB was the cheapest configuration in this experiment.
That's why Lambda optimization is really a performance-versus-cost problem.
Limitations
This experiment has some obvious limitations.
Only one workload was tested: a deterministic CPU-bound SHA-256 hashing workload.
Only four memory configurations were tested.
Each configuration had 10 invocations.
The benchmark also used estimated compute costs rather than attempting to reproduce an exact AWS invoice.
Cold starts, runtime initialization, account-level free-tier effects, request charges, and other AWS billing details can affect actual production costs.
So these results shouldn't be interpreted as:
"Always use 512 MB for Lambda."
The correct takeaway is:
Measure your workload before choosing a memory configuration.
Final Results
Here's the entire experiment in one table:
| Memory | Avg Time | Speedup | Estimated Cost / 1M |
|---|---|---|---|
| 128 MB | 4.147 s | 1.00× | $10.37 |
| 256 MB | 1.931 s | 2.15× | $9.65 |
| 512 MB | 0.876 s | 4.74× | $8.76 |
| 1024 MB | 0.518 s | 8.01× | $10.36 |
Execution time falls sharply as Lambda memory increases, reaching an 8.01× speedup at 1 GB, while 512 MB delivers the lowest estimated compute cost.
The pattern is pretty hard to miss:
More memory → more CPU → shorter execution time.
But the relationship between performance and cost isn't linear.
For this workload, 512 MB delivered the best balance.
Reproduce the Experiment
The entire benchmark was designed to be reproducible.
The project contains:
- AWS SAM infrastructure
- Lambda function code
- Benchmark runner
- Results JSON
- Chart generation script
- Troubleshooting notes
- Experimental results
The project separates AWS Lambda execution, benchmark collection, result storage, and analysis into a simple workflow designed for reproducibility.
The benchmark runner invokes the deployed Lambda function multiple times at each memory configuration and stores the results locally.
The charts are then generated from the collected results.
Final Takeaway
I started this experiment expecting a fairly predictable result:
More Lambda memory should make a CPU-heavy function faster.
That part was correct.
What surprised me was how dramatic the difference was.
The exact same workload went from 4.15 seconds at 128 MB to 0.52 seconds at 1 GB.
That's an 8× performance improvement.
But the fastest configuration wasn't the most cost-efficient.
For this workload, 512 MB was the sweet spot, delivering nearly 5× the performance of 128 MB while also producing the lowest estimated compute cost.
And that's probably the biggest lesson from the experiment:
Lambda memory configuration isn't just a memory decision. It's a performance and cost decision.
If your Lambda function is CPU-bound, the only reliable way to find the right configuration is to benchmark it.
Series: Serverless in Practice (3 articles)
- 1I Tested AWS Lambda at 128 MB, 256 MB, 512 MB, and 1 GB - Here's What Happened This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article