Right-sizing Lambda memory: Why more can actually cost less

The cheapest Lambda memory configuration is rarely the lowest one. A function sized at 512 MB for the same workload can cost more than the same function at 1536 MB, because the higher memory gives you CPU and the function finishes 3x faster. Billing is on compute-seconds. Faster execution beats cheaper per-second rates.

How Lambda billing actually works

AWS charges you in gigabyte-seconds. You pick a memory allocation (128 MB to 10,240 MB). AWS gives you proportional CPU. Higher memory gets more CPU. Your function runs. You're billed for how many seconds it ran, multiplied by how much memory you allocated.

If a function takes 10 seconds at 256 MB, it costs 10 × (256 / 1024) = 2.5 GB-seconds. If you increase to 1024 MB and it finishes in 3 seconds, it costs 3 × (1024 / 1024) = 3 GB-seconds. You're paying 20% more but your function is 3x faster.

For production workloads, speed often matters more than raw memory cost. Faster response times mean better user experience, lower latency for APIs, quicker data processing. This is why just picking the minimum memory is usually wrong.

Memory and CPU scale together

Lambda scales CPU with memory. At 128 MB you get minimal CPU. At 256 MB you get roughly double the CPU. At 512 MB you get roughly double again. This scaling continues until 1,769 MB, where you get one full vCPU. Beyond that, CPU increases more gradually.

For CPU-bound functions (anything doing computation, data transformation, image processing, file compression), more memory and more CPU make a real difference. A machine learning inference function at 512 MB might take 2 seconds. At 1024 MB it might take 0.8 seconds.

For network-bound functions (anything waiting on external APIs or database queries), more CPU barely helps. Adding memory won't speed up a function blocked waiting for a 500ms DynamoDB call.

Test your workload. Use CloudWatch to see if your function is CPU-bound (high execution time) or network-bound (low CPU usage but long execution time).

Finding the optimal size

Start by identifying what your function actually needs. Look at these CloudWatch metrics:

Duration tells you total execution time. Max Memory Used tells you peak memory during execution. Billed Duration is what AWS actually charges (rounded up). Compare Max Memory Used against your allocated memory. If you allocate 512 MB but only use 200 MB, you're wasting money.

Use AWS Compute Optimizer. Point it at your Lambda function. It analyses 14 days of CloudWatch data (minimum 50 executions) and recommends a memory configuration that balances cost and performance. It's not perfect, but it's a useful starting point.

For more detailed analysis, use AWS Lambda Power Tuning. This open-source tool tests your function across multiple memory settings and shows you a chart of cost versus performance. Run your actual workload against different memory allocations (256 MB, 512 MB, 1024 MB, 1536 MB, 3008 MB) and see which one gives you the best cost per invocation for your use case.

The step-by-step approach

First, understand your function's actual requirements. Is it processing images or PDFs? That's CPU-bound. Is it calling an API? That's network-bound. Is it both? Figure out which dominates the execution time.

Second, set CloudWatch alarms. Monitor Max Memory Used and execution duration. If memory usage consistently stays below 50% of allocation, you're over-provisioned. If it's consistently above 80%, you might be throttling.

Third, test with Power Tuning. Set it to test a reasonable range around your current setting. Let it run your function 100 times at each memory level. The output chart will show you the cost and performance trade-off.

Fourth, apply the recommendation and monitor for a week. Watch error rates, latency, and memory usage. If everything looks good, stick with it. If not, adjust again.

Don't make huge jumps. If you're at 512 MB, don't jump to 3008 MB. Try 1024 MB. Wait a week. Adjust again. Small steps let you catch problems early.

Real costs vs benchmarks

The AWS free tier gives you one million requests and 400,000 GB-seconds monthly. For many small functions, this covers production workloads entirely.

For paid workloads in the UK, Lambda costs roughly £0.33 per million requests plus about £0.0000166 per GB-second. A function using 1 million monthly invocations at 512 MB taking an average 100ms costs about £0.82 per month in compute. Hosting, observability, and network egress will dwarf this.

If you're paying £50 per month in Lambda costs, it's worth spending 2 hours optimising. If you're paying £5, it's not. Optimise the high-volume functions first.

Practical considerations

For non-critical or non-customer-facing functions (batch jobs, data processing, cleanup tasks), leave memory at the lowest setting that doesn't fail. Cost optimisation is the goal.

For customer-facing APIs and latency-sensitive work, test aggressively. A 200ms improvement in p99 latency is worth paying for.

For microservices, size each function for its specific workload. Don't use the same memory for a simple request router as you use for a ML inference function.

Keep code lean. Remove unused dependencies. Each library you import slows cold starts and increases memory usage. Import only what you need.

Use ARM-based Graviton processors if your runtime supports them. They're about 20% cheaper and often faster than x86.

Monitoring as an ongoing practice

Memory optimisation isn't a one-time task. As your code evolves, dependencies grow, and workloads change, revisit your sizing quarterly.

Use CloudWatch Logs Insights to create custom queries for memory usage trends. Look for creeping memory leaks, increasing baseline memory, or degrading performance.

Add Lambda memory checks to your deployment pipeline. Before deploying, run Power Tuning on the new version and compare the results to the old version. If memory usage increased 20%, investigate why.

Set up dashboards that track your cost per invocation across all Lambda functions. If cost per invocation is creeping up, something's wrong.

Where Critical Cloud comes in

Right-sizing only works if you can trust the data. You need clear visibility into what your functions are actually doing, how memory usage correlates with performance, and whether your optimisation actually worked in production.

We're a Powered by Datadog accredited partner, and we instrument Lambda performance deeply. That means monitoring cold starts, warm execution performance, memory patterns, and cost per invocation.

If Lambda optimisation is eating your time or you're not confident in your sizing decisions, see how Critical Support works.