I love the convenience, simplicity and auto-scaling behavior of AWS Lambda. Its liberating to focus on what your function does and not at all on the servers needed to run it. It can be a very cost-efficient option too. The pay-for-usage model is great for any kind of intermittent workload, and you aren't paying for an EC2 instance sitting idle at 3am.

Of course, at Frugal we tend to see the dark side of cost, and you can certainly get into trouble with Lambda. So, happy to announce that Frugal is now ready to help with AWS Lambda! We analyse your Lambda bill, pull in the usage metrics behind it, and attribute the cost back to the code and components doing the spending. We help you fix the problems in the Lambdas you're running today, and we bring that same cost and usage information to your coding agent and your PR review so the next batch doesn't repeat them.

A per-millisecond purchasing decision

Lambda prices are a function of how much memory you allocated, which CPU architecture you picked, how long the handler ran, and how much capacity you kept warm for the moments it wasn't running at all. Then there's the log volume on the way out, which for a chatty function can cost more than the compute did.

A bunch of those are numbers somebody typed into a YAML file once. Usually while getting something working, applying a healthy margin and never revisited. A healthy margin during development looks a lot like cloud waste once it reaches production.

I wrote up the ten patterns we see most often in The Frugal Approach to AWS Lambda Costs, memory, architecture, timeouts, warming, batching, retry storms, idle waits, logging, and the rest. That post describes the cost traps when using Lambda, see below for how we now surface those in Frugal.

Let's see it

Start with the money, because that's the part that decides what you look at next.

Every deployed function, ranked by cost, with runtime and architecture right there in the table. This account has 1,703 Lambda functions. The top one is $1,819 a month and 26% of the Lambda bill on its own, and the ten on this first page are about 85% of it between them. For our Lambda optimization mission the other 1,693 are basically noise. This table is our first stop and gets us focused on the Lambda functions that matter for cost. It shows you which handful of functions is worth an afternoon and gives you permission to ignore the rest.

So where does Lambda cost go wrong? For many of these the answer is sitting in the IaC: the serverless.yml or the Terraform module where somebody picked a number once and moved on.

For each of these five functions, fifty units of provisioned concurrency are being held warm around the clock so users don't exprience cold starts. Usual peak across them runs between 5.83 and 16.39. The recommendation is that peak plus AWS's suggested 10% buffer, which lands between 7 and 19, and the gap is $5,151 a month of capacity sitting there waiting for traffic that never arrives.

A useful detail included in the Detected State is the spillover count. "Reduce your provisioned concurrency" is easy advice to give and hard to take, because nobody wants to be the person who brought back cold starts. So Frugal also tells you how often the provisioned capacity was actually exceeded. In this case there were 50 invocations, which arms the engineer with the data they need to decide the tradeoff.

A problem of a similar shape is found one line further down the config. With memory utilization between 15 and 26%, 6,272 MB of allocation is doing nothing. One function is configured at 3072 MB and has never used more than 468 MB. Right-sizing against P95 plus headroom saves another $1,009 a month.

Note the CPU column and the considerations that come with it. Lambda ties CPU allocation to memory, so cutting memory on a CPU-bound function makes it run longer and can cost you more than it saves. Frugal grades each function's CPU sensitivity, adjusts the savings estimate down where the risk is real, and tells you to run Power Tuning before any reduction over 50%. It also tells you to do the Graviton migration first if you're doing both, since ARM changes the CPU-to-memory relationship you'd be tuning against.

Then the timeout, on that same top function: configured to run for 300 seconds, never once taken more than 1.6. A ratio of 188x, and $380 a month.

The money is the smaller half of the argument on this one. A five-minute timeout is a five-minute blank cheque for any invocation that gets stuck on a hung connection or wanders into a loop, which is the difference between a bad afternoon and a bad afternoon that also turns up on the bill. The number you're managing there is the worst case, not the average.

What the source code tells you

Some optimization opportunities are only identified once Frugal looks at the source code of the function itself.

Every function on that first page was x86_64, which is common enough. Graviton is about 20% cheaper for the same compute, so moving to arm64 is usually worth doing. The hard part isn't deciding, it's knowing whether the function will still run once you have. Native dependencies compiled for x86, a Lambda layer shipping x86 binaries, a compiled extension somewhere down in the dependency tree — any of those will break the migration, and none of them show up in the console.

Frugal reads the source and the deployment config together and grades each function. Runtime, layers, complexity. Six function definitions across twelve deployed instances, all pure interpreted Python and Node, no layers, all low complexity. That's a migration you can schedule instead of a migration you have to investigate first.

Frugal reads the handler code too, looking for the things that cost money no matter how the function is configured: blocking on a third-party call, logging every field of every event, processing SQS records one at a time instead of in batches.

From recommendation to patch

For the fixes where the change can be determined by the machine, it will codes it up so you don't have to.

That's the $5,151 concurrency fix from earlier, as a git patch. Five files, +21/−8. It didn't just drop the numbers in, either: it pulled the hardcoded provisionedConcurrencyMax out into a per-environment parameter, so prod gets 13, test gets 11, and the next person to change it doesn't have to touch three serverless.yml files to do it. Download the patch, review it like any other diff, ship it.

Not doing it again

Fixing the deployed state is half the job. The other half is that the same mistake gets written again next sprint, usually by an agent, usually in a PR that looks completely reasonable.

The change makes a new function that renders branded PDFs through a third-party API. It submits the job, then sits in a sleep(5) loop until the vendor finishes. Actual compute in the handler is 1.4 seconds. The other 96 seconds is time.sleep(), billed at 2,048 MB, 420,000 times a month.

98.6% of that function's bill buys nothing. The code works, the PDFs come out branded, it would likely pass a review that is only looking at correctness, coding style and security. But Lambda bills wall-clock duration rather than work done, so the vendor's render time quietly becomes your compute bill. Frugal flags it at the pull request with the number attached, and the fix is a Step Functions wait state instead of a sleep loop.

Better to have that conversation in the PR than in next month's cost review.

Where this goes

With Lambda, cost originates from two places. Half of it is configuration — memory, architecture, timeout, concurrency — sitting in files in your repo. The other half is what the handler does between the first line and the return, which no amount of staring at the AWS console will tell you. Frugal uniquely combines your IaC code, your function code, your usage and cost data into one correlated dataset that takes the guesswork and experimentation out of making your Lambda usage efficient.

Find the functions that matter, size them against what production actually did, read the code for the patterns that waste money by design, then put a reviewer on the pull request so the next one doesn't ship. Same loop we run for AI, storage, logging, and databases. Lambda's just where the config and the code are closest together.

Here I am talking about it, if you'd rather watch: https://www.youtube.com/shorts/l6vMKYuo1OU

Looking for help with cost optimizations like these? Book a Demo to see Frugal in action.