24/7 Monitoring Caught a $7,500/Month Surprise During an Account Migration

The Number That Was Going the Wrong Way

One account's spend went up. That would be unremarkable, except this was an account we were in the middle of switching off. A decommissioning account still carries cost right up until the end, so the number is never zero. But the direction should be down, not up. The agent flagged it the first day the number moved the wrong way, before anyone on the client's side had noticed a thing.

That contradiction is where this story starts.

The Context

The client is a global financial services group running on AWS. When we came in they were partway through an account migration, moving workloads into a new AWS account and decommissioning the old one.

The old account was on its way out. Someone had already gone through and stopped the resources that were no longer needed, databases included. Decommissioning a large account is not a switch you flip, though. Migrations have to be finalised, dependencies unpicked, and data deleted safely, so the account still carried real spend and its cost was meant to wind down gradually rather than disappear. During a migration all the attention sits on the new account, on getting workloads across and stable. The old one becomes an afterthought. That is precisely the blind spot.

The Signal

Our AI agent monitors cost across every connected account continuously. What matters here is not just that it was watching, but that it understood what it was watching. It knew this account was being decommissioned. It knew the cost curve was supposed to point down.

So on the very first day RDS cost on that account came in higher than the day before, the agent did not read it as ordinary variance. It read it as a contradiction, and the alert it raised said exactly that: RDS costs are increasing in a decommissioning account.

That specificity is the point. Not "spend is up by some percent" but "the wrong service is growing in an account that is supposed to be shrinking". At that moment we did not know why. The resources had been stopped. Something was not adding up, and the only thing that had noticed was the agent, on day one.

The Investigation

So we pulled the account apart to see what was driving the number. The databases that had been stopped were running again.

Nobody had started them. No deploy, no change request, no human action of any kind. They had simply come back on their own. That is the part that stops you. A resource you deliberately switched off, live again, billing at full price, with no one having touched it.

Here is the behaviour that catches teams out. When you stop an RDS instance, AWS does not leave it stopped indefinitely. After 7 days, it starts the instance back up automatically. AWS uses that window to apply pending maintenance and patching. It is documented, and there is a sensible reason for it, but almost nobody remembers it in the moment. The instances hit their seventh day, AWS quietly brought them back, and the meter started running again.

Left alone, those restarted instances would have added roughly $7,500 a month to an account that was meant to cost nothing. Around $90,000 a year on infrastructure nobody was using.

Why This Matters

The catch here was not a threshold alarm. Plenty of tools can tell you spend went up by some percentage. What mattered was that the agent understood the intent of the account. Rising spend on a dying account is only meaningful if you know the account is dying. That context is what turned a small, easily ignored number into a signal worth acting on.

It is also why the timing mattered. Native cloud billing is retrospective. You learn about this month's spend next month, at the account and service level, long after the money has left. During a migration, when a resource restarting itself is the last thing on anyone's mind, that lag is exactly where surprises live. Instead of discovering the cost in a later bill, we caught it on the first day it moved, while it was still a rounding error. That is the difference between recovering a cost after the fact and preventing it before it compounds.

Worth flagging that this is not a rare edge case. RDS auto-restart after 7 days affects anyone who stops instances and expects them to stay stopped, which is common during migrations, decommissions, and cost exercises. In most environments the team only notices when the bill arrives.

This is engineering-grade FinOps in practice. Knowing the platform behaviour, watching every account continuously and in context, and acting on the signal while it still costs almost nothing.

That's the kind of surprise Koritsu is built to catch before it lands.