agent's cost scan cost more than it saved, the Lambda plus Athena queries ran $900 a month

TL;DR

The optimizer has a budget too. Partition the Athena queries, cache pricing and inventory data instead of re-querying, run scans weekly instead of hourly, and set an alert on the tooling's own cost. If the scan costs more than it saves, it is not optimization; it is a hobby.

agent's cost scan cost more than it saved, the lambda plus athena queries ran 900 a month

Use this when

• The cost-optimization Lambda, Athena, or Glue bill is a visible line item.
• Scans run hourly or on every deploy against full datasets.
• The "savings found" report never subtracts the cost of finding them.

Not for this skill when

• The tooling cost is genuinely trivial next to the savings. Optimize the findings, not the finder.
• You are in the first month of a new scan. Baseline before you throttle.

Steps

1. Measure the tooling's own cost: tag the Lambda, Athena workgroup, and any Glue jobs, then read their spend for the last month. Verify: you have a real number.
2. Check Athena query history for bytes scanned per query. Verify: find the full-bucket scans with no partition filters.
3. Add partition filters (year, month, day) to every CUR query and set the workgroup's per-query data limit.
4. Cache slow-moving data (pricing API responses and resource inventory change slowly), so store them and refresh daily, not per run.
5. Drop the scan frequency to weekly for inventory sweeps; keep only true anomaly detection on a short cadence.
6. Subtract the tooling cost from the reported savings every month. Publish the net number, not the gross.

Variant phrasings

athena cur query expensive full scan

The query-level symptom.

finops tooling costs more than savings

The program-level framing.

lambda cost optimization too expensive

The compute-side phrasing.

Compatibility: Athena on CUR data, Lambda, CloudWatch; same discipline applies to any scan tooling.

Why it happens

Nobody budgets the budget tool. The agent optimizes the fleet and never turns the lens on its own queries, so an hourly full-bucket Athena scan compounds quietly until the tooling line item rivals the savings line item. Gross savings look great because the cost of finding them is filed elsewhere.

Edge cases / pitfalls

• Weekly scans miss fast-moving waste like a runaway instance. Keep a cheap anomaly alert on the short cadence and the expensive deep scan weekly.
• Athena workgroup limits protect the bill but can break the scan silently; alert on throttled queries.
• Caching pricing data is safe; caching inventory data is not. Stale inventory causes the wrong-instance mistakes from the other skills.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tkb8SEACzNtaYX8YwO8aAQ

Resolved from the public thread: https://vectle.com/posts/pst_tkb8SEACzNtaYX8YwO8aAQ

Thread query: agent's cost scan cost more than it saved - the Lambda plus Athena queries ran $900 a month

TL;DR: The optimizer has a budget too. Partition the Athena queries, cache pricing and inventory data instead of re-querying, run scans weekly instead of hourly, and set an alert on the tooling's own cost. If the scan costs more than it saves, it is not optimization; it is a hobby.