Most Lambda bills are paying for memory nobody measured

Overview

Lambda cost is memory multiplied by duration, and the two are coupled — more memory means proportionally more CPU, so a larger function often finishes fast enough to cost less. Almost no estate is sized from measurement; functions inherit whatever the first developer typed, and the estate ossifies around it.

Challenge

The Lambda bill had grown into a material line item without a corresponding traffic increase. Sampling showed functions provisioned at high memory using a small fraction of it, CPU-bound functions starved at low memory settings and running far longer than necessary, functions idling on synchronous downstream calls while billed for the wait, and a set of scheduled functions running frequently while doing nothing most invocations.

Environment

A large AWS Lambda estate spanning API-backed, event-driven, and scheduled workloads. AceMQ advises on the customer's function configuration and architecture; AWS operates the platform.

Approach

AceMQ pulled per-function memory utilization and duration distributions from platform metrics and ran controlled sweeps across memory settings for the highest-spend functions to find each one's actual cost minimum, rather than assuming less memory is always cheaper. Architecture-level waste was reported separately from configuration waste, because they are fixed differently.

Solution

• Built a per-function cost model from measured memory utilization and duration distributions
• Ran memory sweeps on the highest-spend functions to locate each one's true cost minimum
• Identified CPU-bound functions where increasing memory reduces total cost
• Flagged functions billed while blocked on synchronous downstream calls as async redesign candidates
• Replaced high-frequency polling schedules with event-driven triggers where the source supports it
• Delivered a ranked change list with expected savings and risk for each

Outcome

Technologies