Most Lambda bills are paying for memory nobody measured
AWS LambdaAmazon SQS
Docker
PostgreSQLRight-sizing the top-spend functions reduced Lambda spend meaningfully without any latency regression, and several CPU-bound functions got both cheaper and faster once memory was raised.
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
- 1Built a per-function cost model from measured memory utilization and duration distributions
- 2Ran memory sweeps on the highest-spend functions to locate each one's true cost minimum
- 3Identified CPU-bound functions where increasing memory reduces total cost
- 4Flagged functions billed while blocked on synchronous downstream calls as async redesign candidates
- 5Replaced high-frequency polling schedules with event-driven triggers where the source supports it
- 6Delivered a ranked change list with expected savings and risk for each
Outcome
Right-sizing the top-spend functions reduced Lambda spend meaningfully without any latency regression, and several CPU-bound functions got both cheaper and faster once memory was raised.
Technologies
AWS LambdaAmazon SQSDockerPostgreSQLRelated Use Cases
AWS Lambda Event-Source Architecture Consulting
Designing event-source mapping, batching, ordering, and failure handling for a Lambda estate that had grown without a consistent event architecture.
Azure Functions Cost and Scaling Assessment
Reviewing hosting plan choice, instance scaling behavior, and cold start impact across an Azure Functions estate to align cost with actual workload shape.
AWS Lambda SQS Redrive Loop Remediation
Breaking a redrive loop where SQS messages were reprocessed indefinitely because the queue visibility timeout was shorter than the Lambda function timeout.
AWS Lambda VPC Networking and ENI Exhaustion Support
Diagnosing VPC-attached Lambda invocation failures caused by ENI and subnet IP exhaustion during scale-out, and the connection handling that made it worse.
MuleSoft Streaming Strategy and OOM Remediation
Resolving out-of-memory failures in a Mule application that buffered entire multi-hundred-megabyte payloads because no repeatable streaming strategy was configured.
WSO2 Platform Architecture Assessment
Reviewing a WSO2 deployment's topology, database layout, high availability posture, and gateway sizing against its actual traffic profile.
Ready for an AWS Lambda Health Check?
AceMQ's senior AWS Lambda engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.