Industry: Digital marketing and directory services - Finland. Engagement: April–May 2026, single AWS development and QA account. Client identity anonymised.
Cost governance rarely fails because nobody cares. It fails because the person who cares has twelve other things on their plate.
For a Finnish digital marketing and directory services company, cloud cost optimisation rested on a single operations engineer. Not because the organisation was negligent, but because that is how these things work in practice. Patching, incidents, service requests, and provisioning queue ahead of cost reviews every time. The work that shouts gets done. The work that quietly accumulates does not.
The client wanted to know whether autonomous cost optimisation could surface what a stretched team never had time to chase. More specifically, they wanted the figures verified against their real AWS environment before committing to anything.
Firemind ran a live deployment of its IT Operating Engine on the client’s AWS development and QA account over two months. Cost optimisation ran continuously, as part of live operations, not as a one-off review.
The problem with manual FinOps
Manual cost reviews have a structural blind spot. They chase the big wins because the economics make sense: if an engineer spends two hours finding a saving, the saving needs to be worth two hours of that engineer’s time.
That threshold filters out a long tail of genuine waste. An idle IP address costing £4 a month does not make the list. Neither does an unattached EBS volume at £5. Neither, usually, does a database running at near-zero utilisation outside its once-a-day backup window, because identifying that pattern takes time the team does not have.
The result is a cost estate that looks optimised but is not. The big-ticket items get reviewed. The rest accumulates.
What continuous optimisation found
Running live on the client’s dev and QA estate, the IT Operating Engine produced a ranked, item-by-item savings list with a specific monthly figure attached to each one.
The largest single saving was an Oracle database - qa-oracle-01 - running at approximately 3% CPU utilisation off-peak, active only during the nightly backup window. Monthly saving: approximately £862.
After that: an over-provisioned three-node Elasticsearch cluster at approximately £423 per month. An idle DocumentDB instance at approximately £209. An Aurora instance that could run on a business-hours schedule at approximately £108. A second dormant DocumentDB at approximately £79. And 714 GB of unattached EBS storage at approximately £43.
The confirmed total: £1,888 per month, or £22,650 annualised, from a single development and QA account.
The engine corrected itself
One finding is worth highlighting because it illustrates what makes continuous optimisation different from a periodic audit.
The engine initially flagged a DocumentDB instance as a termination candidate. Before actioning that recommendation, it observed actual utilisation data - and found the instance reached 20% peak utilisation at specific times. Termination was amended to a scale-down with an after-hours stop schedule.
A one-off review would have captured a snapshot. A continuous process observed the pattern. The difference matters when the cost of a wrong recommendation is data loss or a production incident.
Firemind’s delivery lead also cross-verified the engine’s full analysis against the live environment. The recommendations closely matched the actual state of the estate. That verification is what allowed the savings to be stated as confirmed rather than estimated.
What gets left on the table
The long tail in this engagement - unattached storage, idle IPs, schedulable compute - is where the structural difference between manual and continuous FinOps becomes visible.
Each item is individually small. Together, they represent a meaningful share of the total saving. And because the IT Operating Engine carries no cost threshold, nothing is filtered out. Every item that can be priced gets priced.
Run continuously across a wider estate, that dynamic compounds. A one-off cost review captures the obvious wins. A continuous discipline catches what accumulates between reviews, which turns out to be quite a lot.
The engagement has since progressed into commercial business case discussions, with further savings headroom to assess across the wider estate.
Cost governance as an ongoing discipline
The insight from this engagement is not that the client was wasting money carelessly. It is that cost governance without a continuous feedback loop will always drift.
Organisations that want predictable cloud spend need the same continuous coverage they apply to security or availability. Not a quarterly review, not an annual audit, but a process that watches the estate and surfaces waste as it appears.
That is what becomes possible when cost optimisation runs as part of live operations rather than competing for time against everything else.
Read the full case study: £22,650 a year in confirmed AWS savings, from a single dev and QA account
