Inside the Finout Investigator: How a 9% CPU Database Became a Decision-Ready Recommendation

Follow Finout’s Investigation Agent through a real-world RDS rightsizing case: from a low-utilization signal to a recommendation built on evidence and policy, with a clear list of what still needs a human.

Finding cloud cost optimization opportunities is the easy part.

A detector can tell you that a resource looks oversized, appears idle, or might be worth optimizing. Before anyone touches production infrastructure, though, a much harder set of questions starts:

• Does the evidence actually support the recommendation?
• What configuration should we move to?
• Does that target fit the workload, including its peaks and not just its average?
• Does it respect our infrastructure policies?
• How much would we actually save?
• What still needs to be validated, and who needs to do what next?

That’s where Finout’s Investigation Agent, the Investigator, comes in.

Finout is building an agentic FinOps experience around a simple flow: Detection → Investigation → Action. The Detection Agent finds potential optimization opportunities. The Investigator picks up the case and turns the signal into a decision-ready investigation, grounded in Finout’s cost, usage, and resource data and in the customer’s own configuration.

Let’s follow one investigation from start to finish.

The Case: A Production Database That Looks Oversized

It starts with a signal.

A Finout Detector flags orders-db-prod, an Amazon RDS for PostgreSQL instance running on a db.r5.4xlarge (16 vCPU, 128 GiB) in a Multi-AZ deployment. Over the last 30 days, its average CPU utilization was 9%.

Most tools stop here. They rank the finding by dollar value and suggest the smallest instance that fits the average.

A production database is not a place to guess. Low average utilization doesn’t tell you what the right target is, whether the workload has peaks, whether the move breaks a policy, or what still needs checking.

So instead of stopping at “This database may be oversized,” Finout starts an investigation.

Phase 1: Understand the Resource and the Evidence

The Investigator begins by gathering what Finout already knows: the current configuration, cost, and optimization signal, plus 30 days of workload metrics. It then tests each metric against the claim that the database is oversized.

This is where the case changes direction.

The 9% average suggests cutting the instance in half, then cutting it again. The nightly peak says the second cut would hurt. And without the cache hit ratio, nobody can say with confidence how much of the database’s working set depends on memory.

What matters is what the Investigator doesn’t do. It doesn’t fill gaps with assumptions. It doesn’t invent a cache hit ratio, it doesn’t guess which team owns the database, and it doesn’t make up a cost figure it doesn’t have.

Missing evidence becomes part of the investigation: something to validate before anyone acts.

The goal isn’t the most confident-sounding answer. The goal is an answer a FinOps practitioner can trust.

Phase 2: Find the Best Valid Target Within the Customer’s Guardrails

Once the evidence is clear, the harder question is what should we actually do?

Finout doesn’t just pick the next smaller size. It evaluates options within the current family, alternatives from other families, and newer generations. Each candidate is checked against the workload, against the infrastructure capabilities it needs to keep, and against the policies this organization has defined.

There’s no universal “best” cloud configuration. One company allows moves between instance families and another forbids them. One accepts burstable instances in some environments and another never allows them in production. Many protect processor architecture, minimum memory, or recently resized resources. Finout builds these customer-defined guardrails into the decision itself.

Here’s how the candidates for orders-db-prod came out:

The cheapest option in the catalog was the wrong answer.

A tool that ranks by dollars alone would have recommended db.r5.xlarge, and the nightly batch job would have surfaced the problem at 2 a.m. A move that’s technically possible but breaks the organization’s policies is not a valid recommendation.

The Investigator isn’t looking for the cheapest resource. It’s looking for the best valid outcome within the limits the customer has set.

Phase 3: Turn the Decision Into an Investigation Humans Can Review

Instead of returning “Downsize resource,” the Investigator explains the case by answering five questions:

What was investigated?
orders-db-prod, a production PostgreSQL database flagged for low average CPU.

What did Finout find?
The instance is about 2x oversized, but not 4x, because the nightly batch job sets the floor.

What evidence supports it?
30 days of CPU, memory, and connection data, plus the projected utilization on the recommended class.

What is the potential financial impact?
About $1,460 per month (about $17,500 per year) in on-demand compute.

What still needs to be validated?
The buffer cache hit ratio. Turn on Performance Insights, or have the database owner confirm that the working set fits in 64 GiB.

That last question is the most important one. Good investigation doesn’t hide uncertainty. It makes uncertainty actionable.

Phase 4: Show the Evidence, Not Just the Answer

A recommendation is much easier to trust when the evidence sits right next to it.

For orders-db-prod, the Investigator shows the 30-day CPU trend with the 02:00 UTC peak marked. It also shows the projected utilization on db.r5.2xlarge against the 70% headroom line, next to the memory trend. Users don’t have to rebuild the investigation themselves.

The evidence changes with the question. An idle-resource investigation, for example, would focus on resource state, attachment status, recent activity, how long the resource has been idle, cost, and ownership.

The goal stays the same: give the user enough evidence to see why Finout reached its recommendation, and to decide whether to move forward.

Phase 5: Turn the Investigation Into the Next Action

An investigation that ends with “here’s what we found” still leaves work for the user. So the Investigator turns the finding into a concrete next step.

In this case, one validation is still open. The Investigator drafts a short, copy-ready message to the database owner with the context needed to confirm the working-set size. It also drafts a ticket-ready change: resize orders-db-prod to db.r5.2xlarge during the next maintenance window. Because the database is Multi-AZ, the change triggers a short failover, so schedule it away from the 02:00 UTC batch job. The ticket includes the justification, the expected savings, and the main risk.

Users can keep digging with contextual follow-up questions, such as what happens if the batch job grows 30%.

For now, the human stays in control. Finout prepares the recommendation and the operational context for review; it doesn’t silently change infrastructure for the customer. Over time, this investigation layer becomes the bridge between Detection and Orchestration: from finding an opportunity, to understanding it, to eventually helping teams carry it out in their existing workflows.

The Complete Optimization Investigation

1. Detect. A Finout Detector flags orders-db-prod for low average CPU.
2. Investigate. The Investigator gathers 30 days of workload, cost, and configuration context, and surfaces the nightly peak and the missing cache hit ratio.
3. Evaluate. Candidates are tested against workload requirements, infrastructure capabilities, economic impact, and customer guardrails. Three are rejected and one is valid.
4. Explain. The result becomes a decision-ready case, with evidence, about $1,460 per month in impact, and one explicit validation step.
5. Act. The Investigator drafts the owner message and the ticket-ready change for review.

As Finout extends the Investigator to more optimization use cases, the same model applies: start with a signal, investigate the evidence, respect the customer’s context, find the right recommendation, explain it, and help the user move it forward.

Why This Matters

Cloud optimization has never been short on recommendations. The hard part is turning them into decisions teams are comfortable acting on.

Every finding leaves a gap between “we found something” and “we know what to do.” Closing that gap usually means a FinOps practitioner has to read the metrics, understand the infrastructure constraints, calculate the impact, apply the organization’s policies, and translate all of it into something engineering will act on. The Finout Investigator is built to do that work.

Three things make the difference:

Context. The Investigator never looks at a resource in isolation. It works from the customer’s own cost and usage data, resource configuration, optimization signals, and policies. That’s how it knew the nightly batch job mattered more than the average.

Trust. A strong recommendation isn’t one that sounds certain. It’s one that clearly separates what the evidence supports from what still needs validation. When the cache hit ratio wasn’t available, the Investigator said so.

Actionability. The output isn’t another optimization card for someone to interpret later. It brings the finding, the evidence, the financial impact, the validation step, and the next action together in one place.

Detection tells you where to look. The Finout Investigator tells you what the evidence supports, why it matters, and what should happen next.

That’s how optimization moves from a recommendation to a decision.