If you have spent any time in a mature cloud estate lately, you will recognise the scene. There is a dashboard somewhere showing 4,000 findings. There is a spreadsheet from the last audit that nobody has opened since the kickoff call. And there is a Slack thread, three months old, that ends with someone asking "does anyone know what prod-legacy-svc-2 actually does?" followed by silence.

Welcome to the current state of cloud audit tooling. The industry has become genuinely excellent at finding problems. It remains remarkably bad at fixing them.

The audit tools themselves are fine. Mostly.

Credit where it's due: the tooling has come a long way. The CSPM crowd (Wiz, Orca, Prisma Cloud and friends) will happily graph your attack paths. The FinOps platforms will tell you, to the cent, how much you're wasting on idle compute. The cloud providers' own advisors will nag you about unattached volumes and over-provisioned instances until you mute the notifications.

The problem is that all of this is diagnosis. An audit tool that produces a 200-page PDF of findings has not actually improved your estate. It has improved your awareness of how bad your estate is, which is a different thing, and arguably worse for morale.

Why remediation is so much harder than detection

Here's the uncomfortable truth that most audit vendors gloss over: the reason those findings sit unresolved for years is not laziness. It's fear, and the fear is rational.

Years of cloud sprawl mean most organisations are carrying hundreds of resources with no known owner. The engineer who built it left in 2021. The tagging policy was introduced in 2023 and never backfilled. The Terraform state drifted so long ago that nobody trusts it. So when the audit says "this security group is wide open" or "this instance has been idle for 400 days", the honest internal response is: probably safe to remove. Probably. But if it turns out that unlabelled Lambda was quietly holding up month-end billing, you're the one explaining the outage.

So nothing gets deleted. The findings pile up, the bill grows, and the technical debt compounds. Detection without confident ownership mapping is just an anxiety generator.

Any serious approach to cloud assurance has to start with archaeology: working out what things are, who they belong to, what depends on them, and only then what to do about them. Very few tools do that part well.

A word on Well-Architected reviews

The AWS Well-Architected Framework gets a lot of use in this space, and let's be fair: it's not bad. Azure has its own Well-Architected Framework, Google has its Architecture Framework, and all three are sensible, structured ways to think about reliability, security, cost and performance. If your team has never done a structured review, doing one will genuinely surface useful things.

But two caveats deserve more airtime than they get.

First, "free" is doing some heavy lifting. Well-Architected reviews are frequently delivered by partners, and there are funding credits floating around specifically to incentivise them. That's not a scandal, but understand the commercial mechanics: the review is often the top of a partner's sales funnel. The findings will, remarkably often, point towards services and engagements that the partner (and the cloud provider) would quite like to sell you. You're not getting an audit, you're getting a well-structured pitch with an audit attached.

Second, and more fundamentally: these frameworks are written by the cloud providers themselves. They will never tell you that the answer to your cost problem is egress pricing being what it is, or that you're over-exposed to a single vendor's pricing decisions, or that a particular managed service locks you in harder than the alternatives. A Well-Architected review will happily tell you your architecture is sub-optimal. It will never tell you the cloud is sub-optimal for your workload, because that question sits outside the frame by design. The frame is the bias.

None of this makes the frameworks useless. It makes them one input, from one interested party, rather than the neutral scorecard they're often presented as.

The lift-and-shift treadmill

The other gap in the market: almost nothing helps you actually rearchitect. The migration tooling ecosystem is superb at moving your legacy application from one place to a slightly nicer version of the same place. VM to VM, VM to container, container to a managed container. The application itself, with its twenty-year-old assumptions and its tangle of undocumented dependencies, arrives at the destination fully intact.

That's not modernisation. That's relocation. You've moved the technical debt into a building with better lighting.

The interesting shift, and the reason we think this space is about to change quickly, is AI. Rebuilding a legacy system used to be a multi-year, career-risking programme, which is exactly why everyone chose lift and shift instead. With modern AI-assisted engineering, the economics of a genuine rebuild have moved dramatically. Understanding a legacy codebase, mapping its behaviour, and regenerating it against a modern architecture is becoming weeks-and-months work rather than years.

And once rebuilding is cheap, the destination becomes a real choice again. Next-gen clouds and specialised platforms are suddenly viable. And yes, shock horror, so is going back on-prem. Repatriation used to be a contrarian talking point; for predictable, steady-state workloads with painful egress bills, it's increasingly just arithmetic. When your architecture is no longer welded to one provider's managed services, you get to do that arithmetic honestly.

Where this is heading

The next generation of cloud audit needs to do three things the current one doesn't: map ownership and dependencies well enough that people stop being scared to delete things, assess the estate from a vendor-neutral position rather than inside one provider's framework, and connect findings to actual rearchitecture rather than another round of lift and shift.

It's the gap we kept running into on client work, which is why we ended up building our own Cloud Assurance tool at refactor.red. But whichever tooling you use, the principle stands: an audit that ends with a PDF is a cost. An audit that ends with a smaller, cleaner, better-architected estate is the point.

Stop counting the findings. Start closing them.