Monthly AWS Lambda cost review and right-sizing board

Build me a review board I open once a month to find the money my AWS Lambda functions are quietly wasting, and fix it on the spot. It is a single screen, not something that runs on a schedule. I open it, it loads the current state of the account, I work down the list approving fixes, and every fix I approve gets logged.

Loading the inventory. Use AWS Lambda List Functions to pull every function in the account and region, following the NextMarker and Marker pagination until the list is complete. List Functions already returns the full configuration for each function, so read memory size, architecture, timeout, runtime, code size, package type, last modified date and handler straight from that response rather than making a second call per function. Use Get Function Configuration for the detail panel refresh and for the polling described later. For each function also call Get Function Concurrency to read any reserved concurrency, and List Provisioned Concurrency Configs, which is per function, to read any provisioned concurrency allocated to its versions or aliases. Show a progress indicator while this loads, because an account with a lot of functions means a lot of calls, and cache the result for the session so moving around the board does not refetch everything.

Loading the usage. For each function pull the last 30 days from Amazon CloudWatch using Get Metric Statistics against the AWS/Lambda namespace with a FunctionName dimension. Fetch four metrics: Invocations, Duration, Errors and Throttles. Get Metric Statistics covers one metric per call but accepts several statistics in the same call, so for Duration request Sum, Average and Maximum together. The Sum of Duration is the total compute time and is what the cost estimate should be built on, while Average and Maximum drive the headroom flag. Use Sum for Invocations, Errors and Throttles. This fans out to roughly four calls per function, so run them with limited concurrency, and handle the CloudWatch 400 Throttling response with exponential backoff rather than failing the whole page. If a metric returns no datapoints, treat it as zero invocations rather than as an error, because that is exactly how a zombie function looks.

Estimating cost. Compute monthly cost per function as compute cost plus request cost. Compute cost is the total Duration in seconds multiplied by the memory in gigabytes multiplied by the per gigabyte-second rate, where the rate depends on architecture: use 0.0000166667 for x86_64 and 0.0000133334 for arm64 as editable defaults. Request cost is invocations multiplied by 0.20 per million. If a function has provisioned concurrency, add its cost separately: allocated concurrency multiplied by memory in gigabytes multiplied by the seconds it was enabled multiplied by a provisioned rate, defaulting to 0.0000041667. Put all of these rates in a settings panel so I can edit them to match my region or negotiated pricing, and show on screen which rates the current numbers were calculated with. Make clear in the UI that these are estimates and do not account for free tier, credits or discounts.

The main table. One row per function, sorted by estimated monthly cost descending so the biggest spenders are at the top. Columns: function name, estimated monthly cost, invocations, average duration, maximum duration, timeout, memory, architecture, runtime, code size, errors, throttles, reserved concurrency and provisioned concurrency. Above the table show account level totals: total estimated monthly spend, total identified waste and how many functions carry each flag. Let me sort by any column, filter by flag, and search by name prefix. Clicking a row opens a detail panel with the full configuration, the 30 day metric trend and the suggested fixes for that function.

The four flags. First, timeout headroom: flag functions whose average duration is a tiny fraction of their configured timeout, defaulting to under 10 percent, where invocations are above zero. Be honest in the flag description that a high timeout does not itself cost money, since Lambda bills actual runtime, so the value of lowering it is capping the damage when an invocation hangs rather than a guaranteed monthly saving. Second, Graviton: flag every function still on x86_64, with an estimated saving of roughly 20 percent of its compute cost. Third, idle warm capacity: flag functions that have provisioned concurrency allocated while their invocation count over 30 days is below a configurable floor, and show the full cost of that provisioned concurrency as the saving, because this is usually the single biggest line item on the board. Fourth, zombies: flag functions with zero invocations across the whole 30 days, showing how long they have been idle and their code size.

Be honest about one real limit, visibly in the UI and not buried. The actual memory consumed per invocation is not published as a CloudWatch metric, so there is no way for this app to know how much of the configured memory a function truly uses. Every memory right-sizing suggestion must therefore be presented as an estimate inferred from duration and timeout headroom, never as a measured fact, and must always require my approval instead of being applied automatically. Also state the point that makes this genuinely tricky: memory sets processor power, so the lowest setting is not the cheapest setting. A function at 512MB can finish faster and cost less than the same code at 128MB. Where a suggestion lowers memory, warn that it may increase duration and should be watched after applying.

Inline fixes, each confirmed before it runs. Every flagged row gets an action button that opens a confirmation dialog showing the current setting, the proposed setting and the estimated monthly saving before anything happens. Changing memory or timeout uses Update Function Configuration. Removing wasted warm capacity uses Delete Provisioned Concurrency Config. Setting a scaling cap uses Put Function Concurrency. Keep reserved concurrency and provisioned concurrency clearly separate in the interface, with distinct labels and distinct actions, because they are different features on different API paths and conflating them would be misleading. For container image functions, where package type is Image, show the Graviton flag as advisory with an explanation that the image has to be rebuilt for arm64 first, and do not offer a one-click switch.

Handle the asynchronous update properly. Update Function Configuration returns while the function is still updating, so after applying a change poll Get Function Configuration until State is Active and LastUpdateStatus is Successful before showing the row as done. Show a pending state in the row while polling, and surface a clear error if LastUpdateStatus comes back as Failed, including the reason. Handle a 409 ResourceConflictException, which means the function is busy, by retrying rather than reporting a hard failure.

Logging. Every change I accept appends a row to a Google Sheets log using Append Values, capturing the timestamp, function name, region, which fix was applied, the before setting, the after setting and the estimated monthly saving. Only log changes that actually completed successfully, never ones that failed or that I cancelled. Let me set the spreadsheet and tab in settings, and create the header row on first use. Show a running total of logged savings somewhere on the board so I can point at one number for what we clawed back this month.

Handle the empty and unhappy paths gracefully: an account with no functions, a function with no metric data at all, a credential that can read but not write, which should disable the fix buttons with an explanation rather than hiding them, and a CloudWatch or Lambda call that fails partway through the load, which should show what did load alongside a retry.