Cloud Waste Doesn’t Happen Overnight

How I stopped treating cloud governance as an audit and started treating it as an engineering workflow.

During my early years working with AWS environments, I assumed cloud governance was something teams reviewed every few months. A security assessment, cost optimization exercise OR a compliance report before an audit.

The process always looked similar. Run a few scripts —> Export a spreadsheet —> Raise a list of findings —> Assign them to different teams —> Wait for them to be fixed.

A month later, the same findings would appear again. That cycle repeated itself across different environments. Eventually I realised the problem wasn’t identifying issues.

The problem was treating governance as an event instead of an engineering capability.


The Pattern I Kept Seeing

Every AWS account looked clean on the day it was reviewed. A few weeks later, small inconsistencies started appearing.

  • An EBS volume attached to an instance that no longer existed. Snapshot nobody remembered creating. Application Load Balancer still running after a migration.
  • Security groups with rules nobody could explain.
  • Resources launched without mandatory tags.
  • IAM roles that hadn’t been used for months.

None of those issues looked serious on their own. Together, they slowly increased operational risk, cloud spend and engineering effort. Nobody intentionally created cloud waste. It accumulated because there was nothing continuously looking for it.


The Turning Point

That changed how I approached governance.

Instead of asking,

“How do I generate a better audit report?”

I started asking,

“How do I make governance part of the engineering workflow?”

That shift completely changed the solution.


Building Continuous Governance

Instead of running periodic reviews, I built a platform that continuously evaluated AWS resources against engineering policies. Every new resource automatically became part of the same governance process.

  • Security.
  • Cost.
  • Operational hygiene.
  • Compliance.

Everything was evaluated using policy as code. Instead of manually checking resources, policies continuously checked the environment.


One Example

One recurring issue involved storage. Every review identified unattached EBS volumes.

The recommendation was always the same —> Delete them.

A month later, another set of unattached volumes appeared. Deleting resources wasn’t solving the problem. The environment was simply creating new ones faster than reviews could remove them. Instead of producing another report, I introduced continuous detection and with that every unattached volume was automatically identified. Resources were tagged with ownership information. Teams could immediately understand why the resource had been flagged. Some policies automatically remediated low-risk findings. Others generated actionable recommendations for engineering teams.

The objective wasn’t deleting EBS volumes.

The objective was preventing forgotten infrastructure from becoming permanent infrastructure.


Beyond Cost Optimization

One lesson became very clear. Most governance discussions focus on cost. My experience was different. Cloud governance was equally about engineering quality.

  • Unused load balancers increased operational complexity.
  • Missing tags made incident response slower.
  • Old IAM roles expanded the attack surface.
  • Unmanaged snapshots complicated disaster recovery.

Every finding represented engineering debt. The monthly AWS bill was simply one way that debt became visible.


How I Think About Governance Today

Today, I don’t think of governance as reporting. I think of it as continuous feedback. A good governance platform shouldn’t tell engineers what they did wrong last month. It should help them make better decisions today. That philosophy influenced how I designed governance platforms.

—> Detection.

—> Context.

—> Recommendation.

—> Automated remediation where appropriate.

The goal is never to produce another compliance dashboard rather I focus on enabling cloud environment continuously improve itself.


Looking Back

The biggest lesson I learned wasn’t about Cloud Custodian, Steampipe or any specific tool.

It is much simpler.

Cloud environments naturally drift toward complexity.

Good governance continuously moves them back toward simplicity.

That’s the mindset I now bring to every cloud platform I help design.