An Approval-Gated Agent Cut My CloudWatch Logs Bill by 4%

AWS published a cost optimization guide  for CloudWatch Logs a little while back, and the framing stuck with me: ingestion is a one-time cost, but storage compounds for as long as the data sits there. Three levers get you out of it. Pick Infrequent Access as the log class when you create a group. Turn on Intelligent Tiering so cold data drifts into cheaper storage automatically. Set a retention policy so nothing accumulates forever.

All three are sound advice. None of them tell you how much they're actually worth on your bill. So I built something that would tell me, and I made sure it couldn't delete anything without asking first.

LogCost Gate scans a fleet of log groups, asks Bedrock (Claude Sonnet 4.6) to explain what it's looking at in plain language, and splits every recommendation into two lanes. Turning on Intelligent Tiering is reversible, so it runs automatically. Setting a retention policy on a group that currently keeps everything forever will eventually delete data, so that one waits for a checkbox. It's a small version of a rule I keep coming back to: reversible changes can run on their own, anything that destroys data earns a human in the loop.

The rule engine that decides which lane a recommendation belongs to is plain TypeScript, not the model. Claude's job is narrower: given the numbers for each group — days since last access, current retention, daily ingest volume — write one sentence explaining why the recommendation applies. I did not want the model inventing the diagnosis; I wanted it translating a diagnosis I'd already computed into something a human skims in two seconds.

That plan survived first contact with a small bug. My first prompt asked the model to also count how many log groups had unbounded retention as part of its summary. It said seven. The actual number, computed in code two lines above the prompt, was eight. Nothing about the math was hard — the model just isn't a reliable counter of a list it's also writing prose about. I fixed it by computing the count myself and handing it over as a fact in the prompt instead of a question. Small lesson, but it's the kind of thing you only notice by running the tool against real output instead of reading the prompt and assuming it's fine.

I pointed it at twelve log groups modeled on a realistic small production fleet — Lambda functions, an ECS service, VPC flow logs, an RDS audit trail — sized with unit prices from CloudWatch Logs' published pricing structure rather than a real account, since I didn't want to wire an experimental tool to production billing data just to write a blog post. Eight of the twelve had never had a retention policy set. Five hadn't been queried in over three months.

The audit came back with a monthly bill of $854. Turning on tiering, before I'd approved a single retention change, already brought it to $831 — 2.7%. Approving retention on the four highest-ingest groups took it to $820, 4.0%. Approving the other four, the small stale ones nobody had looked at in months, moved it another tenth of a point to 4.1%. I checked the math three times assuming I'd made an error, because I'd expected something closer to the "cut your logs bill in half" territory these posts usually promise, and I definitely hadn't expected that most of the checkboxes I was so careful to gate behind human approval would turn out not to matter much.

I hadn't made an error. The reason is in the unit prices themselves. Ingestion runs about $0.76 per GB, charged once, every month, on whatever volume you're currently generating. Storage, after CloudWatch's roughly 0.15x compression, comes out to about $0.0045 per GB per month. For a byte of log data to cost as much in storage as it cost to ingest, it has to sit around for roughly 169 months — about fourteen years. Under those numbers, ingestion dominates the bill for any log group whose retention is measured in weeks or months, which is most of them. Tiering and retention hygiene only start moving the needle on data that's been sitting for years, and by definition most production log groups haven't been running for years without anyone touching the retention setting.

None of this makes the AWS guide wrong. Setting a retention policy is still the right call for the eight groups in my fleet with none — an unbounded log group is a liability regardless of what it costs this month, and the guide is explicit that the storage problem is a compounding one over a multi-year horizon, not a this-month one. Intelligent Tiering is free to turn on and only ever saves money, so there's no reason not to. What the run told me is narrower and more useful: if your bill is dominated by ingestion, which is the common case, the guide's three levers are governance, not a rescue plan. The lever that actually moves an ingestion-heavy bill is what you choose to log in the first place, and the guide's own constraint on that — the Infrequent Access log class can only be picked when a group is created, never changed afterward — means that lever only applies going forward, not to the fleet you already have.

I put the demo up at logcost-gate.vercel.app . It runs against the same synthetic fleet every time rather than a live account, so the numbers won't move between visits, but the audit and the approval gate are real code, not a mockup.