More Lambda memory can cost less. Idle Lambda still costs.

Lambda bills memory times duration. CPU rides along with the memory slider. For a tight numeric job, 1024 MB that finishes in 2.5s can beat 512 MB that crawls for 6s. You pay a higher rate for fewer milliseconds.

That is a real lever. It is also a lab result. Unit prices move. Your payload is not our payload. Measure with AWS Lambda Power Tuning on your function, then pick a size. Do not copy a blog table into production.

Two different problems

Right-sizing memory is for functions that actually run. The other problem is quieter: functions that almost never run, or that sit on x86 in a region where Arm is cheaper, or that were given 3008 MB "to be safe" and peak at 200.

Cost Explorer will show you a Lambda line. It will not tell you which function is over-provisioned. Compute Optimizer can, for memory, if you opened it. Most teams do not.

What we flag

unusd.cloud is not a profiler. We do not retune every handler. The scan looks for waste you can act on without a research project: idle patterns, over-sized memory vs observed use, and x86 functions that are candidates for Arm where it is available. Navi can then draft the change notes from those findings. It does not deploy them.

If Lambda is a rounding error on your bill, skip this. If it is a product surface, tune the hot paths and delete the cold ones. Run a read-only scan when you want the idle list instead of another spreadsheet.