Automating AWS EBS Cleanup Workflows with Wiv, BigQuery, and Ownership Mapping

Most FinOps teams I talk to do not have a visibility problem. They have a follow-through problem.

The findings are already sitting right in front of them, politely waving. What is missing is the connective tissue. Someone has to clean the data, figure out who owns the resource, route the work to the right owner, and keep nudging until something actually changes. That middle layer is where most cost programs go to take a nap.

A large cybersecurity company I talked to recently built something pretty elegant for this with Wiv, and the pattern is worth walking through.

The short version is this: AWS data flows into Wiv, gets transformed and enriched there, lands in BigQuery, and ends up in Google Sheets where engineering teams actually review it. That last hop matters more than it sounds. Nobody wakes up excited to log into another tool to look at a cost recommendation. They want it in something they already have open, ideally next to the tab where they are pretending to read a design doc.

The orphaned EBS volume workflow is a good example. The traditional approach here is roughly this: export a CSV, wrestle it in a spreadsheet, email a report that is stale by the time it lands, and then hold a meeting three weeks later to ask whether the numbers are still good. Nobody remembers. Then a week or two later everybody has the same conversation again. It is FinOps Groundhog Day.

This team took a different route. They set up Wiv to grab the resource data from AWS, apply their own ownership logic, attach cost context, and push the result into BigQuery. Google Sheets pulls from there. Every morning the team opens a sheet that is already current, already sorted, already annotated. The file is not named something like ebs_cleanup_FINAL_v_reallyfinal.xlsx, which in my experience is already a win.

The enrichment layer is where this gets interesting. Like any large AWS environment, they had ownership logic scattered across tags, account structures, naming conventions, and the memories of roughly four people, two of whom have since taken other jobs. Someone knew that a certain prefix meant a certain team. Someone else knew which tag was authoritative when two disagreed. That kind of tribal knowledge does not scale, and it definitely does not survive a reorg.

So they codified it inside Wiv. They built a rules engine that normalizes identifiers, standardizes outputs, and maps ownership consistently before anything moves downstream. By the time the data hits Google Sheets, it is already shaped into something a reviewer can act on without scheduling a call to ask what any of it means.

And that is really the point. Plenty of tools can tell you there is waste. Far fewer do the operational work in the middle, which is where cost programs typically get stuck forever. In this setup, “we found something” is not the end of the workflow. It is maybe a third of the way through.

They are using the same pattern beyond classic cost optimization too, including alerting, anomaly-style use cases, and API integrations with other internal systems. The common thread is automating the stitching work that tends to accumulate around a FinOps team, especially the kind of team that is small relative to the footprint it is responsible for. Which is to say, every FinOps team.

And that mismatch is the job, really. A handful of people and an environment they could not manually audit if you gave them a year to do it. The only way it works is if the path from finding to action is mostly automated, and if the output lands where the people doing the actual remediation already live.

The hard part in FinOps is rarely spotting the issue. It is getting from finding to follow-up before the context evaporates and everyone forgets who owned it. This team built a better path for that, and Wiv is doing a lot of the heavy lifting.