Lambda memory as a cost lever: finding the real sweet spot

Quick answer

Lambda allocates CPU in proportion to memory, so raising memory can lower total cost when the workload is CPU-bound. A function hits one full vCPU at 1,769 MB and gets additional vCPUs above that. For CPU-bound work, doubling memory from 512 MB to 1024 MB often halves duration, leaving the bill flat while latency improves; going further can make it cheaper outright. For I/O-bound work, duration barely changes and doubling memory doubles the bill. The sweet spot is the lowest memory at which duration stops improving proportionally, typically 512 MB to 1024 MB for API handlers and 1,769 MB or above for compute-heavy jobs.

Memory is the only performance dial on a Lambda function, and it is also the price dial. AWS allocates CPU proportionally to the memory you configure, so the setting controls both how fast your code runs and how much each millisecond costs. Those two effects pull in opposite directions, which means the cheapest configuration is rarely the smallest one.

How memory maps to CPU

Memory	Approx. vCPU	Cost per second (x86)
128 MB	0.07	$0.0000021
512 MB	0.29	$0.0000083
1024 MB	0.58	$0.0000167
1769 MB	1.00	$0.0000288
3538 MB	2.00	$0.0000575
10240 MB	~5.79	$0.0001667

The key threshold is 1,769 MB, where a function receives one full vCPU. Below that it gets a fraction of a core, so single-threaded CPU work scales almost linearly with memory. Above it, extra memory adds additional vCPUs, which only help if your code is actually multi-threaded or your runtime parallelizes work such as garbage collection, compression, or JSON parsing in native libraries.

The arithmetic that makes bigger cheaper

Cost per invocation equals memory in GB times duration in seconds times $0.0000166667. If doubling memory halves duration, those two changes cancel and cost stays flat while latency halves. If doubling memory cuts duration by more than half, which happens when a smaller configuration was thrashing or waiting on a throttled fraction of a core, the bigger function is strictly cheaper.

Memory	Duration (CPU-bound job)	Cost per 1M invocations
256 MB	3,200 ms	$13.53
512 MB	1,580 ms	$13.37
1024 MB	790 ms	$13.37
1769 MB	450 ms	$13.16
3008 MB	430 ms	$21.38

This is the classic shape: nearly flat cost from 256 MB to 1,769 MB with a six-fold latency improvement, then a sharp cost increase past the point where the job stops getting faster. The sweet spot here is 1,769 MB, where you get the best latency at the lowest cost. Notice that the smallest setting is not the cheapest, and the difference in user-visible latency between 256 MB and 1,769 MB is nearly three seconds for the same price.

When more memory is pure waste

I/O-bound functions behave the opposite way. A handler that spends 180 ms waiting on a DynamoDB query and 15 ms computing will run in roughly 195 ms at 512 MB and roughly 190 ms at 2048 MB. The network wait does not shrink with CPU. Quadrupling memory there takes the cost for 10 million invocations from $16.25 to $65.00 for a 3 percent latency improvement.

Workload type	Memory response	Typical sweet spot
API handler, mostly I/O wait	Flat	512 MB to 1024 MB
JSON transform, moderate CPU	Linear to ~1 vCPU	1024 MB to 1769 MB
Image or video processing	Strong, often multi-core	1769 MB to 3538 MB
Large dependency cold path	Init-dominated	Reduce package, not memory

The 1 ms billing granularity matters

Lambda bills duration in 1 ms increments, which changes how much a memory change is worth for very short functions. A handler that completes in 8 ms at 512 MB and 5 ms at 1024 MB costs $0.0000000667 per invocation in the first case and $0.0000000833 in the second, so the bigger configuration is more expensive despite being faster. Below roughly 20 ms of execution, per-invocation overhead and the $0.20 per million request charge dominate anyway: at 10 ms and 512 MB, the request fee is more than double the duration fee. For these functions, memory tuning is close to pointless and the only meaningful cost lever is reducing the number of invocations through batching.

Finding your curve

Do not guess. Run the function at 256, 512, 1024, 1769, and 3008 MB against a representative payload, record p50 and p95 billed duration at each, and compute cost per million as memory in GB times duration times $16.6667. Plot cost and latency together. Pick the point where cost is at or near its minimum and latency has flattened. Repeat when the function's work changes meaningfully, since the curve moves with the code.

Two multipliers apply on top. Arm architecture cuts the rate to $0.0000133334 per GB-second, about 20 percent off, and frequently runs the same code slightly faster, so re-tune after switching. And ephemeral storage above the free 512 MB bills separately at $0.0000000309 per GB-second, which is easy to forget in image pipelines. Combine memory tuning with the rest of yourserverless cost work and price the chosen configuration against the resource catalog so the setting is deliberate rather than inherited from a template default.

FAQ

Does increasing Lambda memory always increase cost?

No. Lambda allocates CPU proportionally to memory, so for CPU-bound work, doubling memory often halves duration and leaves the bill flat while latency halves. If duration falls by more than half, the larger configuration is strictly cheaper. Only for I/O-bound functions, where duration is dominated by network waits, does extra memory raise cost without benefit.

At what memory does Lambda get a full vCPU?

At 1,769 MB a function receives one full vCPU. Below that it gets a proportional fraction of a core, so single-threaded CPU work scales almost linearly with the memory setting. Above 1,769 MB, additional memory adds more vCPUs, which only helps if the runtime or code actually parallelizes work across cores.

What is the best Lambda memory setting?

It depends on the workload. API handlers dominated by I/O wait typically sit best at 512 MB to 1024 MB. Moderate CPU work such as JSON transformation usually peaks around 1024 MB to 1769 MB. Image and video processing often benefits up to 1769 MB or 3538 MB. The right answer is the lowest memory at which duration stops improving proportionally.

How do I measure the Lambda memory cost curve?

Run the function at 256, 512, 1024, 1769, and 3008 MB against a representative payload, record p50 and p95 billed duration at each setting, and compute cost per million invocations as memory in GB times duration in seconds times $16.6667. Plot cost and latency together and pick the point where cost is near minimum and latency has flattened.

Does Arm change the memory sweet spot?

It can. Arm bills at $0.0000133334 per GB-second instead of $0.0000166667, roughly 20 percent cheaper, and often executes the same code slightly faster. Both effects shift the cost curve down and can move the optimum, so it is worth re-running the memory sweep after migrating a function to Arm rather than carrying over the x86 setting.

How does C3X help with Lambda memory decisions?

C3X prices Lambda functions from Terraform, so the memory setting's cost implication is visible in the pull request at your expected invocation volume. That catches the common pattern of a template default carried into production, and makes the difference between 512 MB and 3008 MB explicit before the configuration ships rather than after a month of billing.

What to do next

Turn the memory dial with the price in view. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.